المقدمة
كما تعلم ، فإن الانتقال من بنية متراصة إلى بنية الخدمات المصغرة يسبب عددًا من الصعوبات المرتبطة بالجزء الفني للمشروع والعامل البشري. أحد أصعب التحديات التقنية هو ضمان الاتساق في النظام الموزع.
التناسق
النقطة الدقيقة إلى حد ما هي أن الاتساق في سياق الأنظمة الموزعة يختلف عن الاتساق في سياق قواعد البيانات. علاوة على ذلك ، من خلال الاتساق ، سنعني بالضبط الأول: العملية غير الكاملة (الخاطئة) لا تقدم أي تأثيرات ولا تغير البيانات ؛ مع الوصول المتزامن إلى البيانات ، تعتبر جميع العمليات بمثابة ذرية (لا يمكنك رؤية النتيجة الوسيطة للعملية) إذا كانت البيانات تحتوي على نسخ متعددة (تكرار) ، فإن تسلسل تطبيق العمليات على جميع النسخ هو نفسه. هذا ، في الواقع ، نريد أن نتلقى معاملة ACID ، ولكن فقط واحدة موزعة.
سبب المشكلة
لماذا يصعب الحفاظ على الاتساق في بنية الخدمات المصغرة؟ الحقيقة هي أن هذا النمط المعماري غالبًا ما يتضمن استخدام قاعدة البيانات لكل نمط خدمة. دعني أذكرك أن هذا النمط يتألف من حقيقة أن كل خدمة صغيرة لها قاعدة أو قواعد مستقلة خاصة بها (قواعد ، لأنه بالإضافة إلى مصدر البيانات الأساسي ، على سبيل المثال ، يمكن استخدام ذاكرة التخزين المؤقت). يسمح هذا النهج ، من ناحية ، بعدم إضافة روابط تنسيق بيانات ضمنية بين الخدمات المصغرة (تتفاعل الخدمات المصغرة فقط بشكل صريح من خلال واجهة برمجة التطبيقات) ، من ناحية أخرى ، لتحقيق أقصى استفادة من بنية الخدمات المصغرة باعتبارها تقنية غير محددة (يمكننا اختيار تقنية تخزين البيانات المناسبة للحمل المحدد على الخدمة المصغرة ). ولكن مع كل هذا فقدنا ضمان تناسق البيانات. أحكم لنفسكتتواصل وحدة monolith بقاعدة بيانات كبيرة واحدة ، مما يوفر القدرة على توفير معاملات ACID. يوجد الآن العديد من قواعد البيانات ، وبدلاً من معاملة ACID كبيرة واحدة ، لدينا العديد من معاملات ACID الصغيرة. ستكون مهمتنا دمج كل هذه المعاملات في واحدةوزعت .
الاتساق المتفائل
أول ما يتبادر إلى الذهن هو مفهوم التناسق المتفائل: نحن نلتزم بالعديد من المعاملات التي نريدها لعدد كبير من محركات التخزين حسب الحاجة. في الوقت نفسه ، نتوقع أن يكون كل شيء على ما يرام ، وإذا كان كل شيء سيئًا ، فنحن نقول إن كل شيء سيكون على ما يرام في النهاية. إذا كان كل شيء سيئًا في النهاية ، فإننا نقول: "نعم ، هذا يحدث ، ولكن باحتمالية منخفضة للغاية."
إذا وضعنا المزاح جانباً ، فإن إهمال الاتساق عندما لا يكون العمل حرجًا هو فكرة جيدة ، خاصة عندما تفكر في مقدار الجهد الذي سيكلفنا الحفاظ عليه (والذي آمل أن تراه لاحقًا).
خيارات الاتساق
إذا كان الاتساق أمرًا بالغ الأهمية للعمل ، فهناك عدة طرق لمحاولة تحقيقه. إذا كنا نتحدث عن موقف يتم فيه تحديث البيانات بواسطة خدمة واحدة (على سبيل المثال ، يوجد تكرار لقاعدة البيانات) ، فيمكن تطبيق خوارزميات الاتساق القياسية مثل Paxos أو Raft. تسمى هذه المعاملات متجانسة . إذا تم تحديث البيانات بواسطة عدة خدمات (أي ، تتم معاملة غير متجانسة ) ، فكيف يبدأ التعقيد ، الذي تحدثنا عنه أعلاه.
من ناحية أخرى ، لا يزال بإمكاننا تجاوز الحاجة إلى توفير معاملة موزعة من خلال السعي وراء بنية قائمة على الخدمة (نقوم بدمج الخدمات بطريقة تجعل المعاملة متجانسة). مثل هذا الحل ليس أساسيًا جدًا من وجهة نظر مبادئ بنية الخدمات المصغرة ، ولكنه أبسط من الناحية الفنية ، وهذا هو سبب استخدامه غالبًا في الممارسة. من ناحية أخرى ، يمكننا ترك الخدمات المصغرة الأساسية ، ولكن في نفس الوقت نطبق إحدى الآليات لضمان المعاملات الموزعة: الالتزام على مرحلتين أو الملحمة. ستستكشف هذه المقالة الخيار الأول وتناقش الخيار الثاني في المرة القادمة.
مرحلتين الالتزام
الآلية بسيطة للغاية: هناك بعض مدير المعاملات الذي ينظم الصفقة بالفعل. في المرحلة الأولى (التحضير) ، يصدر مدير المعاملات الأمر المناسب لمديري الموارد ، والتي بموجبها يكتبون البيانات في سجلاتهم التي سيتم الالتزام بها. بعد تلقي تأكيد من جميع مديري الموارد حول الإكمال الناجح للمرحلة الأولى ، يبدأ مدير المعاملات المرحلة الثانية ويصدر الأمر التالي (الالتزام) ، والذي بموجبه يطبق مديرو الموارد التغييرات المقبولة مسبقًا.
على الرغم من بساطته الواضحة ، فإن لهذا النهج عددًا من العيوب. أولاً ، إذا فشل مدير موارد واحد على الأقل في المرحلة الثانية ، فيجب التراجع عن المعاملة بالكامل. وبالتالي ، تم انتهاك أحد مبادئ بنية الخدمات المصغرة - التسامح مع الخطأ (عندما وصلنا إلى نظام موزع ، افترضنا على الفور أن الفشل فيه هو القاعدة وليس حالة استثنائية). علاوة على ذلك ، إذا كان هناك الكثير من الإخفاقات (وسيكون هناك الكثير منها) ، فإن عملية إلغاء المعاملات سوف تحتاج إلى أتمتة (بما في ذلك كتابة المعاملات التي تتراجع عن المعاملات). ثانيًا ، يعتبر مدير المعاملات نفسه نقطة فشل واحدة. يجب أن يكون قادرًا على إصدار id-shniks للمعاملات. ثالثًا ، نظرًا لأنه يتم إعطاء أوامر خاصة للمستودع ، فمن المنطقي أن نفترض أن المستودع يجب أن يكون قادرًا على القيام بذلك ،أي يتوافق مع معيار XA ، ولا تتوافق جميع التقنيات الحديثة معه (لا يدعم الوسطاء مثل Kafka و RabbitMQ و NoSQL مثل MongoDB و Cassandra الالتزامات ذات المرحلتين).
لقد أوضح كريس ريتشاردسون الاستنتاج الذي يقترح نفسه من كل هذه العوامل بشكل جميل: "2PC ليس خيارًا" (الالتزام على مرحلتين ليس خيارًا).
انتاج |
اكتشفنا سبب كون المعاملات الموزعة هي الألم التقني الرئيسي لهندسة الخدمات المصغرة وتحدثنا عن الخيارات المختلفة لحل هذه المشكلة ، وناقشنا بالتفصيل آلية الالتزام ذات المرحلتين.
أدعو الجميع للاشتراك في الندوة التعليمية على الويب الخاصة بي حول الدورة ، والتي سأخبرك فيها بالتفصيل عن تنسيق التدريب وأعرف الجميع ببرنامج التدريب.