أنماط هندسة الخدمات الصغيرة

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

الخدمات الصغيرة مقابل التطبيق الموحد

إطار القرار

العامل	التطبيق الموحد يفوز	الخدمات الصغيرة تفوز
حجم الفريق	< 20 مهندس	> 30 مهندس
تعقيد المجال	مجال واحد	سياقات محدودة متعددة
تواتر النشر	إصدارات أسبوعية	إصدارات يومية/بالساعة
متطلبات التوسع	توسع موحد	توسع خاص بالمكون
الهيكل التنظيمي	فريق واحد	فرق مستقلة متعددة

سؤال المقابلة: متى تستخدم الخدمات الصغيرة

س: "شركة ناشئة لديها 8 مهندسين وتريد تبني الخدمات الصغيرة. ما نصيحتك؟"

ج: عموماً أنصح بعدم استخدام الخدمات الصغيرة للفرق الصغيرة:

الأسباب:

1. العبء التشغيلي: كل خدمة تحتاج نشراً ومراقبة وتسجيلاً
2. تعقيد الشبكة: التتبع الموزع، التأخير، معالجة الفشل
3. الحمل المعرفي: 8 مهندسين لا يستطيعون امتلاك خدمات كثيرة بعمق
4. سرعة التطوير: التطبيق الموحد يسمح بتطوير أولي أسرع

التوصية:

• ابدأ بتطبيق موحد معياري (حدود داخلية واضحة)
• استخدم حقن التبعيات والواجهات
• استخرج الخدمات فقط عند ظهور احتياجات توسع محددة
• المرشحون الأوائل: ميزات عالية التوسع، متطلبات تقنية مختلفة

تفكيك الخدمات

نهج التصميم المدفوع بالمجال (DDD)

السياقات المحدودة:

منصة التجارة الإلكترونية:
├── سياق الكتالوج (المنتج، الفئة، البحث)
├── سياق الطلب (الطلب، السلة، الدفع)
├── سياق الدفع (الدفع، الاسترداد)
├── سياق الشحن (الشحنة، التتبع)
└── سياق المستخدم (المستخدم، المصادقة، الملف الشخصي)

استدلالات التفكيك:

• المسؤولية الواحدة: كل خدمة تفعل شيئاً واحداً جيداً
• ملكية الفريق: فريق واحد يمكنه الامتلاك والنشر باستقلالية
• القدرة التجارية: متوافقة مع الوظيفة التجارية
• ملكية البيانات: كل خدمة تملك بياناتها

سؤال المقابلة: حدود الخدمات

س: "أنت تصمم منصة تجارة إلكترونية. أين ترسم حدود الخدمات؟"

ج: طبق مبادئ التفكيك:

الخدمة: خدمة الطلبات
المسؤوليات:
  - دورة حياة الطلب (إنشاء، تحديث، إلغاء)
  - إدارة السلة
  - التحقق من الطلب

لا تتضمن:
  - معالجة الدفع (خدمة الدفع)
  - فحص المخزون (خدمة الكتالوج - استعلام فقط)
  - الشحن (خدمة الشحن - مدفوعة بالأحداث)

الاتصال:
  - متزامن: استعلام الكتالوج للسعر/التوافر
  - غير متزامن: إصدار حدث OrderCreated → الدفع، المخزون، الشحن

أنماط الاتصال

الاتصال المتزامن

REST عبر HTTP:

• بسيط، مفهوم على نطاق واسع
• جيد لعمليات CRUD
• التحدي: الفشل المتتالي

gRPC:

• بروتوكول ثنائي، أسرع من REST
• نوع قوي مع Protocol Buffers
• بث ثنائي الاتجاه
• أفضل للاتصال الداخلي بين الخدمات

الاتصال غير المتزامن

قوائم انتظار الرسائل (SQS، RabbitMQ):

المنتج → قائمة الانتظار → المستهلك

• اتصال نقطة إلى نقطة
• موازنة الحمل
• توصيل مضمون

بث الأحداث (Kafka، Kinesis):

المنتج → الموضوع → مستهلكون متعددون

• نمط النشر-الاشتراك
• قدرة إعادة تشغيل الأحداث
• المعالجة في الوقت الحقيقي

سؤال المقابلة: متزامن مقابل غير متزامن

س: "متى تختار الاتصال غير المتزامن على المتزامن؟"

ج:

