الميكروسيرفس كانت حلمًا تحول لكابوس: كيف أنقذنا “المونوليث النمطي” من جحيم التعقيد الموزع؟

بتذكرها زي كأنها مبارح… الساعة كانت حوالي 2 بعد منتصف الليل، وأنا وفريق العمل في مكالمة طارئة، نحاول نفهم ليش طلبات الشراء الجديدة ما بتظهر في نظام إدارة المخزون. المشكلة كانت زي الشبح، بتظهر وبتختفي. السيرفر اللي عليه خدمة “الطلبات” (Orders Service) بحكي إنه أرسل الرسالة بنجاح، وسيرفر خدمة “المخزون” (Inventory Service) بحكي إنه ما استلم إشي. بين هدول السيرفرين كان في وسيط رسائل (Message Broker) وضايعين في سجلاته (logs) اللي حجمها وصل للجيجابايت.

هذا المشهد كان يتكرر معنا كثير. قبل سنة، كنا متحمسين جداً لما قررنا نبني نظامنا الجديد باستخدام معمارية الميكروسيرفس (Microservices). قرأنا عن Netflix و Amazon، وحلمنا بالاستقلالية في التطوير والنشر، والقدرة على التوسع اللانهائي. حسينا حالنا بنواكب العصر وأحدث التقنيات. لكن بعد أشهر قليلة، الحلم الوردي بدأ يتحول لكابوس حقيقي. بدل ما نكون مركزين على كتابة كود يخدم البزنس، صرنا نقضي معظم وقتنا في حل مشاكل الشبكات، ومزامنة البيانات، وإدارة عشرات المستودعات (Repositories) وخطوط النشر (Deployment Pipelines).

في ليلة من ليالي الإحباط الطويلة هذيك، واحد من المبرمجين الجداد حكى جملة بسيطة بس عميقة: “يا جماعة، مش كان زمان أسهل لما كان كل الكود في مكان واحد؟”. ضحكنا كلنا، بس هاي الجملة ضلت ترن في بالي. هل فعلاً قفزنا نحو التعقيد بدون سبب حقيقي؟ ومن هنا بدأت رحلة عودتنا إلى “البساطة المنظمة”، رحلتنا لاكتشاف قوة ما يسمى بـ “المونوليث النمطي” (Modular Monolith).

أغنية الميكروسيرفس الجذابة: لماذا وقعنا في الفخ؟

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

• الاستقلالية في التوسع (Independent Scaling): فكرة إنك تقدر تعمل توسيع (scale) لخدمة الدفع (Payments) لوحدها خلال مواسم العروض، بدون ما تلمس باقي الخدمات، كانت مغرية جداً.
• تنوع التقنيات (Technology Diversity): حلم كل مبرمج! نقدر نكتب خدمة معالجة البيانات بلغة Python لأن مكتباتها قوية، ونكتب خدمة الواجهة الخلفية بـ Go أو #C لسرعتها.
• استقلالية الفرق (Team Autonomy): حسب قانون كونواي (Conway’s Law)، بنية النظام تعكس بنية التواصل في المؤسسة. فكرة إن كل فريق يكون مسؤول عن خدمة أو خدمتين من الألف إلى الياء، من التطوير للاختبار للنشر، كانت بتوعدنا بسرعة وكفاءة أكبر.
• عزل الأخطاء (Fault Isolation): نظرياً، لو وقعت خدمة التوصيات (Recommendations)، باقي الموقع بضل شغال. (طبعاً الواقع كان أعقد من هيك بكثير).

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

عندما يتحول الحلم إلى كابوس: التكاليف الخفية للميكروسيرفس

بسرعة، بدأت المشاكل تظهر. ما كانت مشاكل في الكود نفسه، بل في “الغراء” اللي بربط هاي الخدمات ببعضها. هذا الغراء كان هش، ومعقد، ومكلف جداً.

جحيم التعقيد الموزع

أكبر مشكلة واجهناها هي أننا استبدلنا تعقيد الكود داخل تطبيق واحد (Monolith) بتعقيد موزع على الشبكة، وهو أسوأ بمليون مرة. أي استدعاء دالة (function call) بسيط داخل المونوليث، صار عبارة عن استدعاء شبكة (network call) محفوف بالمخاطر:

