البرنامج التعليمي للخدمات المصغرة: ما هو، Archiالبنية والمثال

ما هي الخدمات المصغرة؟

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

يشير مصطلح "الخدمات المصغرة" إلى حجم الخدمة المصغرة، بحيث يمكن لفريق تطوير واحد (من 5 إلى 10 مطورين) إدارتها. في هذه المنهجية، تُقسّم التطبيقات الكبيرة إلى أصغر الوحدات المستقلة.

ما هو متجانسة Archiتكنولوجيا؟

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

متكشف عن وحدة متراصة Archiبنية تطبيق التجارة الإلكترونية

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

ما هي الخدمة المصغرة Archiتكنولوجيا؟

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

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

Microservices Architecture

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

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

الخدمات المصغرة مقابل المتجانسة Architecture

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

تحديات الخدمات المصغرة

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

SOA مقابل الخدمات الصغيرة

تُدار خدمات بنية الخدمات الموجهة (SOA) في المؤسسة بواسطة سجل يعمل كدليل. تحتاج التطبيقات إلى البحث عن الخدمات في السجل واستدعاء الخدمة. بعبارة أخرى، الخدمية يشبه تمامًا الأوركسترا حيث يؤدي كل فنان بآلاته بينما يقوم مدير الموسيقى بإعطاء التعليمات للجميع.

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

معامل	الخدمية	Microservices
نوع التصميم	في SOA، تتعرض مكونات البرنامج للعالم الخارجي لاستخدامها في شكل خدمات.	تعد الخدمة الصغيرة جزءًا من SOA. إنه تطبيق SOA.
التبعية	وحدات الأعمال تعتمد.	إنهم مستقلون عن بعضهم البعض.
حجم البرنامج	حجم البرنامج أكبر من أي برنامج تقليدي.	حجم البرمجيات يكون صغيراً دائماً في بنية الخدمات المصغرة.
كومة التكنولوجيا	مكدس التكنولوجيا أقل مقارنة بـ Microservice.	يمكن أن تكون حزمة تكنولوجيا الخدمات الصغيرة كبيرة جدًا.
طبيعة التطبيق	متجانسة بطبيعتها.	هو مطور برامج متكامل.
مستقلة والتركيز	تم تصميم تطبيقات SOA لأداء مهام عمل متعددة.	لقد تم تصميمها لأداء مهمة عمل واحدة.
التنفيذ	عملية النشر تستغرق وقتاً طويلاً.	النشر بسيط ويستغرق وقتًا أقل.
الفعالية من حيث التكلفة	أكثر تكلفة فعالة.	Less فعاله من حيث التكلفه.
التوسعة	Less مقارنة بالخدمات المصغرة.	قابلة للتطوير بدرجة عالية.
منطق الأعمال	يتم تخزين مكونات منطق الأعمال داخل نطاق خدمة واحد، مع بروتوكولات سلكية بسيطة (HTTP مع XML أو JSON) وواجهة برمجة تطبيقات مدفوعة باستخدام SDKs/Clients.	يمكن أن تتواجد منطق الأعمال عبر المجالات، مع طبقات تشبه ناقل خدمة المؤسسة بين الخدمات (البرمجيات الوسيطة).

أدوات الخدمات المصغرة

1) Wiremock: اختبار الخدمات المصغرة

WireMock هي مكتبة مرنة لإنشاء نماذج أولية ومحاكاة لخدمات الويب. يمكنها تهيئة الاستجابة التي تُرجعها واجهة برمجة تطبيقات HTTP عند تلقي طلب محدد. كما تُستخدم لاختبار الخدمات المصغرة.

تحميل الرابط: http://wiremock.org/

2) عامل الميناء

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

تحميل الرابط: https://www.docker.com/

3) هيستريكس

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

وصلة التحميل: https://github.com/Netflix/Hystrix

أفضل ممارسات الخدمات المصغرة Architecture

• مخزن بيانات منفصل لكل خدمة مصغرة.
• حافظ على مستوى نضج الكود مماثلاً.
• بناء منفصل لكل خدمة مصغرة.
• تعامل دائمًا مع كل خادم على أنه عديم الحالة.

الأسئلة الشائعة