حالة الاستخدام	نمط الاتصال	السبب
الحصول على تفاصيل المنتج	متزامن (REST/gRPC)	المستخدم ينتظر، يحتاج استجابة فورية
وضع طلب	غير متزامن (حدث)	يمكن معالجته في الخلفية، إرسال تأكيد
إرسال إشعار	غير متزامن (قائمة انتظار)	المستخدم لا ينتظر تسليم البريد
معالجة الدفع	متزامن (مع مهلة)	يحتاج نتيجة فورية للدفع
تحديث فهرس البحث	غير متزامن (حدث)	الاتساق النهائي مقبول

نمط Saga للمعاملات الموزعة

المشكلة

الخدمات الصغيرة لا يمكنها استخدام معاملات ACID التقليدية عبر الخدمات.

Saga القائم على الكوريوغرافيا

كل خدمة تستمع للأحداث وتتصرف:

خدمة الطلبات → حدث OrderCreated
    ↓
خدمة الدفع → حدث PaymentCompleted
    ↓
خدمة المخزون → حدث InventoryReserved
    ↓
خدمة الشحن → حدث ShipmentCreated

الإيجابيات: منفصلة، قابلة للتوسع السلبيات: صعوبة تتبع التدفق الكلي، معالجة فشل معقدة

Saga القائم على التنسيق

منسق مركزي ينسق:

منسق Saga:
  1. استدعاء خدمة الطلبات → إنشاء طلب
  2. استدعاء خدمة الدفع → معالجة الدفع
  3. استدعاء خدمة المخزون → حجز العناصر
  4. استدعاء خدمة الشحن → إنشاء شحنة

عند الفشل في الخطوة 3:
  - تعويض: استرداد الدفع
  - تعويض: إلغاء الطلب

الإيجابيات: تدفق واضح، تصحيح أسهل السلبيات: المنسق نقطة تعقيد واحدة

سؤال المقابلة: تعويض Saga

س: "ماذا يحدث إذا فشلت خدمة الشحن بعد نجاح الدفع؟"

ج: نفذ معاملات تعويضية:

المسار السعيد:
  الطلب → الدفع → المخزون → الشحن ✓

الفشل في الشحن:
  الطلب ✓ → الدفع ✓ → المخزون ✓ → الشحن ✗

التعويض:
  1. تحرير المخزون (تعويض الحجز)
  2. استرداد الدفع (تعويض الشحن)
  3. إلغاء الطلب (أو وضع علامة فشل)
  4. إخطار المستخدم (شرح الفشل)

المبادئ الرئيسية:

• التعويضات يجب أن تكون متساوية القوة
• تخزين حالة saga للاستعادة
• اعتبر المهلات وإعادة المحاولات قبل التعويض

نمط بوابة API

المسؤوليات

• توجيه الطلبات
• المصادقة/التفويض
• تحديد المعدل
• تحويل الطلبات
• تجميع الاستجابات
• التخزين المؤقت

خيارات بوابة API

الخدمة	السحابة	الميزات
Amazon API Gateway	AWS	تكامل Lambda، الاختناق
Apigee	GCP	التحليلات، بوابة المطورين
Azure API Management	Azure	السياسات، بوابة المطورين
Kong	متعددة السحابات	نظام المكونات الإضافية، مفتوح المصدر
AWS ALB	AWS	توجيه بسيط، فعال من حيث التكلفة

سؤال المقابلة: نمط BFF

س: "اشرح نمط Backend for Frontend (BFF)."

ج: أنشئ بوابات API متخصصة لكل نوع عميل:

تطبيق الموبايل → Mobile BFF → الخدمات الصغيرة
تطبيق الويب → Web BFF → الخدمات الصغيرة
API الشريك → Partner BFF → الخدمات الصغيرة

الفوائد:

• حمولات محسنة لكل عميل (الموبايل يحصل على بيانات أقل)
• تدفقات مصادقة خاصة بالعميل
• تطور مستقل

متى تستخدم:

• متطلبات عملاء مختلفة بشكل كبير
• فرق متعددة تملك عملاء مختلفين
• احتياجات تحسين الأداء

مبدأ الهندسة المعمارية: ابدأ ببوابة API واحدة، استخرج BFFs فقط عندما يبرر تباين العملاء العبء الإضافي.

بعد ذلك، سنستكشف أنماط الهندسة المعمارية المدفوعة بالأحداث. :::