البنية الأحادية أم الخدمات المصغرة Microservices: كيف تختار معمارية نظامك

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

1. ما الفرق بين البنية الأحادية والخدمات المصغرة

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

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

2. مزايا البنية الأحادية وحدودها

البنية الأحادية هي نقطة البداية الطبيعية لأغلب المشاريع، لأنها تجعل التطوير والاختبار والنشر أبسط. ومن أبرز مزاياها:

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

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

3. ما تقدمه الخدمات المصغرة وما تكلفه

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

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

4. معايير القرار: الفريق قبل التقنية

يقرر حجم الفريق وبنيته المعمارية المناسبة أكثر مما تقرره التقنية. وتنص ملاحظة معروفة في هندسة البرمجيات تُسمى «قانون كونواي» على أن بنية الأنظمة تميل إلى أن تعكس بنية التواصل في المؤسسة التي تبنيها. ومن الأسئلة التي تساعد على القرار:

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

5. الانتقال التدريجي حين تظهر الحاجة

إذا بدأ النظام أحاديًا ثم ظهرت أسباب حقيقية للتقسيم، فإن إعادة كتابته كاملًا دفعة واحدة من أخطر الخيارات وأكثرها كلفة. والنهج الأكثر أمانًا هو الانتقال التدريجي، ويُعرف أحد أساليبه باسم «نمط التين الخانق» Strangler Fig، حيث تُستخرج الوظائف واحدة بعد أخرى إلى خدمات جديدة، ويُوجَّه إليها الطلب تدريجيًا، بينما يستمر النظام القديم في خدمة ما لم يُنقل بعد.

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

الخلاصة

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