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

يا حبر! أقدم انتباهكم ترجمة المؤلف للمقالة الخدمات المصغرة – انفجار اندماجي للإصدارات.

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

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

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

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

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

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

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

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

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

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

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

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

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

المصدر: www.habr.com