ما أنماط تصميم الخدمات المصغرة؟

توفِّر أنماط البنية هذه حلولًا معيارية للتحديات اليومية التي تواجه فرق التطوير عند تنفيذ أنظمة الحوسبة الموزعة، بما في ذلك التواصل بين الخدمات، واتساق البيانات، وتحمل الأخطاء، وقابلية توسُّع النظام.

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

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

وفقًا لاستطلاع أجرته IBM بعنوان، Microservices in the Enterprise, 2021، أفادت 88% من المؤسسات أن الخدمات المصغرة تقدِّم العديد من الفوائد لفرق التطوير. تشمل هذه الفوائد زيادة في إنتاجية المطورين بنسبة 20 إلى 50% نتيجةً لتحسين تنظيم الكود، وسهولة الصيانة، وتسريع دورات النشر.

بنية الخدمات المصغرة هي طريقة سحابية الأصل تعمل على تقسيم التطبيقات إلى خدمات مستقلة ومترابطة بشكل ضعيف يتم نشرها في حاويات وتُدار بواسطة منصات التنسيق مثل Kubernetes.

تعمل كل خدمة بشكل مستقل باستخدام مجموعة التكنولوجيا الخاصة بها، بما في ذلك قواعد بيانات ونماذج إدارة البيانات المخصصة لها. يحدث التواصل بين الخدمات عبر واجهات برمجة التطبيقات REST ومنصات بث الأحداث مثل Apache Kafka ووسطاء الرسائل، بينما تصمِّم الفرق الخدمات حول قدرات الأعمال مع حدود واضحة تُعرَف باسم السياقات المحددة.

يدعم هذا النهج الحديث في تطوير البرمجيات المرونة التشغيلية المطلوبة لمبادرات التحول الرقمي الحديثة، مثل أتمتة عمليات التطوير ومسارات التكامل المستمر/النشر المستمر، والترحيل إلى السحابة، وتحديث التطبيقات، وتكامل الذكاء الاصطناعي (AI).

رغم أن الخدمات المصغرة تقدِّم مزايا كبيرة للتطبيقات الحديثة، فإن فهم متى يجب اختيار هذا النوع من البنية يتطلب مقارنته بالنهج الأحادي التقليدي.

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

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

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

عند اتخاذ القرار بشأن النهج المناسب، يجب على المؤسسات تقييم كل خيار وفق متطلباتها الخاصة، بما في ذلك حجم الفريق، وتعقيد التطبيق، واحتياجات قابلية التوسع، ومستويات نضج عمليات التطوير.

تعرَّف أكثر على البنية الأحادية مقابل الخدمات المصغرة.

تنتشر أنماط تصميم الخدمات المصغرة عبر خمسة مجالات رئيسية توفِّر حلولًا مجربة تساعد الفرق على مواجهة تحديات البنية الموزعة:

1. الاتصال بالخدمة واكتشافها
2. إدارة البيانات والمعاملات
3. المرونة والتعامل مع الأعطال
4. البنية والتكامل
5. الحدث والتواصل

نمط سجل الخدمات

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

نمط بوابة واجهة برمجة التطبيقات

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

على سبيل المثال، عند تحميل صفحة منتج، يمكن للبوابة جلب تفاصيل المنتج والسعر والمخزون والتقييمات من خدمات مختلفة في الوقت نفسه. ثم تُعيد كل هذه المعلومات في استجابة واحدة موحَّدة إلى العميل.

نمط اكتشاف الخدمات

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

نمط قاعدة البيانات لكل خدمة

يضمن نمط قاعدة البيانات لكل خدمة أن تمتلك كل خدمة مصغرة قاعدة بياناتها الخاصة وتُديرها بنفسها، ما يُلغي الاعتماد على البيانات المشتركة بين الخدمات. يمنع هذا النهج الوصول المباشر للبيانات بين الخدمات ويقلل الترابط، لكنه يتطلب من الخدمات التواصل عبر واجهات برمجة التطبيقات عندما تحتاج إلى معلومات من مصادر أخرى. على سبيل المثال، في نظام تخطيط موارد المؤسسات (ERP)، تُدير خدمة المحاسبة البيانات المالية بشكل مستقل عن قاعدة بيانات الموظفين الخاصة بخدمة الموارد البشرية.

نمط المعاملات الموزعة (Saga)

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

نمط فصل مسؤوليات الأوامر والاستعلامات (نمط CQRS)

