الخدمات المصغرة مقابل Monolith: اتخاذ القرار المعماري الصحيح

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

يوفر هذا الدليل إطارًا صادقًا للاختيار بين بنيات الخدمات المتجانسة والمصغرة، بما في ذلك الأساليب الهجينة التي غالبًا ما تكون أكثر منطقية للشركات المتنامية.

الوجبات الرئيسية

• ابدأ بوحدة متراصة ما لم تكن لديك حاجة محددة ومثبتة للتوسع أو النشر المستقل
• حجم الفريق هو أقوى مؤشر على نجاح الخدمات الصغيرة: الحد الأدنى 3 مهندسين لكل خدمة
• يوفر نمط "المتراصة المعيارية" معظم فوائد الخدمات الصغيرة دون تحمل تكاليف تشغيلية
• يجب أن يكون الانتقال من الخدمات المتجانسة إلى الخدمات الصغيرة تدريجيًا، بحيث يتم استخراج خدمة واحدة في كل مرة

---

المقارنة الصادقة

مزايا مونوليث

مزايا الخدمات المصغرة

تكاليف الخدمات الصغيرة (غالبًا ما يتم التقليل من قيمتها الحقيقية)

---

إطار القرار

القرار حسب حجم الفريق

القرار من خلال قياس الاحتياجات

القرار حسب احتياجات النشر

---

المنوليث المعياري: الأفضل في كلا العالمين

يقوم المونوليث المعياري بتنظيم التعليمات البرمجية في وحدات ذات حدود جيدة داخل وحدة واحدة قابلة للنشر. تتواصل الوحدات من خلال واجهات محددة، وليس من خلال الوصول المباشر إلى قاعدة البيانات.

###الهندسة المعمارية

Single Deployment Unit
+---------------------------------------------------+
|  [Orders Module]  [Inventory Module]  [Users Module] |
|       |                  |                 |        |
|       +------ Internal API Layer ----------+        |
|       |                  |                 |        |
|  [Orders DB]   [Inventory DB]    [Users DB]          |
|       |                  |                 |        |
|       +------ Shared Database Server ------+        |
+---------------------------------------------------+

نمط متراصة وحدات NestJS

// orders/orders.module.ts
@Module({
  imports: [
    InventoryModule, // Explicit dependency declaration
    UsersModule,
  ],
  controllers: [OrdersController],
  providers: [OrdersService],
  exports: [OrdersService], // Controlled public interface
})
export class OrdersModule {}

// inventory/inventory.module.ts
@Module({
  controllers: [InventoryController],
  providers: [InventoryService],
  exports: [InventoryService], // Only expose what others need
})
export class InventoryModule {}

قواعد الوحدة:

1. تتواصل الوحدات من خلال الخدمات المصدرة، وليس من خلال الوصول المباشر إلى قاعدة البيانات أبدًا
2. تمتلك كل وحدة جداول قاعدة البيانات الخاصة بها بشكل حصري
3. يتم الوصول إلى البيانات المشتركة من خلال طرق الخدمة، وليس من خلال عمليات الانضمام عبر حدود الوحدة النمطية
4. تبعيات الوحدة واضحة في المصفوفة imports

متى يتم استخراج الوحدة النمطية في الخدمة

استخراج عندما:

• تحتاج الوحدة إلى التوسع بشكل مستقل (على سبيل المثال، معالجة الصور والبحث)
• يختلف تكرار نشر الوحدة بشكل كبير عن البقية
• تتم صيانة الوحدة من قبل فريق منفصل
• تحتوي الوحدة على متطلبات تقنية مختلفة (على سبيل المثال، نموذج ML في Python)

لا تستخرج عندما:

• "يبدو أنها يجب أن تكون خدمة"
• تريد بنية أنظف (أعد بناء المتراصة بدلاً من ذلك)
• لم تحدد حاجة محددة للتوسع أو النشر

---

