المعمارية الأحادية مقابل الخدمات المصغرة

المعمارية الأحادية مقابل الخدمات المصغرة

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

ما هي المعمارية الأحادية؟

تجمع المعمارية الأحادية (Monolith) كل مكونات التطبيق — طبقة HTTP، ومنطق الأعمال، ونماذج البيانات، وطبقة الوصول للبيانات — في وحدة نشر واحدة. عند الإطلاق تُطلق كل شيء معًا، وعند معالجة أي طلب يمتلك الخيط المُنفِّذ وصولًا مباشرًا في الذاكرة لكل وحدة وظيفية.

أمثلة واقعية: يعمل Stack Overflow على معمارية أحادية مضبوطة بعناية تخدم نحو 1.5 مليار طلب شهريًا من خوادم معدودة. كذلك اعتمد Shopify وBasecamp في مراحلهما الأولى على معمارية Rails أحادية لفترات طويلة وبأحجام ضخمة.

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

تُفكِّك معمارية الخدمات المصغرة (Microservices) النظامَ إلى مجموعة من الخدمات الصغيرة المستقلة القابلة للنشر بشكل منفرد، إذ تمتلك كل خدمة مخزنها الخاص وتتواصل عبر الشبكة (عادةً HTTP/REST أو رسائل غير متزامنة). تُشغِّل Netflix أكثر من 1,000 خدمة مصغرة، وقد قطعت Amazon مسيرة التحويل من المعمارية الأحادية مطلع الألفية الثالثة وأرجعت إليها قدرتها على التوسع الهائل.

مصفوفة المقايضات

لا يوجد أسلوب متفوق بالمطلق؛ فالاختيار الصحيح يعتمد على موضع نظامك وفريقك على عدة محاور:

• التعقيد التشغيلي. في المعمارية الأحادية هناك وحدة نشر واحدة، ومجموعة سجلات واحدة، واتصال قاعدة بيانات واحد. أما الخدمات المصغرة فتستلزم اكتشاف الخدمات، والتتبع الموزع، والمصادقة بين الخدمات، وأنماط الصمود كقواطع الدوائر. هذا العبء حقيقي — فمنهجية Chaos Engineering في Netflix موجودة تحديدًا لأن الشركة تُشغِّل مئات الخدمات.
• سرعة التطوير في المراحل الأولى. في المعمارية الأحادية يفتح المطور المستودع ويُشغِّل أمرًا واحدًا ثم يُعدِّل أي جزء من النظام دون قفزات عبر الشبكة ودون عقود توافق API. استثمر مطورو Shopify الأوائل هذه الميزة للتكرار السريع قبل تحقيق توافق المنتج مع السوق.
• قابلية التوسع المستقل. إذا احتاجت خدمة video-transcoding وحدها إلى 500 نواة معالج بينما يكتفي الباقي بخمس نوى، فإن الخدمات المصغرة تُتيح توسيع تلك العملية بمعزل. أما المعمارية الأحادية فتجبرك على توسيع التطبيق بأكمله.
• عزل الأعطال. في المعمارية الأحادية قد يتسبب تسرب ذاكرة في وحدة ReportGenerator في إيقاف التطبيق بأكمله. في الخدمات المصغرة، تعطُّل Notification Service لا ينبغي أن يمنع المستخدمين من إتمام طلباتهم — بشرط تصميم قواطع الدوائر بصورة صحيحة.
• استقلالية الفريق. يقول قانون كونواي إن المؤسسات تنتج أنظمة تعكس هياكل تواصلها. حين يكون لديك 200 مهندس في 15 فريقًا مستقلًا، تتحول قاعدة الشيفرة الوحيدة إلى جحيم من تعارض الدمج. الخدمات المصغرة تُتيح لكل فريق امتلاك خدمته من الألف إلى الياء.
• اتساق البيانات. يستطيع المونوليث استخدام معاملة قاعدة بيانات واحدة لضمان كتابة الطلب وسجل الدفع معًا ذريًّا. عبر الخدمات المصغرة يُفقَد هذا الضمان، ويجب اللجوء لأنماط كـ Sagas أو الاتساق النهائي، وهي أصعب في التفكير والتصحيح.

متى تختار كل أسلوب؟

اختر المعمارية الأحادية حين:

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

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

• تتباين متطلبات التوسع تباينًا حقيقيًّا بين أجزاء النظام المختلفة.
• لديك فرق كبيرة متعددة وتحتاج إلى استقلالية تنظيمية.
• تفرض اشتراطات قانونية أو أمنية عزلًا صارمًا للبيانات بين النطاقات (مثل PCI-DSS للمدفوعات).
• تحتاج إلى استخدام لغات أو بيئات تشغيل مختلفة لكل خدمة (Python للتعلم الآلي، Go للكمون المنخفض، Node للعمليات كثيفة الإدخال والإخراج).

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

معظم الأنظمة الكبيرة اليوم كانت في البداية معماريات أحادية. أمازون وNetflix وUber وAirbnb وثّقت جميعها علنًا رحلة الهجرة من المونوليث إلى الخدمات المصغرة على مدى سنوات لا بين عشية وضحاها. استُخرجت الحدود الأكثر إيلامًا أولًا — المصادقة، أو المدفوعات، أو الخدمة الأعلى حركةً — بينما بقي بقية المونوليث كما هو. هذا النهج (نمط Strangler Fig الذي سنتناوله في الدرس الثامن) يُقلِّل مخاطر الهجرة تقليلًا كبيرًا.

الخلاصة

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