فصل كل شيء. دع الخدمات تتواصل من خلال الأحداث، وليس التوقعات حول وقت تشغيل بعضها البعض.

نظامك المتكامل أصبح عنق زجاجة في النشر - كل تغيير يتطلب التنسيق عبر الفرق، وخطأ في الفوترة يؤدي إلى تعطيل التطبيق بأكمله. أو أنك تبني نظامًا جديدًا حيث تتطور القدرات المختلفة بمعدلات مختلفة: إدارة الطلبات تتغير أسبوعيًا، لكن منطق المخزون يتغير ربع سنويًا. تحتاج إلى خدمات يمكن تطويرها ونشرها وتوسيعها بشكل مستقل، تتواصل من خلال الأحداث بدلاً من استدعاءات API المتزامنة التي تخلق سلاسل فشل متتابعة.
Explore more design patterns and system architectures
يمكن لفريق معماري لدينا مساعدتك في تصميم وبناء الأنظمة باستخدام هذا النمط لمتطلباتك المحددة.
تواصل معناالخدمات المصغرة المدفوعة بالأحداث تقوم بتفكيك النظام إلى خدمات يمكن نشرها بشكل مستقل تتواصل بشكل أساسي من خلال الأحداث غير المتزامنة. كل خدمة تمتلك بياناتها، تنشر أحداث المجال عند حدوث تغييرات في الحالة، وتستجيب للأحداث من الخدمات الأخرى. هذا يلغي الربط الزمني - خدمة A لا تحتاج إلى خدمة B لتكون قيد التشغيل لأداء عملها. النمط يدمج CQRS (فصل المسؤولية بين الأوامر والاستعلامات) لفصل نماذج الكتابة والقراءة، وتسجيل الأحداث لالتقاط التاريخ الكامل لتغييرات الحالة، وتنسيق الساجا لإدارة المعاملات متعددة الخدمات دون أقفال موزعة.
المعماري يركز على العمود الفقري للأحداث (Kafka، EventBridge، أو NATS) الذي يوجه أحداث المجال بين الخدمات. كل خدمة لها ثلاث حدود: معالج الأوامر الذي يعالج الطلبات الواردة ويصدر الأحداث، معالج الاستعلامات الذي يخدم الإسقاطات المحسنة للقراءة، ومعالج الأحداث الذي يستجيب للأحداث من الخدمات الأخرى. منسق الساجا ينسق عمليات الأعمال متعددة الخطوات (مثل تنفيذ الطلبات) عن طريق الاستماع للأحداث وإصدار الأوامر التعويضية عند فشل الخطوات.
| الطبقة | التقنيات |
|---|---|
| الحوسبة | Node.js (NestJS)، Python (FastAPI)، Go — لكل خدمة بناءً على خصائص عبء العمل |
| المراسلة | Apache Kafka (MSK)، AWS EventBridge، NATS JetStream، RabbitMQ |
| البيانات | PostgreSQL (معاملات)، DynamoDB (مفتاح-قيمة)، Redis (التخزين المؤقت/الأقفال)، EventStoreDB |
| الأوركسترا | Temporal (تنسيق سير العمل)، AWS Step Functions، منسق ساجا مخصص |
| المراقبة | OpenTelemetry (تتبع موزع)، Datadog، Jaeger، تسجيل منظم مع معرفات الترابط |
| استخدم عندما | تجنب عندما |
|---|---|
| تحتاج الفرق المتعددة إلى النشر بشكل مستقل على إيقاعات مختلفة | فريقك أقل من 5 مهندسين — النظام المتكامل المنظم بشكل جيد أبسط في التشغيل |
| أجزاء مختلفة من النظام لديها خصائص توسيع مختلفة | أنت تبني MVP وتحتاج إلى الشحن بسرعة — الأنظمة الموزعة بطيئة في البناء |
| تحتاج إلى مسارات تدقيق قوية وقدرات إعادة تشغيل الأحداث | كل عملية تتطلب استجابات متزامنة، متسقة بقوة |
| المجال لديه سياقات محدودة طبيعية (الطلبات، المدفوعات، المخزون) | المجال مرتبط بشكل وثيق — تقسيمه يخلق نظامًا متكاملًا موزعًا |
MW لا تتفكك إلى خدمات مصغرة حسب الطبقة التقنية (خدمة API، خدمة البيانات، خدمة المصادقة). نحن نفكك على طول حدود المجال باستخدام DDD (تصميم مدفوع بالمجال) سياقات محدودة. قبل كتابة الكود، نقوم بورشة عمل لتفجير الأحداث لرسم أحداث المجال، الأوامر، والتجمعات — هذا يحدد حدود الخدمة، وليس تفضيلات التكنولوجيا. لقد هاجرنا الأنظمة المتكاملة إلى معماريات مدفوعة بالأحداث للعملاء المؤسسيين، والدروس الأكثر شيوعًا هي: ابدأ بخدمات أقل وأكبر وقسم لاحقًا، وليس العكس.
النماذج لا تعمل من تلقاء نفسها. خط الأنابيب الذي يدرب نماذجك ويتحقق منها وينشرها ويراقبها هو المنتج الفعلي — النموذج هو مجرد ناتج واحد.
تصمم MicrocosmWorks أنظمة تعتمد على الأحداث باستخدام وسطاء رسائل دائمين مثل Apache Kafka أو Amazon EventBridge التي تحتفظ بالأحداث حتى يقوم المستهلكون بمعالجتها بنجاح، مما يضمن عدم فقدان البيانات أثناء الانقطاعات. نحن نطبق dead-letter queues، وسياسات إعادة المحاولة بـ exponential backoff، و circuit breakers حتى لا يقوم microservice فاشل بحظر مسار الأحداث بالكامل. بمجرد أن تتعافى الخدمة التابعة، فإنها تلحق تلقائيًا بالأحداث غير المعالجة بدون تدخل يدوي.
التواصل القائم على الأحداث هو الخيار الأفضل عندما لا تحتاج خدماتك إلى استجابة فورية، أو عندما تحتاج إلى فصل دورات النشر، أو عندما يؤدي إجراء واحد إلى تشغيل عمليات متعددة لاحقة. توصي MicrocosmWorks عادةً بالأنماط القائمة على الأحداث لمعالجة الطلبات، وخطوط أنابيب الإشعارات، واستيعاب التحليلات، مع الاحتفاظ بواجهات برمجة التطبيقات المتزامنة للاستعلامات الموجهة للمستخدم التي تتطلب استجابات في أقل من ثانية. تستخدم العديد من أنظمة الإنتاج التي نبنيها نهجًا هجينًا مع قراءات متزامنة وكتابات غير متزامنة.
تستخدم MicrocosmWorks partition-key-based ordering في مواضيع Kafka لضمان معالجة جميع الأحداث لكيان معين (مثل طلب محدد أو مستخدم) تسلسليًا بواسطة نفس مثيل المستهلك. بالنسبة للسيناريوهات التي تتطلب ترتيبًا عابرًا للكيانات، نقوم بتنفيذ saga orchestrators مع idempotent event handlers التي يمكنها إعادة معالجة الرسائل غير المرتبة بأمان. نقوم أيضًا بتضمين vector clocks أو sequence numbers في حمولات الأحداث حتى يتمكن المستهلكون من اكتشاف تعارضات الترتيب وتسويتها.
تُطبّق MicrocosmWorks نمط Saga pattern مع compensating transactions، حيث تقوم كل microservice بنشر domain events بعد إتمام الـ local transaction الخاصة بها، والـ downstream services تتفاعل وفقًا لذلك أو تُشغل rollback compensations عند الفشل. ندمج هذا مع outbox pattern الذي يكتب الأحداث بشكل ذري إلى جدول outbox محلي جنبًا إلى جنب مع بيانات الأعمال، ثم ينشرها بشكل موثوق إلى الـ message broker. هذا يحقق eventual consistency بدون عقوبات الأداء والموثوقية لـ two-phase commits.
تقوم MicrocosmWorks بتضمين كل حدث بـ correlation IDs و distributed tracing headers باستخدام OpenTelemetry، مما يتيح لنا تصور دورة الحياة الكاملة لمعاملة تجارية عبر جميع microservices المشاركة في أدوات مثل Jaeger أو Grafana Tempo. نقوم أيضًا ببناء لوحات معلومات تدفق الأحداث في الوقت الفعلي التي تعرض throughput، و consumer lag، و processing latency لكل خدمة، مما يسهل تحديد الاختناقات. يتضمن observability stack القياسي لدينا structured logging مع event metadata بحيث يمكن تتبع أي حدث فردي من producer إلى كل consumer في ثوانٍ.