القرارات المعمارية وراء نواة المحفظة والأنظمة المساندة لإحدى أبرز المحافظ الإلكترونية في فيتنام — وما الذي كنا سنفعله بشكل مختلف.
كثيرًا ما تُفهم "Microservices" على أنها تفكيك كل شيء. عمليًا، لا تكمن القيمة في عدد الخدمات بل في رسم الحدود الصحيحة — حول قدرات الأعمال، لا حول الهيكل التنظيمي.
عند بناء نواة المحفظة والأنظمة المساندة لمحفظة إلكترونية على مستوى وطني، عالجنا ملايين المعاملات في ظل متطلبات صارمة للاتساق والأمان وقابلية التوسع. إليك بعض الدروس التي صمدت أمام بيئة الإنتاج.
1. حدود الخدمات تتبع الأعمال
ينبغي أن تمتلك الخدمة قدرة أعمال كاملة وبياناتها. إذا كان لا بد أن تتغير خدمتان معًا عند كل تحديث، فتلك علامة على أن الحد خاطئ — وينبغي أن تكونا خدمة واحدة.
2. النهج القائم على الأحداث لما لا يحتاج إلى التزامن
- حركة الأموال تحتاج إلى اتساق قوي — عالجها بشكل متزامن مع آلية idempotency.
- الإشعارات والتسويات والتحليلات — ادفعها عبر الأحداث وعالجها بشكل غير متزامن حتى لا تعرقل المسار الرئيسي.
- كل حدث هو واقعة حصلت، لا أمر — فيمكن إضافة مستهلكين جدد دون المساس بالمنتِج.
3. نهج API-first بعقود واضحة
تعريف عقود API قبل كتابة الكود يتيح للفرق العمل بالتوازي ويقلل آلام التكامل في النهاية. كل تغيير في العقد يُدار بالإصدارات ولا يكسر المستهلكين الحاليين أبدًا.
لا تمنحك Microservices السرعة مجانًا — إنها تستبدل بالتعقيد في الكود تعقيدًا في التشغيل. لا تدفع هذا الثمن إلا حين يتطلبه حجم العمل فعلًا.
ما الذي كنا سنفعله بشكل مختلف
ابدأ بعدد أقل من الخدمات. فالمونوليث الجيد التقسيم إلى وحدات، الذي يُفكَّك تدريجيًا مع ظهور ضغط التوسع، يكاد يكون دائمًا أرخص من التفكيك المبكر ثم الدمج لاحقًا. وينبغي أن توجد بنية المراقبة (observability) قبل الخدمة الثانية، لا بعد العاشرة.