ما هي الـ Microservices؟

لتوضيح الأمر، لا يوجد هيكل واحد يناسب الجميع؛ ولا يوجد أفضل أو أسوأ هيكل أيضًا، فقط الهيكل الأكثر ملاءمة لعملك.

مقدمة عن الخدمات المصغرة (Microservices)

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

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

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

تطور هيكل البرمجيات

لنبدأ باستخدام الهيكل الأحادي (Monolithic) كهيكل بداية. لنرى المشكلات التي تواجهها الهياكل المختلفة مع نمو الأعمال بمرور الوقت.

الهيكل الأحادي (Monolithic Architecture)

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

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

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

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

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

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

الهيكل الموجه للخدمات (Service-Oriented Architecture)

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

نظرة عامة على نشر SOA نموذجي. يتم تقليل تأثير فشل خدمة واحدة بشكل فعال مع مثل هذا الهيكل ويزداد معدل التكرار لخدمة واحدة.

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

الفوائد التالية لـ SOA مقابل الهيكل الأحادي:

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

هيكل الخدمات المصغرة (Microservice Architecture)

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

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

الاختلافات الإضافية ملخصة في الجدول أدناه:

	SOA	الخدمات المصغرة
الهيكل	يتم إعادة استخدام الخدمات ومشاركتها على مستوى المؤسسة	الخدمات منفصلة وتعمل بشكل مستقل
الحجم	خدمات كبيرة نسبيًا ووحداتية	خدمات أصغر وأكثر مرونة تخدم غرضًا أو وظيفة محددة للأعمال
الاتصال	ESB	API
الترابط	مشاركة الموارد/ترابط فضفاض	سياق محدد
التوافقية	يدعم بروتوكولات رسائل متعددة مثل بروتوكول الوصول إلى الكائنات البسيط (SOAP)، بروتوكول قائمة الانتظار المتقدم للرسائل (AMQP) وبروتوكول قائمة انتظار الرسائل من مايكروسوفت (MMQ)	يستخدم بروتوكولات رسائل خفيفة الوزن وغير مرتبطة بلغة معينة مثل HTTP، نقل حالة التمثيل (REST) أو خدمة رسائل جافا (JMS)
حوكمة البيانات	حوكمة بيانات مشتركة عبر المؤسسة نتيجة لمشاركة المكونات	لا توجد حوكمة بيانات متسقة بين الفرق بسبب الطبيعة المستقلة للخدمات
التخزين	طبقة تخزين بيانات واحدة مشتركة بين جميع الخدمات داخل تطبيق معين	خادم بيانات أو قاعدة بيانات مستقلة لتخزين البيانات لكل خدمة، حسب الحاجة

نظرة عامة على نشر خدمة مصغرة نموذجية

استراتيجيات التوسع للهيكل الأحادي وهيكل الخدمات المصغرة

لقراءة المزيد بالتفصيل https://martinfowler.com/articles/microservices.html

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

لماذا نحتاج إلى الخدمات المصغرة

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

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

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