• الشبكة غير موثوقة: ممكن الطلب يضيع، ممكن يصير فيه تأخير (latency)، ممكن السيرفر المستقبِل يكون واقع. فجأة، صرنا محتاجين نطبق أنماط تصميم معقدة زي (Retries, Circuit Breakers, Timeouts) لكل استدعاء.
• اتساق البيانات (Data Consistency): في المونوليث، كنا بنستخدم (Database Transaction) عشان نضمن إن عملية إضافة طلب جديد وخصم الكمية من المخزون بتصير كوحدة واحدة. في عالم الميكروسيرفس، هذا صار شبه مستحيل. دخلنا في دوامة أنماط زي (Sagas) و (Eventual Consistency) اللي زادت التعقيد بشكل هائل، وخلت تتبع الأخطاء مهمة انتحارية.
• التتبع والمراقبة (Debugging and Tracing): لما كان يجينا خطأ، كنا بنفتح ملف السجل (log file) وبنعرف شو صار. الآن، عشان نفهم مسار طلب واحد، لازم نجمع سجلات من 5 أو 6 خدمات مختلفة. الأدوات مثل Jaeger و Zipkin بتساعد، لكنها بتضيف طبقة جديدة من التعقيد والإدارة.

العبء التشغيلي (Operational Overhead)

كل خدمة جديدة كانت بتعني قاعدة بيانات جديدة، pipeline جديد للنشر، نظام مراقبة جديد، وتنبيهات جديدة. فجأة، صار عنا جيش من ملفات الـ YAML والـ Dockerfiles أكبر من الكود نفسه! صرنا محتاجين فريق DevOps متخصص من اليوم الأول بس عشان يخلي هاي المنظومة واقفة على رجليها. بدل ما نركز على تطوير المنتج، صرنا مدراء أنظمة.

نصيحة من أبو عمر: إذا كان فريقك أقل من 15-20 مطور، وفكرة وجود فريق منصة (Platform Team) متخصص تبدو رفاهية، فالميكروسيرفس غالباً ستكون عبئاً عليك أكثر من كونها حلاً.

احتكاك في عملية التطوير (Development Friction)

حتى تجربة التطوير على الجهاز المحلي صارت معاناة. عشان المبرمج يقدر يختبر تعديل بسيط، صار لازم يشغل 7 أو 8 خدمات على جهازه باستخدام Docker Compose، اللي كان بيستهلك كل ذاكرة الجهاز. والأسوأ هو لما يكون تعديل واحد بيحتاج تغيير في 3 خدمات مختلفة. فكرة “النشر المستقل” تبخرت، وصرنا محتاجين نعمل تنسيق معقد بين الفرق عشان نطلق ميزة جديدة، وهذا بالضبط ما يسمى بالـ “المونوليث الموزع” (Distributed Monolith)، وهو أسوأ أنواع الأنظمة على الإطلاق.

لحظة “وجدتها!”: إعادة اكتشاف المونوليث

في خضم هذا الإحباط، بدأنا نفكر: هل المشكلة في فكرة المونوليث نفسها، أم في طريقة بنائنا له في الماضي كـ “كرة طين كبيرة” (Big Ball of Mud)؟ الجواب كان واضحاً. المشكلة ليست في وجود الكود في مكان واحد، بل في غياب الحدود الواضحة والفصل بين المسؤوليات داخله.

وهنا تعرفنا على صديقنا المنقذ: المونوليث النمطي (Modular Monolith).

الفكرة عبقرية في بساطتها: هو تطبيق واحد، يتم نشره كوحدة واحدة، ويعمل في عملية (process) واحدة. لكن من الداخل، هو مقسم إلى وحدات (modules) منفصلة ومنظمة بشكل صارم، كل وحدة لها مسؤولياتها الخاصة وبياناتها الخاصة، ولا تتواصل مع الوحدات الأخرى إلا من خلال واجهات برمجية (APIs) عامة ومحددة جيداً.

أفضل تشبيه هو أنه مثل بيت كبير منظم جيداً. فيه غرفة جلوس، مطبخ، غرف نوم. كل غرفة لها وظيفتها وبابها الخاص. عشان تنتقل من المطبخ لغرفة الجلوس، أنت بتستخدم الممر والباب (API)، ما بتكسر الحيط اللي بينهم (Direct access). هذا عكس الميكروسيرفس اللي هي عبارة عن مجموعة بيوت منفصلة، وعشان تنتقل من بيت لبيت لازم تطلع عالشارع (Network) وتواجه مخاطره.

