تعد الخدمات المصغرة أسلوباً تصميمياً شائعاً لإنشاء تطبيقات تتسم بالمرونة وقابلية التوسع بدرجة كبيرة وقابلة للنشر بشكل مستقل وقابلة للتطور بسرعة. ولكن بنية الخدمات المصغرة الناجحة تتطلب نهجاً مختلفاً لتصميم التطبيقات وبناءها.
يتكون تصميم الخدمات المصغرة من مجموعة من الخدمات الصغيرة المستقلة. كل خدمة قائمة بذاتها ويجب أن تنفذ قدرة عمل واحدة ضمن سياق محدود. السياق المحدود هو تقسيم طبيعي داخل الأعمال ويوفر حدًا واضحًا يوجد ضمنه نموذج المجال.
ما الخدمات المصغرة؟
الخدمات المصغرة صغيرة ومستقلة وغير مرتبطة بصورة وثيقة. يمكن لفريق واحد صغير من المطورين كتابة خدمة والحفاظ عليها.
كل خدمة عبارة عن قاعدة بيانات منفصلة، والتي يمكن لفريق تطوير صغير إدارتها.
يمكن توزيع الخدمات بشكل مستقل. يمكن للفريق تحديث خدمة موجودة بدون إعادة إنشاء التطبيق بالكامل وإعادة توزيعه.
الخدمات مسؤولة عن استمرار بياناتها الخاصة أو الحالة الخارجية. هذا يختلف عن النموذج التقليدي، حيث تتعامل طبقة بيانات منفصلة مع استمرار البيانات.
تتواصل الخدمات مع بعضها البعض باستخدام واجهات برمجة تطبيقات محددة جيداً. تفاصيل التنفيذ الداخلي لكل خدمة مخفية عن الخدمات الأخرى.
يدعم برمجة متعددة اللغات. على سبيل المثال، لا تحتاج الخدمات إلى مشاركة نفس مكدس الذاكرة المؤقتة للتكنولوجيا أو المكتبات أو أطر العمل.
إلى جانب الخدمات نفسها، تظهر بعض المكونات الأخرى في بنية نموذجية للخدمات المصغرة:
الإدارة/ التنسيق. كون ذلك المكون مسؤولاً عن وضع الخدمات على العقد، وتحديد حالات الفشل، وإعادة موازنة الخدمات عبر العقد، وما إلى ذلك. عادةً ما يكون هذا المكّون عبارة عن تقنية جاهزة مثل Kubernetes، وليس شيئاً مخصصاً.
بوابة واجهة برمجة التطبيقات. تُعد بوابة واجهة برمجة التطبيقات هي نقطة الإدخال للعملاء. بدلاً من الاتصال بالخدمات مباشرةً، يقوم العملاء بالاتصال ببوابة واجهة برمجة التطبيقات، والتي تقوم بإعادة توجيه المكالمة إلى الخدمات المناسبة في النهاية الخلفية.
تتضمن المزايا إمكانية استخدام بوابة واجهة برمجة التطبيقات ما يلي:
إنها تفصل العملاء عن الخدمات. يمكن إصدار الخدمات أو إعادة هيكلتها دون الحاجة إلى تحديث كافة العملاء.
يمكن أن تستخدم الخدمات بروتوكولات المراسلة غير الملائمة للويب، مثل AMQP.
يمكن لبوابة واجهة برمجة التطبيقات أداء وظائف شاملة أخرى مثل المصادقة، والتسجيل، وإنهاء SSL، وموازنة التحميل.
السياسات الجاهزة، مثل التحكم بالنطاق الترددي، أو التخزين المؤقت، أو التحويل، أو التحقق من الصحة.
المزايا
البراعة والتحكم. نظرًا إلى توزيع الخدمات المصغرة بشكل مستقل، فمن الأسهل إدارة إصلاحات الأخطاء وإصدارات الميزات. يمكنك تحديث الخدمة دون إعادة توزيع التطبيق بأكمله، واستعادة التحديث إذا حدث خطأ ما. في العديد من التطبيقات التقليدية، إذا تم العثور على خطأ في جزء ما من التطبيق، فإنه يمكن حظر عملية الإصدار بأكمله. قد يتم تعليق الميزات الجديدة في انتظار تكامل إصلاح الأخطاء واختبارها ونشرها.
فرق صغيرة وموجهة. يجب أن تكون الخدمة المصغرة صغيرة بما يكفي أن فريق ميزات واحدًا يمكنه إنشاؤها واختبارها ونشرها. أحجام الفرق الصغيرة تعزز خفة البراعة والتحكم. تميل الفرق الكبيرة إلى أن تكون أقل إنتاجية، لأن الاتصال يكون أبطأ، وزيادة النفقات الإدارية، وتقل البراعة والتحكم.
قاعدة تعليمة برمجية بسيطة. في التطبيق الأحادي، ثمة ميل بمرور الوقت إلى تشابك تبعيات التعليمات البرمجية. تتطلب إضافة ميزة جديدة لمس تعليمة برمجية في كثير من الأماكن. ومن خلال عدم مشاركة التعليمات البرمجية أو مخازن البيانات، تقلل بنية الخدمات المصغرة التبعيات، مما يسهل إضافة ميزات جديدة.
مزيج من التقنيات. يمكن للفرق اختيار التكنولوجيا التي تناسب خدمتها بشكل أفضل، وذلك باستخدام مزيج من مجموعات التكنولوجيا حسب الاقتضاء.
عزل الخطأ. إذا أصبحت الخدمة المصغرة الفردية غير متوفرة، فلن تعطل التطبيق بأكمله، طالما تم تصميم أي خدمات مصغرة في المصدر للتعامل مع الأخطاء بشكل صحيح. على سبيل المثال، يمكنك تنفيذ نمط قاطع الدائرة، أو يمكنك تصميم الحل الخاص بك بحيث تتواصل الخدمات المصغرة مع بعضها باستخدام أنماط المراسلة غير المتزامنة.
قابلية التوسع. يمكن توسيع نطاق الخدمات بشكل مستقل، مما يتيح لك توسيع نطاق الأنظمة الفرعية التي تتطلب المزيد من الموارد، دون توسيع نطاق التطبيق بأكمله. باستخدام منسق مثل Kubernetes، يمكنك حزم كثافة أعلى من الخدمات على مضيف واحد، ما يسمح باستخدام الموارد بشكل أكثر كفاءة.
عزل البيانات. من السهل بكثير إجراء تحديثات المخطط، لأن ما يتأثر هو خدمة مصغرة واحدة فقط. في تطبيق متجانس، يمكن أن تصبح تحديثات المخطط صعبة للغاية، لأن أجزاء مختلفة من التطبيق قد تلمس جميعها نفس البيانات، ما يجعل أي تعديلات على المخطط محفوفة بالمخاطر.
التحديات
لا تأتي مزايا الخدمات المصغرة مجاناً. موضح فيما يلي بعض التحديات التي يجب مراعاتها قبل الشروع في معمار الخدمات المصغرة.
التعقيد. يحتوي تطبيق الخدمات المصغرة على أجزاء متنقلة أكثر من التطبيق المتجانس المكافئ. كل خدمة أبسط، ولكن النظام بأكمله أكثر تعقيدًا.
التطوير والاختبار. تتطلب كتابة خدمة صغيرة تعتمد على خدمات تابعة أخرى نهجاً مختلفاً عن كتابة تطبيق تقليدي مترابط أو متعدد الطبقات. لا تعد الأدوات الحالية مصممة دائماً للعمل مع تبعيات الخدمة. قد يكون من الصعب إعادة بناء التعليمات البرمجية عبر حدود الخدمة. من الصعب أيضاً اختبار تبعيات الخدمة، خاصةً عندما يتطور التطبيق بسرعة.
انعدام الإدارة. إن النهج اللامركزي في إنشاء الخدمات المصغرة له مزايا، ولكنه يمكن أن يؤدي أيضًا إلى مشكلات. قد ينتهي بك الأمر إلى العديد من اللغات والأطر المختلفة التي يصبح من الصعب للتطبيق الحفاظ عليها. وقد يكون من المفيد تطبيق بعض المعايير على نطاق المشروع، دون الإفراط في تقييد مرونة الفرق. ينطبق ذلك بشكل خاص على الوظائف الشاملة مثل التسجيل.
ازدحام الشبكة وزمن الانتقال. استخدام العديد من الخدمات الصغيرة، متعددة المستويات يمكن أن يؤدي إلى مزيد من الاتصال المشترك للخدمات. أيضاً، إذا كانت سلسلة تبعيات الخدمة طويلة جدًا (الخدمة A تستدعي B، والتي تستدعي C...)، يمكن أن يصبح زمن الانتقال الإضافي مشكلة. سوف تحتاج إلى تصميم واجهات برمجة التطبيقات بعناية. تجنب واجهات برمجة التطبيقات (API) المبالغة في الدردشة، وفكر في تنسيقات التسلسل، وابحث عن أماكن لاستخدام أنماط الاتصال غير المتزامن مثل تسوية التحميل على أساس قائمة الانتظار.
تكامل البيانات. مع كل خدمة مصغرة مسؤولة عن استمرارية البيانات الخاصة بها. ونتيجة لذلك، يمكن أن يكون اتساق البيانات تحديًا. تبنى الاتساق النهائي حيثما كان ذلك ممكنًا.
الإدارة. لتحقيق النجاح مع الخدمات المصغرة، يتطلب الأمر ثقافة DevOps ناضجة. يمكن أن يكون التسجيل المترابط عبر الخدمات أمرًا صعبًا. يجب أن يربط التسجيل استدعاءات الخدمة المتعددة لعملية مستخدم واحد.
تعيين الإصدار. يجب ألا تؤدي تحديثات خدمة ما إلى قطع الخدمات التي تعتمد عليها. يمكن تحديث العديد من الخدمات في أي وقت، لذلك بدون تصميم دقيق، قد تواجه مشكلات في التوافق مع الإصدارات السابقة أو القادمة.
مجموعة المهارات. الخدمات المصغرة هي أنظمة موزعة بشكل كبير. قم بتقييم ما إذا كان الفريق يمتلك المهارات والخبرات اللازمة للنجاح.
عملية بناء بنية الخدمات المصغرة
تقدم المقالات المذكورة هنا نهجاً منظماً لتصميم وبناء وتشغيل بنية الخدمات المصغرة.
تحليل المجال. لتجنب بعض المزالق الشائعة عند تصميم الخدمات المصغرة، استخدم تحليل المجال لتحديد حدود الخدمة المصغرة. اتبع الخطوات التالية:
- استخدم تحليل المجال لنمذجة الخدمات المصغرة.
- استخدم DDD التكتيكي لتصميم الخدمات المصغرة.
- حدد حدود الخدمات المصغرة.
تصميم الخدمات تتطلب الخدمات المصغرة نهجاً مختلفاً لتصميم التطبيقات وبناءها. لمزيد من المعلومات، قم بمراجعةتصميم بناء الخدمات المصغرة.
تعمل في الإنتاج. نظراً لتوزيع بنيات الخدمات المصغرة، يجب أن يكون لديك عمليات قوية للتوزيع والمراقبة.
- CI/CD لبنيات الخدمات الصغيرة
- إنشاء البنية الأساسية لبرنامج ربط العمليات التجارية للتكامل المستمر/ التسليم المستمر للخدمات المصغرة على Kubernetes
- مراقبة الخدمات المصغرة التي تعمل على خدمة Azure Kubernetes (AKS)