البنية المعيارية المتجانسة مقابل الخدمات المصغرة: أي بنية يجب أن تختار؟

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

ومن أكثر الخيارات التي تظهر في نقاشات هندسة البرمجيات: Modular Monolith وMicroservices.

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

لذلك، السؤال الصحيح ليس "أي بنية أكثر حداثة؟" وإنما "أي بنية تناسب تعقيد التطبيق وحجم الفريق ومتطلبات التوسع وأهداف العمل؟"

Modular Monolith مقابل Microservices في لمحة سريعة

ما هي Modular Monolith؟

Modular Monolith هي تطبيق واحد قابل للنشر، لكنه مقسم داخليًا إلى وحدات واضحة ومحددة المسؤوليات.

والكلمة المهمة هنا هي Modular. فهي لا تعني مجرد قاعدة كود ضخمة يمكن لكل جزء فيها الوصول إلى كل شيء.

يمكن للتطبيق المنظم بهذا الأسلوب أن يحتوي على وحدات مثل:

• المستخدمون والهوية
• المبيعات
• الطلبات
• المدفوعات
• المخزون
• التقارير
• الإشعارات

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

مثال: منصة تجارة إلكترونية

تخيل منصة تجارة إلكترونية تحتوي على وحدات للعملاء والمنتجات والطلبات والمدفوعات والمخزون والشحن.

في Modular Monolith يمكن فصل هذه المجالات منطقيًا مع الاحتفاظ ببيئة تشغيل وبنية نشر مشتركة.

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

ما هي Microservices؟

تعتمد بنية Microservices على تقسيم التطبيق إلى مجموعة من الخدمات القابلة للنشر بشكل مستقل، بحيث تكون كل خدمة مسؤولة عن قدرة تجارية أو نطاق محدد.

يمكن أن تحتوي المنصة على خدمات مستقلة لإدارة:

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

وتتواصل هذه الخدمات من خلال APIs أو أنظمة الرسائل أو بروتوكولات الشبكة الأخرى، وقد تمتلك كل خدمة بياناتها الخاصة وفقًا للتصميم المعتمد.

الفرق الأساسي: حدود التطبيق واستقلالية النشر

الفرق العملي الأكبر ليس مجرد عدد الوحدات أو المستودعات، وإنما مستوى الاستقلالية بين مكونات النظام.

في Modular Monolith تعمل الوحدات ضمن بيئة تشغيل واحدة ودورة نشر مشتركة.

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

هذا الحد يمنح مرونة أكبر، لكنه يضيف أيضًا تعقيدًا.

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

سرعة التطوير: Modular Monolith مقابل Microservices

بالنسبة إلى كثير من الفرق الصغيرة والمتوسطة، يمكن أن تجعل Modular Monolith عملية التطوير أبسط وأسرع.

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

أما Microservices فتمنح استقلالية أكبر، لكن هذه الاستقلالية تتطلب هندسة وتشغيلًا إضافيين.

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

وإذا لم تكن هذه القدرات مطلوبة فعليًا، فقد يؤدي إدخالها إلى إبطاء التطوير بدل تحسينه.

قابلية التوسع: متى تتميز Microservices؟

من أهم مزايا Microservices إمكانية التوسع بشكل مستقل.

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

في بنية Microservices يمكن توسيع هذه الخدمة بشكل مستقل بدل توسيع التطبيق بالكامل.

يصبح ذلك مفيدًا بشكل خاص عندما تختلف متطلبات الموارد بين أجزاء النظام بشكل كبير.

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

استقلالية النشر

عادةً ما تشترك Modular Monolith في دورة نشر واحدة، وبالتالي قد يتطلب تغيير وحدة معينة نشر التطبيق بالكامل.

أما Microservices فتسمح للفرق بنشر الخدمات بشكل مستقل عندما تكون البنية وخطوط النشر مصممة لذلك.

ويمكن أن تكون هذه ميزة مهمة للمؤسسات الهندسية الكبيرة.

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

البيانات والمعاملات

تُعد بنية قاعدة البيانات من أكثر الجوانب التي يظهر فيها الفرق بين النهجين.

يمكن لـ Modular Monolith استخدام قاعدة بيانات مشتركة مع فرض حدود منطقية واضحة للملكية والوصول بين الوحدات.

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

تخيل طلبًا يحتاج إلى حجز المخزون وتفويض عملية الدفع. في البنية الأحادية قد يتم تنسيق هذه العمليات ضمن نموذج معاملات أبسط.

أما في النظام الموزع فقد تحتاج العملية إلى Events وإجراءات تعويضية وإعادة المحاولة وضمان عدم تكرار العمليات ومعالجة دقيقة للفشل.

الموثوقية ومعالجة حالات الفشل

تحتوي Modular Monolith على عدد أقل من حدود الشبكة، وبالتالي عدد أقل من حالات الفشل المرتبطة بالشبكة.

