هناك شعور بأن الخدمات الدقيقة غالبًا ما يتم وضعها على أنها "رصاصة فضية" لتحل محل المونوليث. ولكن لا يحب الجميع هذا النهج. في الواقع ، يتم استخدامه في بعض الأحيان بشكل غير صحيح أو غير مناسب. فيما يلي أمثلة على المشكلات التي كنت "محظوظًا" في مواجهتها عند استخدام الخدمات الدقيقة في شركات مختلفة والتي لا أريد تكرارها في المستقبل.
قابلية الوهمية
ميزة كبيرة من نهج الخدمات الصغيرة هي قابلية التوسع. يعتبر التدفق الكبير غير المحدود للمستخدمين والحمل العالي أمرًا لا مفر منه. وبسبب هذا ، يتم إنفاق الكثير من الوقت على التحسين الأولي ، وليس على ميزات الأعمال المفيدة. في الواقع ، الأحمال العالية ليست موجودة دائمًا.
الضحية الأولى للتحسين المسبق هي عملية الأعمال الخطية. يتحلل إلى العديد من الخدمات الدقيقة. نوع من الاحتياطي للمستقبل لأسباب تقسيم المسؤوليات أو التحجيم الوهمي. ونتيجة لذلك ، يصبح من الصعب على الشركات التنقل في مجال تكنولوجيا المعلومات والتحدث بنفس لغة تكنولوجيا المعلومات ، ناهيك عن مشاكل التنقل في شفرة المصدر للمطورين أنفسهم.
مشكلات تفاعل الخدمة
تنتشر الخدمات المستلمة من monorep في مستودعات منفصلة. الخدمات نفسها أصبحت أكثر صعوبة للربط معا. في هذه الحالة ، قد يبدأ إصدار API microservice بالانحراف عن إصدار API نفسه في عملاء الخدمات الصغيرة. ثم يتم استبدال JSON القديم الجيد بـ Protobuf ، و HTTP بـ gRPC للحصول على الأداء والكتابة والإصدار المناسب لواجهة برمجة التطبيقات.
لسوء الحظ ، فإن الحلول مثل gRPC + Protobuf ليست خالية من الأخطاء. يمكن أن تتعطل الخدمات باستمرار بسبب انتشار خطأ وعدم تطابق إدخال / إخراج خدمة معروف. يزداد حجم قاعدة التعليمات البرمجية ، وخدمات التصحيح أكثر صعوبة بكثير من البيانات العادية ، مما يجلب معها مجموعة جديدة كاملة من المشاكل.
يجب حل هذه المشكلة من خلال عملية اختبار عادية. على وجه الخصوص ، اختبارات التكامل. ولكن يجب كتابة اختبارات التكامل وتشغيلها لكل خدمة صغيرة ومجموعتها كجزء من عملية الأعمال. هذه مهمة صعبة نوعًا ما لا يرغبون عادةً في تخصيص وقت إضافي لها. في هذه الحالة ، يمكن تقليل اختبار تكامل الخدمات المصغرة إلى شكل اختبار وحدة للوحدة.
قيود وعادات قديمة
مع كل هذا ، فإن القيود المعتادة على متراصة تتجول في الخدمات الصغيرة. أمثلة حية: لغة برمجة واحدة وقاعدة بيانات واحدة لجميع الخدمات الصغيرة. في الحالة الأولى ، هذا هو القيد السابق على المونوليث ، في الحالة الثانية ، إنه إرث يسعى إلى أن يصبح "عنق الزجاجة" للنظام بأكمله. نظرًا لحقيقة أن المطورين والإدارة لا يقبلون إمكانية وجود نظام غير متجانس مبني بلغات برمجة مختلفة ، فإن إمكانية اختيار الأدوات المناسبة لحل المشكلات العاجلة تضيع.
بالإضافة إلى ما سبق ، قد لا يكون للخدمات الصغيرة الفردية المطورين المسؤولين عنها. يبدأ الجميع في دعم كل شيء ، ولا أحد مسؤول عن أي شيء. في هذه الحالة ، لا أحد لديه معرفة حول تشغيل الخدمات الفردية باستثناء آخر شخص قام بتغيير رمزه. هناك عدم تزامن للمطورين ، وفقدان فهم جوهر عمل الخدمات الصغيرة فيما يتعلق بالمهام التي تم حلها داخل مجال الموضوع.
بيروقراطية البنية التحتية
يصعب الحفاظ على الخدمات الصغيرة أكثر من متجانسة. تصبح البنية التحتية التي كانت تمثل زوجًا من الخوادم سحابة خاصة صغيرة. يستغرق المطورون وقتًا طويلاً لدعم هذه الحلول ويخلق مشاكل للإدارة في المستقبل. تظهر حاجة بعيدة المنال لبيروقراطية إضافية. يتم تعيين الموظفين الأفراد ، ويتم إنشاء عمليات منفصلة.
في مثل هذه الحالات ، يمكن الكشف عن مجموعات القواعد للعمل مع الخدمات الصغيرة للحفاظ على سلامة حلقة الخدمات الصغيرة. أسوأ حالة هو رفض حتى إمكانية تشغيل برنامج نصي لمرة واحدة أو ترحيل ، مما يمنع الوصول المباشر إلى الدائرة. خلاصة القول هي أن البرنامج النصي تم تصميمه كخدمة كاملة ، مضيفًا سطرًا إضافيًا إلى قائمة الخدمات الصغيرة الطويلة.
مستقبل
والنتيجة هي نظام به ضوضاء أكثر من الإشارة المفيدة. في كل مكان - من البنية التحتية إلى رمز خدمة معينة. من فهم المطور لمخطط تفاعل الخدمة إلى إدارة الشركة. يصبح المبرمجون عن غير قصد سيدًا في حل الألغاز.
بالطبع ، المونوليث الكلاسيكي ليس أفضل. إنه بطيء ، ويحافظ على حالته ، ويصعب معالجته ، ولا يشمله اختبار الوحدة أو التكامل ، إلخ. ولكن يمكننا أن نفعل ما هو أفضل! بفضل أزياء الخدمات الصغيرة ، رأينا ارتفاعًا في CI / CD بين العديد من الإيجابيات الأخرى وعملنا على الاختبار. يمكننا الآن تطبيقها على طرق أخرى أيضًا ، وليس فقط الخدمات الدقيقة.
في المرة القادمة التي تقوم فيها بتطوير نظام جديد أو إعادة تدوير نظام قديم ، مهما كان حجمه ، فكر مرتين. هل تحتاج الشركة قابلية التوسع؟ هل تحتاج إلى القدرة على التعامل مع الأحمال العالية؟ هل أنت مستعد بالفعل للخدمات الصغيرة بنفسك؟ أم من الأفضل أن تبدأ ببنى معمارية أكثر تحفظًا؟
ربما لا تبني صاروخًا ، بل تصنع سكوترًا بسيطًا ، لأنك تحتاج فقط إلى نهاية الشارع؟