يبدو أن ذروة الضجيج لخدمات micros وراء. لم نعد نقرأ المنشورات "كيف نقلت متجولتي إلى 150 خدمة" عدة مرات في الأسبوع. الآن أسمع غالبًا أفكارًا معقولة: "أنا لا أكره المتراصة ، بل أهتم بالكفاءة". لاحظنا حتى العديد من الهجرات من الخدمات الصغيرة العودة إلى متراصة . عند الانتقال من تطبيق كبير إلى عدة خدمات أصغر ، سيتعين عليك حل العديد من المشكلات الجديدة. نحن قائمة لهم لفترة وجيزة ممكن.

التركيب: من الكيمياء الأساسية إلى ميكانيكا الكم

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

النظام ليس من السهل فهمه.

دعنا نتوقف للحظة على صغارنا. مع التطبيقات المتجانسة ، في حالة وجود خطأ ، كان من السهل تتبعها والانتقال مباشرة إلى تصحيح الأخطاء. الآن لدينا خدمة تتحدث إلى خدمة أخرى تضع قائمة انتظار على شيء ما في ناقل الرسائل الذي يعالج خدمة أخرى - ثم يحدث خطأ. يجب أن نجمع كل هذه الأجزاء حتى نكتشف في النهاية أن الخدمة A قيد التشغيل في الإصدار 11 ، والخدمة E تنتظر بالفعل الإصدار 12. وهذا يختلف تمامًا عن سجلي الموحد القياسي: عليك استخدام جهاز طرفي مصحح / مصحح تفاعلي لإجراء العملية خطوة بخطوة. أصبح التصحيح والفهم في جوهره أكثر صعوبة.

إذا لم تتمكن من تصحيح الأخطاء ، فسنختبرها

التكامل المستمر والتنمية المستمرة أصبحت الآن شائعة. تقوم معظم التطبيقات الجديدة التي أراها مع كل إصدار جديد بإنشاء الاختبارات وتشغيلها تلقائيًا وتتطلب اجتياز الاختبارات ومراجعتها قبل التسجيل. هذه عمليات ممتازة لا يمكن التخلي عنها ؛ فقد أصبحت تحولًا كبيرًا للعديد من الشركات. ولكن الآن ، لاختبار هذه الخدمة حقًا ، يجب أن أرفع نسخة العمل الكاملة لطلبي. تذكر أن المهندس الجديد مع مجموعة K8 من 150 خدمات؟ حسنًا ، سنقوم الآن بتعليم نظام CI الخاص بنا كيفية رفع كل هذه الأنظمة للتحقق من أن كل شيء يعمل حقًا. قد يكون هذا جهدًا كبيرًا للغاية ، لذلك سنقوم باختبار كل جزء على حدة: أنا متأكد من أن مواصفاتنا جيدة بما فيه الكفاية وأن واجهات برمجة التطبيقات نظيفة وأن فشل الخدمة معزول ولن يؤثر على الآخرين.

جميع الحلول الوسط لها سبب وجيه. صحيح؟

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

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