السبب الأقوى لاعتماد العمارة المستندة إلى الأحداث ليس لأنها تبدو حديثة. إنما لأنها تسمح للأنظمة بالتفاعل مع نفس التغيير دون أن تكون مرتبطة ارتباطاً وثيقاً بنفس مسار الطلب.
هذا مفيد عندما:
- تتعلق خدمات متعددة بنفس حدث المجال
- تكون ردود الفعل الفورية شبه الحقيقية مهمة
- يجب أن تتطور المستهلكون بشكل مستقل
تعتبر Kafka واحدة من الطرق للقيام بذلك لأنها تمنحك سجلًا دائمًا من الأحداث بدلاً من اتصال مباشر نقطة إلى نقطة.
ما الذي يتغير
بدلاً من استدعاء خدمة واحدة مباشرةً لكل نظام تابع، تقوم بنشر حدث وتتحرك للأمام. تقرر الأنظمة التالية كيفية استهلاكه.
قد يبدو عقد الحدث البسيط كما يلي:
{
"type": "order.created",
"orderId": "ord_123",
"customerId": "cus_456",
"occurredAt": "2024-07-20T10:00:00Z"
}
هذا يمنحك فك الارتباط. كما أنه يزيد من تعقيد العمليات:
- تساؤلات الطلب
- التأكيد على عدم التكرار
- سلوك إعادة التشغيل
- التأخير وصحة المستهلك
لذا فإن الحجة الحقيقية لصالح Kafka ليست "الوقت الحقيقي أفضل من مهام كرون" كشعار. بل إن بعض المجالات تستفيد من التعبير عن التغييرات التجارية كسلسلة أحداث بدلاً من مجموعة من الاستدعاءات المتزامنة المرتبطة ارتباطاً وثيقاً.
متى تكون جديرة بالاهتمام
استخدم العمارة المستندة إلى الأحداث عندما تكون ردود الفعل المستقلة المتعددة مهمة.
لا تستخدم Kafka فقط لتجنب كتابة كود تطبيق مباشر لنظام CRUD بسيط.
قراءة إضافية