الجميع يتحدث عن الخدمات الصغيرة الآن. لا يكتمل كل اجتماع أو مؤتمر أو اجتماع تقريبًا بدون قصة عن الخدمات الصغيرة ومدى جودتها ، وكيف تقلل من تعقيد المشروع ، وما إلى ذلك.
الرسالة الرئيسية لجميع هذه التقارير - الخدمات الصغيرة تساعد على الابتعاد عن التعقيد المفرط والتعقيد للمشروع. ولكن ، بالنسبة لي ، لا يمكنك التخلص من التعقيد على الإطلاق ، لا يمكنك إعادة المشروع بحيث يصبح كل شيء بسيطًا في الحال. الصعوبة من منطقة إلى أخرى.
على سبيل المثال: كان هناك مترابط معقد ومتشابك للغاية ، قمنا بتقسيمه إلى عدة خدمات ، كل منها يبدو رائعًا ، ويمكن لأي شخص معرفة الرمز ، ولكن ماذا يحدث للبيئة؟ يزداد التعقيد: فهذه المعاملات الموزعة التي تحتاج إلى تسجيل من أجل فهم أن هذه معاملة واحدة ؛ تضاف CI / CD والتسليم لكل خدمة ؛ يصبح مخطط التفاعل غير تافه.
أكثر الأطروحات أو التصريحات المثيرة للجدل التي سمعتها في التقارير والتي أنا على استعداد للتجادل معها:
يعد الدخول إلى مشروع مترابط أكثر تكلفة لأعضاء الفريق الجدد . لسبب ما ، من المعتاد تقييم تكلفة الانضمام إلى مشروع من خلال السرعة التي يبدأ بها المطور الجديد في أداء المهام. نعم ، سوف يكتشفها في خدمة صغيرة بسرعة كبيرة ويصدر المهمة بسرعة كبيرة (خاصة وفقًا للمواصفات ، "ما كتبوه ، ثم فعلت").
ولكن ماذا عن أعضاء الفريق الآخرين؟
سيتعامل المختبر الجديد مع نموذج التكامل. اختبار الخدمة جيد ، ولكن بالإضافة إلى اختبار عقد الخدمة ، تحتاج إلى التحقق من عملية الأعمال التي تؤثر على العديد من الخدمات.
في البداية ، قد يكسر المحلل الجديد رأسه ، حتى يفهم كل تعقيدات التحديات الداخلية.
تسمح لك الخدمات المصغرة بالافراج عن كثير من الأحيان . يتم تحسين الخدمات الصغيرة بشكل أسرع ، لأنها مقسمة إلى عدة مهام متوازية يتم تطويرها واختبارها بالتوازي ، ويبقى فقط للتحقق من التكامل (دون مراعاة وقت التحليلات).
يمكنك القيام بذلك باستخدام وحدة واحدة ، كل هذا يتوقف على تحلل المهمة. في معظم الأحيان ، في البداية ستكون هناك مهمة واحدة - لجعل الوظائف العامة (لتصحيح قاعدة البيانات العامة ، أو تعديل الواجهة) ، ثم سيرى الجميع مهامهم الفرعية وإعطائهم للاختبار.
وسيكون وقت إصدار الميزة الذي يدفعه النشاط التجاري هو نفسه. سيتم إغلاق الميزة فقط عندما يتم تحرير جميع المكونات. تستطيع الخدمات الصغيرة حل 99٪ من المهام ، ولكن حتى إغلاق الميزة الأخيرة ، لن يتم إطلاقها في المعركة.
ماذا لا يتحدثون عنه
الصعوبة تتزايد
عند استخدام الخدمات الصغيرة ، فإن
البنية التحتية معقدة . هذا يرجع إلى حقيقة أنك بحاجة إلى دعم عمل تطبيق واحد ، ولكن العديد من الخدمات. من الضروري مراقبة أداء جميع الخدمات ، لفهم تبعيات الخدمات حسب الإصدار جيدًا ، للحصول على خطط CI / CD لتجميع الخدمات والتسليم ، وآليات للاستجابة لفشل الخدمة حتى لا ينخفض كل شيء آخر.
يبدو أنها أشياء بسيطة ، ويجب علينا أن نفعل الشيء نفسه في وحدة واحدة. نعمل فقط في المونوليث على تطبيق واحد ، ومع زيادة عدد الخدمات ، ينمو التعقيد ، الأمر الذي يتطلب دعم مهارات أعلى.
تضيف الخدمات المصغرة تعقيدًا - مكتبات جديدة ووظائف جديدة لدعم المعاملات الموزعة ، للتعامل مع أخطاء الخدمات الأخرى ، وإرسال الطلبات المتكررة ، واسترجاع المعاملات. بالنسبة للجزء الأكبر ، ستكون هذه الآليات شائعة ، ولن يدخل معظم المطورين في الشجاعة ، ولكنهم سيستخدمونها فقط.
ولكن قد تكون هناك أخطاء فيها يجب إصلاحها. إذا تعاملنا مع الإصلاح دون أي مشاكل ، فعندئذٍ طرح التغييرات على خدمات 200-300 ، سيستغرق الأمر وقتًا ويضع ضوابط. وإذا كنت بحاجة إلى إعادة بناء الخدمات باستخدام المكتبة المحدثة ، أو حتى إعادة المكالمات (قاموا بإصلاحها بهذه الطريقة ، ولم يوفروها) ، فلن يكون كل هذا ممتعًا.
منليث - ليست كرة كبيرة من الطين
كيف تبدأ القصص عن عالم الخدمات الصغيرة الجميل عادة؟ "كان لدينا قطعة متجانسة ، كانت عبارة عن كتلة صلبة من الطين ، حيث كل شيء مربك وغير مفهوم" ، بالإضافة إلى أنهم سيظهرون صورة رهيبة. وأصبح المونوليث بالفعل شيئًا مخيفًا ، "ستعمل بشكل سيئ ، وسيتحول مشروعك إلى متراصة."
لكن لا.يمكن أن يكون المونوليث (ويجب) أن يكون واضحًا ومنظمًا ، مع رمز "جيد" ، مع وثائق ، تمامًا مثل مشروع الخدمات الصغيرة يمكن أن يتحول إلى كرة أكبر من التراب إذا لم تشارك في عمليات التطوير ولا تراقب جودة التطوير.
إذن ماذا تستخدم؟
سؤال جيد ، ويمكنك فقط الإجابة. لأنك أنت فقط تعرف ما هي المشاكل التجارية التي تقررها ، وماذا سيكون المشروع. لا توجد رصاصة فضية ، ولا توجد هندسة مثالية يمكن استخدامها وسيكون هناك دائمًا "السعادة".
وفي monolith ، وفي microservices ، اتبع الوثائق وأبقها محدثة. مع التوثيق أفضل من بدونه.
قم ببناء عملية تطوير ستنمو فيها جودة الشفرة فقط (المراجعات واختبارات الوحدة). ولكن حول الجودة يمكنك كتابة كتاب كامل ، هذا موضوع لمحادثة كبيرة منفصلة.
إن الكود البسيط والمفهوم ليس حول الخدمات المصغرة ، يجب أن يكون الكود مثل هذا بداهة.
أتمتة الاختبار هي أيضا عن جودة التعليمات البرمجية.
أتمتة كل شيء يمكنك أتمتة - CI / CD. ربما يكون هناك تكدس تكنولوجي يصعب جدًا سحبه إلى CI / CD ، ولكن يمكن أتمتة 99٪ من التجميعات / عمليات التسليم.