يعمل نمط CQRS على فصل تعديل البيانات (الأوامر) عن استرجاع البيانات (الاستعلامات) باستخدام نماذج مخصصة لكلٍّ منهما. يُتيح هذا التقسيم للنظام تحسين كل مسار بشكل مستقل - مع تقليل التنافس على الكتابة في جانب الأوامر وتقليل زمن الانتقال في جانب القراءة. في نظام التجارة الإلكترونية، يتم استخدام نموذج الأوامر المحسَّن للكتابة عند تقديم طلب، بينما يتم الاستفادة من نموذج الاستعلام المحسَّن للقراءة عند إعداد تقرير المبيعات.

نمط قاطع الدائرة

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

على سبيل المثال، إذا توقفت خدمة المخزون عن العمل، يعمل نمط قاطع الدائرة على منع خدمة الطلب من إرسال طلبات فاشلة متكررة. يسمح ذلك لبقية النظام باستمرار العمل مع توفير استجابات احتياطية للعملاء.

نمط الحواجز العازلة

يعزل نمط الحواجز العازلة موارد النظام لمنع فشل جزء واحد من التأثير في النظام بأكمله. مثل الحواجز في هيكل السفينة، تفصل الحواجز العازلة بين الوظائف المختلفة بحيث إذا فشل أحدها، تظل الأخرى تعمل. ويَحُدّ هذا النمط من عدد الطلبات أو الموارد المتزامنة المخصصة لخدمات معينة.

نمط الواجهة الخلفية للواجهة الأمامية (BFF)

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

نمط الكيان والتجميع

ينظِّم نمط الكيان والتجميع البيانات المرتبطة في وحدات منطقية استنادًا إلى مفاهيم التصميم القائم على المجال (DDD). يمثِّل الكيان شيئًا مميزًا له هوية فريدة، مثل حساب عميل يتم التعرُّف عليه بواسطة عنوان البريد الإلكتروني. يعمل التجميع على دمج الكيانات المرتبطة التي يجب تحديثها معًا كوحدة واحدة.

على سبيل المثال، في نظام التجارة الإلكترونية، يشمل تجميع الطلب تفاصيل الطلب، وعناصر الطلب، ومعلومات الشحن، وكلها يجب أن تظل متزامنة عند حدوث تغييرات.

نمط الخانق (Strangler)

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

النمط القائم على الأحداث

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

نمط الحاوية الجانبية (Sidecar)

يشير نمط الحاوية الجانبية إلى نشر حاوية ثانوية (Sidecar) بجانب التطبيق أو الخدمة الرئيسية في بيئة التنفيذ نفسها. تتولى هذه الحاوية الجانبية معالجة الاهتمامات المشتركة (مثل التسجيل، والمراقبة، والأمن، وقابلية الملاحظة)، لتوسيع وظائف التطبيق الرئيسي دون تعديل قاعدة تعليماته البرمجية.

نمط الخدمات المصغرة للمحوِّل

يُتيح نمط الخدمات المصغرة للمحوِّل الاتصال بين الأنظمة أو الواجهات غير المتوافقة. مثلما يُتيح لك محوِّل السفر توصيل جهازك بمقابس كهربائية أجنبية، يعمل نمط المحوِّل على تحويل البيانات بين تنسيقات أو بروتوكولات أو واجهات برمجة تطبيقات مختلفة. يكون هذا النمط مفيدًا عند التكامل مع الأنظمة القديمة أو الخدمات الخارجية التي تستخدم معايير اتصال مختلفة.

تُعَد أنماط تصميم الخدمات المصغرة ذات قيمة كبيرة في الصناعات التي تتطلب قابلية توسُّع عالية ومنطق أعمال معقد وأداء موثوق به للنظام. تتضمن أفضل حالات الاستخدام ما يلي:

• تعتمد منصات التجارة الإلكترونية على أنماط تصميم الخدمات المصغرة لإدارة موازنة التحميل خلال أحداث المبيعات والتعامل مع المخزون المعقد عبر مستودعات متعددة. كما تنسِّق عمليات الدفع والشحن وخدمة العملاء عبر أنظمة مختلفة لتحقيق نتائج أعمال أفضل وتجارب متميزة للعملاء.
• تستخدم خدمات البث أنماط الخدمات المصغرة لتقديم المحتوى عالميًا مع إدارة تفضيلات المستخدمين والتوصيات، ما يمكِّنها من التعامل مع أعداد ضخمة من المستخدمين في الوقت نفسه مع تقليل التخزين المؤقت وتقديم تجارب مخصصة.
• تطبِّق الخدمات المالية هذه الأنماط لفصل عمليات التداول وإدارة المخاطر والمصادقة والعمليات الموجَّهة للعملاء، مع الحفاظ على الامتثال الصارم للوائح التنظيمية والمعايير الأمنية التي تتطلبها المؤسسات المالية.
• تستخدم أنظمة الرعاية الصحية هذه الأنماط لدمج سجلات المرضى وأنظمة جدولة المواعيد والفوترة، مع الحفاظ على الامتثال لمتطلبات HIPAA والربط مع واجهات برمجة تطبيقات الأجهزة الطبية عبر مختلَف مقدِّمي الرعاية الصحية.
• تستخدم منصات التواصل الاجتماعي أنماط تصميم الخدمات المصغرة لتوسيع نطاق المراسلة، وتغذية المحتوى، ومعالجة الوسائط بشكل مستقل، ما يُتيح لها التعامل مع المليارات من التفاعلات اليومية مع الحفاظ على الأداء السريع عبر جميع الميزات.

