الخدمات المصغرة - انفجار اندماجي للنُسخ

مرحبا يا هابر! أقدم لكم ترجمة المؤلف للمقالة Microservices - انفجار اندماجي للنسخ .

في الوقت الذي يتحرك فيه عالم تكنولوجيا المعلومات تدريجيًا إلى خدمات وأدوات مصغرة مثل Kubernetes ، أصبحت مشكلة واحدة فقط أكثر وضوحًا. هذه المشكلة هي انفجار اندماجي لإصدارات الخدمات الصغيرة. ومع ذلك ، يعتقد مجتمع تكنولوجيا المعلومات أن الوضع الحالي أفضل بكثير من جحيم التبعية للجيل السابق من التقنيات. ومع ذلك ، فإن التحكم في إصدار الخدمات الصغيرة يمثل مشكلة معقدة للغاية. يمكن العثور على أحد الأدلة على ذلك في مقالات مثل "إرجاع My Monolith to Me" .

إذا كنت تقرأ هذا النص ولكنك لا تفهم المشكلة ، دعني أشرح لك. افترض أن منتجك يتكون من 10 خدمات صغيرة. لنفترض الآن أنه تم إصدار نسخة جديدة لكل من هذه الخدمات الصغيرة. الإصدار 1 فقط - آمل أن نتمكن جميعًا من الاتفاق على أن هذه حقيقة تافهة ولا معنى لها. الآن ، مع ذلك ، ألق نظرة على منتجنا مرة أخرى. مع إصدار واحد جديد فقط من كل مكون ، لدينا الآن 2 ^ 10 - أو 1024 تبديلًا لكيفية تكوين منتجنا.

إذا كان لا يزال هناك بعض سوء الفهم ، دعني أتوسع في الرياضيات. لذا ، لدينا 10 خدمات صغيرة ، كل منها يتلقى تحديثًا واحدًا. أي أننا نحصل على نسختين ممكنتين لكل خدمة صغيرة (سواء قديمة أو جديدة). الآن ، لكل مكون من مكونات المنتج ، يمكننا استخدام أي من هذين الإصدارين. رياضيا ، هذا هو نفسه كما لو كان لدينا عدد ثنائي من 10 أحرف. على سبيل المثال ، دعنا نقول أن 1 هو الإصدار الجديد ، و 0 هو الإصدار القديم - ثم يمكن تسمية التباديل المحتمل على أنه 1001000000 - حيث يتم تحديث المكونين الأول والرابع ، ولكن لا يتم تحديث جميع البقية. من الرياضيات ، نعلم أن الرقم الثنائي المكون من 10 أحرف يمكن أن يحتوي على 2 ^ 10 أو 1024 قيمة. أي أننا أكدنا حجم العدد الذي نتعامل معه.

نواصل النقاش أكثر - وماذا يحدث إذا كان لدينا 100 خدمة صغيرة ولكل منها 10 إصدارات محتملة؟ أصبح الوضع برمته مزعجًا للغاية - الآن لدينا 10 تباديل 100 ^ - وهذا رقم ضخم. ومع ذلك ، فإنني أفضل وصف هذا الموقف تمامًا ، لأننا الآن لا نختبئ وراء كلمات مثل "kubernetes" ، لكننا نواجه المشكلة كما هي.

لماذا هذه المشكلة رائعة بالنسبة لي؟ جزئياً لأننا عملنا سابقًا في عالم البرمجة اللغوية العصبية والذكاء الاصطناعي ، ناقشنا الكثير من مشكلة الانفجار الاندماجي منذ حوالي 5-6 سنوات. فقط بدلاً من النسخ كان لدينا كلمات منفصلة ، وبدلاً من المنتجات كان لدينا جمل وفقرات. على الرغم من أن مشاكل البرمجة اللغوية العصبية والذكاء الاصطناعي لا تزال دون حل إلى حد كبير ، يجب أن نعترف بأنه تم إحراز تقدم كبير على مدى السنوات القليلة الماضية.(من وجهة نظري ، يمكن استخدام التقدم ل limim إذا كان الناس في الصناعة أقل اهتمامًا بالتعلم الآلي والتقنيات الأخرى أكثر قليلاً - ولكن هذا خارج الموضوع).

