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