توفِّر أنماط تصميم الخدمات المصغرة أفضل الممارسات لإدارة الأنظمة الموزعة المعقدة اليوم وتقدِّم هذه الفوائد واسعة النطاق:

• تقليل التعقيد: تؤدي الأساليب الموحَّدة والمختبرة للتحديات الشائعة إلى نتائج أكثر قابلية للتوقع، وسهولة أكبر في استكشاف الأخطاء وإصلاحها، وتسريع دمج الفرق الجديدة.
• المرونة وتسريع الوصول إلى السوق: يمكن للفرق تطوير الخدمات ونشرها وتوسيعها بشكل مستقل، ما يقلل من عوائق التنسيق ويسرِّع من تسليم المزايا الجديدة.
• تعزيز تحمُّل الأعطال: تمنع تقنيات العزل الأعطال من الانتشار عبر النظام بأكمله، ما يقلل بشكل كبير من فترة التعطل ويحسِّن موثوقية النظام ككل.
• تحسين قابلية التوسع والمرونة: يمكن للمؤسسات تخصيص الموارد بدقة عند الحاجة، والتكيف بسرعة مع متطلبات الأعمال المتغيرة دون الحاجة إلى إعادة هيكلة كبيرة للنظام. يمكن للفرق تطوير الخدمات بلغات برمجة مختلفة، مثل Java أو Python، استنادًا إلى الاحتياجات المحددة.
• كفاءة التكلفة: يؤدي التوسع المستهدف وتحسين الموارد، إلى جانب القدرة على اختيار مجموعات التكنولوجيا المثالية للخدمات المحددة، إلى إنشاء أنظمة أكثر اقتصادًا.
• التنوع التقني: يمكن للفرق اختيار أفضل الأدوات وأطر العمل لمتطلبات كل خدمة محددة ما يؤدي إلى حلول أكثر كفاءة وقابلية للصيانة. على سبيل المثال، يمكنك تحديد Java Spring Boot للخدمات المصغرة للمؤسسات لقاعدة البيانات كخدمة (DBaaS) أو Python لتحليلات البيانات.

يعتمد اختيار الأنماط المناسبة على متطلبات نظامك المحددة والقدرات التنظيمية. كما أن استخدام نهج منهجي قد يساعد على توجيه هذه القرارات المتعلقة بالبنية.

ابدأ باستخدام بوابة واجهة برمجة التطبيقات واكتشاف الخدمات قبل تنفيذ الأنماط المعقدة مثل تحديد مصادر الأحداث أو CQRS. تُنشئ هذه الأنماط الأساسية البنية التحتية للاتصالات اللازمة لإجراء عمليات تنفيذ أكثر تطورًا.

ضع في اعتبارك تجربتك مع الأنظمة الموزعة، والنضج التشغيلي، وممارسات عمليات التطوير. تستفيد الفرق الجديدة في مجال الخدمات المصغرة في البداية من الأنماط الأكثر بساطة، بينما يمكن للفرق ذات الخبرة التعامل مع أنماط التنسيق الأكثر تقدمًا والتي تتطلب معرفة تشغيلية أعمق.

يقدم كل نمط تعقيدًا يجب على فريقك إدارته على المدى الطويل. تتطلب قاعدة البيانات لكل خدمة استراتيجيات مزامنة البيانات. تحتاج الأنماط القائمة على الأحداث إلى بنية تحتية لوسيط الرسائل. تأكَّد من أن لديك القدرة على دعم الأنماط التي اخترتها.

ابدأ ببعض الخدمات باستخدام الأنماط الأساسية، واكتسِب الخبرة، ثم توسَّع مع نمو خبرتك. يمنع هذا النهج التدريجي الإفراط في البنية ويسمح بالتعلم من عمليات التنفيذ المبكرة.