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