سأعود إلى عالم DevOps والخدمات الصغيرة. نحن نواجه مشكلة كبيرة ، متنكرين في شكل فيل في Kunstkamera - لأن ما أسمعه في كثير من الأحيان هو "مجرد اتخاذ kubernetes والدفة ، وكل شيء سيكون على ما يرام!" ولكن لا ، لن يكون كل شيء على ما يرام إذا تُرك كل شيء كما هو. علاوة على ذلك ، لا يبدو الحل التحليلي لهذه المشكلة مقبولًا نظرًا للتعقيد. كما هو الحال في البرمجة اللغوية العصبية ، يجب أن نتعامل أولاً مع هذه المشكلة عن طريق تضييق نطاق البحث - في هذه الحالة ، من خلال إزالة التباديل القديمة.

أحد الأشياء التي يمكن أن تساعد - كتبت العام الماضيحول الحاجة إلى الحفاظ على الحد الأدنى من الانتشار بين الإصدارات الموضوعة للعملاء . من المهم أيضًا ملاحظة أن عملية CI / CD المتطورة مفيدة جدًا في تقليل الاختلافات. ومع ذلك ، فإن الوضع الحالي مع CI / CD ليس جيدًا بما يكفي لحل مشكلة التبديل دون أدوات إضافية لتسجيل المكونات وتتبعها.

ما نحتاج إليه هو نظام تجارب في مرحلة التكامل ، حيث يمكننا تحديد عامل الخطر لكل مكون ، ولدينا أيضًا عملية آلية لتحديث المكونات المختلفة والاختبار دون تدخل المشغل - لمعرفة ما يعمل وما لا يصلح.

قد يبدو نظام التجارب هذا كالتالي:

1. ( — — ).
2. () CI — , CI
3. « » CI - , . , . , — .
4. CD , « » . .

تلخيص ، بالنسبة لي ، فإن إحدى أكبر المشاكل الآن هي عدم وجود "نظام تكامل ذكي" من شأنه أن يربط المكونات المختلفة بالمنتج وبالتالي يسمح لك بتتبع كيفية تكوين المنتج ككل. سأكون مهتمًا بأفكار المجتمع حول هذا (المفسد - أعمل حاليًا على مشروع Reliza ، والذي يمكن أن يصبح نظامًا ذكيًا للتكامل).

آخر شيء أريد أن أذكره هو أنه بالنسبة لي لا يمكن قبول كتلة متجانسة لأي مشروع متوسط ​​الحجم على الأقل. بالنسبة لي ، هناك شك كبير في محاولات تسريع وقت التنفيذ وجودة التطوير من خلال العودة إلى المونوليث. أولاً ، لدى monolith مشكلة مماثلة في إدارة المكونات - من بين المكتبات المختلفة التي تتكون منها ، ومع ذلك ، فإن كل هذا ليس ملحوظًا ويتجلى في المقام الأول في الوقت الذي يقضيه المطورون. نتيجة المشكلة المتجانسة هي حقيقة أنه من المستحيل إجراء تغييرات على الكود - وسرعة التطوير بطيئة للغاية.

تعمل الخدمات الصغيرة على تحسين الوضع ، ولكن بعد ذلك تواجه بنية الخدمات الصغيرة مشكلة انفجار اندماجي في مرحلة التكامل. نعم ، بشكل عام ، لقد انتقلنا نفس المشكلة - من مرحلة التطوير إلى مرحلة التكامل. ومع ذلك ، في رأيي ، لا يزال نهج الخدمات الدقيقة يؤدي إلى نتائج أفضل ، وتحقق الفرق نتائج أسرع (ربما يرجع ذلك بشكل رئيسي إلى انخفاض حجم وحدة التطوير - أو حجم الدفعة ). ومع ذلك ، لم يقدم الانتقال من الخدمات المتجانسة إلى الخدمات الدقيقة حتى الآن تحسينًا كافيًا للعملية - يمثل الانفجار التوافقي لإصدارات الخدمات الصغيرة مشكلة كبيرة ، ولدينا إمكانات كبيرة لتحسين الوضع أثناء حله.