استراتيجية الترحيل: Monolith إلى Microservices

نمط التين الخانق

استبدل الوظائف المتجانسة تدريجيًا بالخدمات الصغيرة، وقم بتوجيه حركة المرور إلى الخدمة الجديدة بينما يظل الكود القديم بمثابة بديل.

الخطوة 1: تحديد مرشح الاستخراج (أعلى متطلبات التوسع أو احتكاك النشر)

الخطوة 2: أنشئ الخدمة الجديدة جنبًا إلى جنب مع الوحدة المتراصة

الخطوة 3: توجيه حركة المرور إلى الخدمة الجديدة عبر بوابة API

الخطوة 4: التحقق من الصحة عن طريق تشغيل كليهما بالتوازي

الخطوة 5: قم بإزالة الرمز القديم من الوحدة المتراصة

اعتبارات ترحيل البيانات

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

---

أمثلة على الهندسة المعمارية في العالم الحقيقي

منصة التجارة الإلكترونية

Modular Monolith (recommended for most):
- Product catalog module
- Cart and checkout module
- Order management module
- User accounts module
- Inventory module
All in one deployable unit, backed by one PostgreSQL instance.

Selective Microservices (for high-traffic stores):
- Search service (Elasticsearch, scales independently)
- Image processing service (CPU-intensive, different scaling)
- Payment service (PCI compliance boundary)
Everything else stays in the monolith.

نظام تخطيط موارد المؤسسات (نمط Odoo)

Monolith is the correct choice for ERP:
- Deep cross-module data relationships
- Complex business rules spanning modules
- Consistent reporting across all data
- Smaller concurrent user counts
- Transactional consistency critical

Odoo itself is a modular monolith: modules are installed/uninstalled,
but everything runs in one process with one database.

---

الأسئلة المتداولة

هل يعيقنا متراصتنا؟

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

ما هو عدد الخدمات الصغيرة التي تعتبر كثيرة جدًا؟

الحد العملي: لا يزيد عن 3-5 خدمات لكل مهندس مسؤول عن العمليات. يجب أن يمتلك فريق مكون من 5 مهندسين ما لا يزيد عن 15-25 خدمة. أبعد من ذلك، يهيمن الحمل التشغيلي وتنخفض السرعة الهندسية. تدير العديد من الشركات الناجحة ما بين 5 إلى 10 خدمات محددة جيدًا بدلاً من مئات الخدمات النانوية.

هل يمكننا استخدام قواعد بيانات مختلفة لوحدات مختلفة في كتلة واحدة؟

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

كيف يتعامل ECOSIRE مع هذا الأمر للعملاء؟

نوصي بالبدء بوحدة متراصة معيارية لمعظم العملاء. تستخدم خدمات تنفيذ Odoo بنية Odoo المعيارية، وتتبع مشاريع التطوير المخصصة لدينا نمط NestJS الموحد. نحن نستخرج الخدمات فقط عندما تكون هناك حاجة مؤكدة للتوسع المستقل --- عادةً البحث أو معالجة الملفات أو عمليات التكامل الخارجية. راجع دليل DevOps للتعرف على الفلسفة المعمارية الكاملة.

---

ما يأتي بعد ذلك

القرارات المعمارية أساسية. بمجرد اختيار النهج الذي يناسبك، استثمر في أتمتة CI/CD للنشر الموثوق، والمراقبة للرؤية التشغيلية، وأنماط بوابة واجهة برمجة التطبيقات لإدارة الاتصال بين خدمة وخدمة.

اتصل بـ ECOSIRE للاستشارات المتعلقة بالهندسة المعمارية، أو استكشف خدمات تنفيذ Odoo الخاصة ببنية تخطيط موارد المؤسسات (ERP) التي تتناسب مع أعمالك.

---

تم النشر بواسطة ECOSIRE - لمساعدة الشركات على اختيار البنية المناسبة لمرحلة نموها.