بناء المونوليث النمطي: دليل عملي

التحول للمونوليث النمطي كان قرار استراتيجي. تطلب منا إعادة التفكير في بنية الكود وفرض قواعد صارمة. إليكم الخطوات العملية اللي اتبعناها:

1. تحديد حدود الوحدات (Module Boundaries)

هذه هي أهم خطوة. بدل التفكير في “الخدمات”، بدأنا نفكر في “القدرات التجارية” (Business Capabilities). جلسنا مع أصحاب المنتج ورسمنا الخريطة: عندنا قدرة لإدارة “المستخدمين”، وقدرة لإدارة “الطلبات”، وقدرة لمعالجة “المدفوعات”، وقدرة لإدارة “المنتجات والمخزون”. كل قدرة من هذه القدرات أصبحت “وحدة” (Module) في نظامنا.

هيكل المشروع أصبح كالتالي (مثال باستخدام C#/.NET):

Solution/
└── src/
    ├── Modules/
    │   ├── Orders/
    │   │   ├── Application/  // حالات الاستخدام والمنطق
    │   │   ├── Domain/       // الكيانات وقواعد البزنس
    │   │   ├── Infrastructure/ // الوصول لقاعدة البيانات، الخ
    │   │   └── Api/          // الواجهات العامة والعقود (Contracts)
    │   ├── Payments/
    │   │   └── ...
    │   └── Users/
    │       └── ...
    ├── Shared/
    │   └── Kernel/           // الأشياء المشتركة بين كل الوحدات
    └── Host/                 // المشروع الرئيسي الذي يجمع كل الوحدات (API Gateway, Web App)

2. فرض الحدود باستخدام الكود

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

• التحكم بالوصول (Access Modifiers): جعلنا كل الأصناف (classes) داخل الوحدة internal بشكل افتراضي. فقط الأصناف الموجودة في مجلد Api والتي تمثل الواجهة العامة للوحدة تكون public.
• قواعد الاعتماديات (Dependency Rules): استخدمنا أدوات مثل NetArchTest في .NET (أو ArchUnit في Java) لكتابة اختبارات تمنع أي مشروع وحدة من الإشارة مباشرة إلى مشروع وحدة آخر. الاعتمادية الوحيدة المسموحة هي على مجلد Api الخاص بالوحدة الأخرى.

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

3. التواصل بين الوحدات

بما أننا في نفس التطبيق، فالتواصل أصبح أسرع وأبسط بكثير.

• التواصل المتزامن (Synchronous): ببساطة عن طريق استدعاء دالة (method call) من الواجهة العامة للوحدة الأخرى. سريع، بسيط، والـ transaction تظل سهلة الإدارة.

  
  // داخل وحدة الطلبات Orders
  public class CreateOrderUseCase
  {
      private readonly IPaymentsApi _paymentsApi; // حقن الواجهة من وحدة المدفوعات
  
      public async Task Handle(CreateOrderCommand command)
      {
          // ... منطق إنشاء الطلب ...
          
          // استدعاء مباشر وآمن
          var paymentResult = await _paymentsApi.ProcessPayment(new PaymentRequest(...));
  
          if (!paymentResult.IsSuccess)
          {
              // يمكن عمل Rollback بسهولة
              throw new Exception("Payment Failed!");
          }
          
          // ... حفظ الطلب ...
      }
  }
      

• التواصل غير المتزامن (Asynchronous): لفصل الوحدات عن بعضها بشكل أكبر، استخدمنا وسيط رسائل داخل الذاكرة (in-process/in-memory message bus) مثل MediatR في .NET. وحدة “الطلبات” تقوم فقط بنشر حدث اسمه OrderCreatedEvent. وحدات أخرى مثل “الإشعارات” أو “المخزون” تكون مشتركة في هذا الحدث وتنفذ منطقها عند سماعه، بدون ما تعرف وحدة “الطلبات” بوجودها أصلاً. هذا يعطينا decoupling قوي بدون تعقيد الشبكة.

أفضل ما في العالمين: لماذا ينتصر المونوليث النمطي؟

بعد تطبيق هذه المعمارية، شعرنا أننا حصلنا على أفضل ما في العالمين:

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

الخلاصة: نصيحة من أخوكم أبو عمر

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

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

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

خلي الكود نظيف، والقهوة مرة، والله يوفقكم يا شباب. 👍