في Microservices قد يمر الطلب الواحد عبر عدة خدمات، ويمكن لأي اعتماد خارجي أن يؤدي إلى تأخير أو Timeout أو فشل جزئي.

لذلك تحتاج أنظمة Microservices في بيئة الإنتاج إلى أنماط مثل:

• Timeouts
• إعادة المحاولة مع Backoff مناسب
• Circuit Breakers عند الحاجة
• Idempotency
• Dead-Letter Handling للعمليات غير المتزامنة
• Distributed Tracing
• Health Checks والمراقبة

هذه التقنيات قوية ومفيدة، لكنها تضيف مسؤوليات هندسية وتشغيلية جديدة.

الاختبار وتصحيح الأخطاء

توفر Modular Monolith عادةً بيئة أبسط لاختبارات النظام الكاملة، لأن التطبيق يمكن تشغيله كمنظومة واحدة.

أما Microservices فتحتاج إلى اختبار الخدمات منفردة، إضافة إلى اختبار العقود والتفاعلات بينها.

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

ولهذا تصبح اختبارات العقود واختبارات التكامل والمراقبة وبيئات الاختبار الواقعية أكثر أهمية مع زيادة عدد الخدمات.

حجم الفريق مهم

يجب أن تعكس البنية طريقة عمل المؤسسة نفسها.

قد لا تستفيد شركة لديها خمسة مطورين من تشغيل عشرين خدمة مستقلة.

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

ولهذا ترتبط Microservices بالتوسع التنظيمي بقدر ارتباطها بالتوسع التقني.

متى تكون Modular Monolith خيارًا أفضل؟

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

ويمكن أن تكون Modular Monolith أيضًا أساسًا جيدًا للتوسع المستقبلي، لأن الحدود الواضحة بين الوحدات تجعل تحديد الأجزاء التي يمكن تحويلها لاحقًا إلى خدمات مستقلة أسهل.

متى تكون Microservices أكثر ملاءمة؟

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

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

Microservices لا تعني تلقائيًا قابلية توسع أفضل

يمكن لـ Microservices أن توفر التوسع المستقل، لكن تقسيم التطبيق إلى خدمات لا يضمن وحده أداءً أفضل.

قد تؤدي الحدود السيئة بين الخدمات إلى زيادة حركة الشبكة وتكرار البيانات وعمليات التنسيق وإنشاء نقاط اختناق بين الخدمات.

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

إطار عملي لاتخاذ القرار

1. هل تحتاج أجزاء التطبيق فعلًا إلى نشر مستقل؟
2. هل تحتاج الأحمال المختلفة إلى توسع مستقل؟
3. هل الحدود التجارية واضحة بما يكفي لتحديد ملكية كل خدمة؟
4. هل يمتلك الفريق الخبرة التشغيلية اللازمة لإدارة الأنظمة الموزعة؟
5. هل ستقلل حدود الخدمات الترابط أم ستنقل التعقيد فقط إلى APIs والبنية التحتية؟
6. هل يمكن لـ Modular Monolith حل المتطلبات الحالية بطريقة أبسط؟

إذا كانت معظم الإجابات تشير إلى البساطة، فقد تكون Modular Monolith نقطة البداية الأفضل. أما إذا كانت هناك متطلبات قوية للنشر أو التوسع أو الملكية أو العزل المستقل، فقد تقدم Microservices فوائد حقيقية.

مسار هجين: ابدأ بشكل Modular ثم قسّم عند الحاجة

لا يجب أن يكون اختيار البنية قرارًا نهائيًا يتم اتخاذه في اليوم الأول.

يمكن البدء بـ Modular Monolith مع إنشاء حدود قوية بين المجالات، ثم مراقبة النظام واستخراج الخدمات عندما يظهر سبب واضح وقابل للقياس.

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

بهذه الطريقة تتجنب المؤسسة دفع التكلفة التشغيلية لـ Microservices قبل أن تكون هناك حاجة حقيقية إليها.

كيف تتعامل Code-Ox مع بنية التطبيقات؟

في Code-Ox Technologies LLP يتم اختيار بنية التطبيق بناءً على متطلبات العمل ونمو المنتج والتكاملات وتدفقات البيانات والاحتياجات التشغيلية.

ووفقًا للمشروع، يمكن أن يعتمد الحل على Modular Monolith أو Microservices أو APIs أو المكونات القائمة على الأحداث أو البنية السحابية أو قواعد البيانات أو لوحات المعلومات أو التكاملات المخصصة.

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

الخلاصة: Modular Monolith أم Microservices؟

Modular Monolith ليست حلًا وسطًا. بالنسبة إلى العديد من التطبيقات، قد تكون البنية الأكثر عملية لتحقيق حدود واضحة للكود وسرعة التطوير وسهولة التشغيل.

Microservices تصبح ذات قيمة عندما تبرر الحاجة إلى النشر المستقل أو التوسع أو الملكية أو العزل بنية موزعة.

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