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

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

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

تكلفة التوزيع المبكر

الخدمات المصغرة ليست مجانية. إنها تستبدل التعقيد المنطقي داخل قاعدة برمجية واحدة بتعقيد تشغيلي عبر شبكة موزعة.

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

1. تأخير الشبكة (Network Latency): ما كان يستغرق أجزاء من الملي ثانية كاستدعاء دالة في الذاكرة، أصبح الآن طلب شبكة عرضة لفقدان حزم البيانات وتأخير الاتصال.
2. إدارة البيانات الموزعة: تتطلب المعاملات التي يجب أن تكون مترابطة (ACID Transactions) عبر قواعد بيانات متعددة أنماطاً معقدة مثل نمط "Saga" أو الالتزام ثنائي المرحلة.
3. العبء المعرفي: لم يعد بإمكان المطورين ببساطة تشغيل التطبيق محلياً. يجب عليهم تشغيل وإدارة نصف دزينة من الحاويات (Containers) فقط لاختبار تغيير بسيط في واجهة المستخدم.

إذا كان فريق الهندسة الخاص بك يقضي وقتاً في إدارة خطوط أنابيب النشر (CI/CD) وشبكات الخدمات (Service Meshes) أكثر من الوقت الذي يقضيه في تطوير ميزات العمل الفعلية، فإن معماريتك تضر بسرعة إنجازك.

عودة البنية الأحادية المعيارية (Modular Monolith)

تحافظ البنية الأحادية المعيارية على وحدة نشر (Deployment Unit) واحدة مع فرض حدود منطقية صارمة داخلياً. إنها توفر النظافة المعمارية للخدمات المصغرة دون ضريبة الشبكات الموزعة.

فرض الحدود المعمارية

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

• واجهات برمجية صارمة (Strict Interfaces): يجب أن تتواصل الوحدات مع بعضها البعض فقط من خلال واجهات عامة (APIs) محددة مسبقاً.
• عزل البيانات: حتى لو كانت الوحدات تعيش في نفس القاعدة البرمجية، يجب أن تمتلك مخططات قاعدة بيانات (Schemas) خاصة بها. لا يمكن للوحدة "أ" الكتابة مباشرة في جداول الوحدة "ب".
• فحص المعمارية آلياً: يجب استخدام أدوات تمنع بناء التطبيق إذا حاول مطور إجراء استيراد غير قانوني بين الوحدات عبر الحدود المسموح بها.

متى يجب استخراج خدمة مصغرة؟

نوصي في كوجنس باستراتيجية "الاستخراج عند الضرورة القصوى". ابدأ ببنية أحادية معيارية، وقم بفصل وحدة معينة إلى خدمة مصغرة مستقلة فقط عندما تفرض عليك متطلبات تجارية أو فنية صارمة القيام بذلك:

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