خبرة في تطوير خدمة أداة استرداد الأموال مع واجهة برمجة تطبيقات غير متزامنة على كافكا

ما الذي يمكن أن يجعل شركة كبيرة مثل Lamoda من خلال عملية انسيابية وعشرات من الخدمات المترابطة تعمل على تغيير النهج بشكل كبير؟ يمكن أن يكون الدافع مختلفًا تمامًا: من التشريعي إلى الرغبة الكامنة في جميع المبرمجين للتجربة.

لكن هذا لا يعني على الإطلاق أنه لا يمكن الاعتماد على مزايا إضافية. ما الذي يمكن تحقيقه بالضبط إذا طبقت واجهة برمجة تطبيقات تستند إلى الحدث على كافكا ، فإن سيرجي زيكا ( قليل ) سيخبرنا. حول المطبات المحشوة والاكتشافات المثيرة ، أيضًا ، سيكون هناك بالتأكيد - تجربة لا يمكن الاستغناء عنها.



إخلاء المسئولية: تستند هذه المقالة إلى مواد mitap التي عقدها سيرجي في نوفمبر 2018 على HighLoad ++. جذبت تجربة لامودا الحية مع كافكا المستمعين بما لا يقل عن تقارير الجدول الأخرى. يبدو لنا أن هذا مثال رائع على حقيقة أنه من الممكن والضروري دائمًا العثور على أشخاص متشابهين في التفكير ، وسيواصل منظمو HighLoad ++ محاولة خلق جو يفضي إلى ذلك.

عن العملية

Lamoda هي عبارة عن منصة تجارة إلكترونية كبيرة بها مركز اتصال خاص بها ، وخدمة توصيل (والعديد من الشركات التابعة) ، واستوديو للصور ، ومستودع ضخم ، وتعمل جميعها على برمجياتها. هناك العشرات من طرق الدفع ، والشركاء B2B الذين يمكنهم استخدام جزء أو كل هذه الخدمات ويرغبون في معرفة أحدث المعلومات عن منتجاتهم. بالإضافة إلى ذلك ، تعمل لامودا في ثلاث دول بالإضافة إلى الاتحاد الروسي وكل شيء مختلف قليلاً هناك. في المجموع ، ربما هناك أكثر من مائة طريقة لتكوين طلب جديد ، والتي يجب معالجتها بطريقتها الخاصة. كل هذا يعمل بمساعدة عشرات الخدمات التي تتواصل في بعض الأحيان بطريقة غير واضحة. هناك أيضًا نظام مركزي تتمثل مسؤوليته الرئيسية في حالة الطلبات. نسميها BOB ، أنا أعمل معها.

أداة رد الأموال مع واجهة برمجة تطبيقات تستند إلى الأحداث

يتم اختراق الكلمات التي تحركها الأحداث تمامًا ، وسوف نحدد بمزيد من التفصيل ما هو المقصود بهذا. سأبدأ بالسياق الذي قررنا فيه تجربة طريقة API التي تعتمد على أحداث Kafka.



في أي متجر ، بالإضافة إلى الطلبات التي يدفعها العملاء ، هناك أوقات يكون فيها المتجر مطلوبًا لاستعادة الأموال ، لأن المنتج لا يناسب العميل. هذه العملية القصيرة نسبيًا: نقوم بتوضيح المعلومات ، إذا كانت هناك حاجة إلى ذلك ، ونحول الأموال.

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



الدافع لدينا:

1. القانون FZ-54 - لفترة وجيزة ، يطلب منك القانون إبلاغ مكتب الضرائب عن كل معاملة نقدية ، سواء كانت استرداد أو إيصال ، في اتفاقية مستوى الخدمة قصيرة إلى حد ما في بضع دقائق. نحن ، كالتجارة الإلكترونية ، نقوم بعدد قليل من العمليات. من الناحية الفنية ، يعني هذا مسؤولية جديدة (وبالتالي خدمة جديدة) وتحسينات في جميع الأنظمة المعنية.
2. BOB split - المشروع الداخلي للشركة لتخليص BOB من عدد كبير من المسؤوليات غير الأساسية وتقليل تعقيدها الكلي.

هذا الرسم البياني يصور أنظمة لامودا الرئيسية. الآن معظمهم يشبه إلى حد كبير كوكبة من 5-10 خدمات مجهرية حول متراصة متناقص . إنها تنمو ببطء ، لكننا نحاول جعلها أصغر حجمًا ، لأنه أمر مخيف نشر الجزء الذي تم تسليط الضوء عليه في الوسط - لا يمكن السماح به بالسقوط. جميع عمليات التبادل (الأسهم) التي أجبرنا على حجزها ووضعت على حقيقة أن أيًا منها قد لا يكون متاحًا.

هناك أيضًا الكثير من عمليات التبادل في BOB: أنظمة الدفع والتسليم والإشعارات وما إلى ذلك.

من الناحية الفنية ، BOB هي:

• ~ 150k خطوط رمز + ~ 100k خطوط الاختبارات؛
• php7.2 + Zend 1 & Symfony Components 3؛
• > 100 API & ~ 50 التكامل الخارجي ؛
• 4 دول مع منطق الأعمال الخاصة بهم.

إن نشر BOB باهظ الثمن ومؤلمة ، ومقدار الكود والمهام التي يحلها هو أنه لا يمكن لأحد أن يضعها في رأسه. بشكل عام ، هناك العديد من الأسباب لتبسيطها.

عملية العودة

في البداية ، يشارك نظامان في العملية: BOB و Payment. الآن اثنين آخرين تظهر:

• خدمة التهيئة المالية ، والتي ستهتم بمشاكل التهيئة المالية والتواصل مع الخدمات الخارجية.
• أداة استرداد الأموال ، والتي يتم فيها الاستغناء عن عمليات التبادل الجديدة حتى لا تضخيم BOB.

الآن تبدو العملية كما يلي:

1. BOB يتلقى طلب استرداد.
2. يتحدث بوب عن أداة استرداد الأموال هذه.
3. أداة استرداد الأموال تقول الدفع: "استرجع المال".
4. دفع إرجاع المال.
5. تقوم أداة استرداد الأموال و BOB بمزامنة الحالات مع بعضهما البعض ، لأن كلاهما يحتاجان إليها في الوقت الحالي. لسنا مستعدين بعد للتبديل الكامل إلى "أداة استرداد" ، نظرًا لأن BOB لديها واجهة مستخدم وتقارير للمحاسبة وكثير من البيانات التي لا يمكنك نقلها بسهولة. علينا أن نجلس على كرسيين.
6. يترك طلب الضبط المالي.

نتيجة لذلك ، قمنا بعمل حافلة للفعاليات على كافكا - حافلة للحدث ، والتي بدأ كل شيء عليها. الصيحة ، الآن لدينا نقطة واحدة من الفشل (السخرية).



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

ما هي واجهة برمجة تطبيقات الحدث

توجد إجابة جيدة على هذا السؤال في تقرير مارتن فاولر (GOTO 2017) "المعاني المتعددة للهندسة المعمارية التي تحركها الأحداث" .

باختصار ، ما فعلناه:

1. لف جميع التبادلات غير المتزامنة من خلال تخزين الأحداث . بدلاً من إعلام كل مستهلك مهتم بتغير الحالة عبر الشبكة ، نكتب حدث تغيير الحالة إلى المستودع المركزي ، والمستهلكين المهتمين بالموضوع يقرؤون كل شيء يظهر من هناك.
2. حدث في هذه الحالة هو إشعار ( إشعارات ) بأن شيئا ما قد تغير في مكان ما. على سبيل المثال ، تم تغيير حالة الطلب. يمكن للمستهلك الذي يهتم بنوع من البيانات المصاحبة لتغيير الحالة وليس في الإشعار معرفة حالته بنفسه.
3. الخيار الأقصى هو تحديد مصدر حدث كامل ، نقل الحالة ، حيث يحتوي الحدث على جميع المعلومات اللازمة للمعالجة: من أين وإلى أي حالة قمت بالتبديل ، وكيف تغير البيانات بالضبط ، وما إلى ذلك. والسؤال الوحيد هو ما إذا كان الأمر يستحق العناء وكم المعلومات التي يمكنك تخزينها.

كجزء من إطلاق أداة استرداد الأموال ، استخدمنا الخيار الثالث. أدى ذلك إلى تبسيط معالجة الأحداث ، حيث لم يكن من الضروري الحصول على معلومات مفصلة ، بالإضافة إلى أنه استبعد السيناريو عندما يولد كل حدث جديد زيادة في توضيح طلبات الحصول على الطلبات من المستهلكين.

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

تبادل المتزامن كما هو

للتبادلات غير المتزامنة ، يستخدم قسم PHP عادةً RabbitMQ. قمنا بجمع بيانات الطلب ، ووضعناها في قائمة الانتظار ، وقراءتها من نفس الخدمة قراءتها وإرسالها (أو لم يرسلها). لواجهة برمجة التطبيقات نفسها ، تستخدم لامودا Swagger بنشاط. نقوم بتصميم واجهة برمجة التطبيقات (API) ، ووصفها في Swagger ، وإنشاء رمز العميل والخادم. نستخدم أيضًا JSON RPC 2.0 المتقدمة قليلاً.

هنا وهناك ، يتم استخدام حافلات esb ، يعيش شخص ما على activeMQ ، ولكن بشكل عام ، RabbitMQ هو المعيار .

تبادل المتزامن أن يكون

عند تصميم تبادل من خلال حافلة الأحداث ، يتم تتبع القياس. وصفنا بالمثل التبادل المستقبلي للبيانات من خلال وصف هيكل الحدث. تنسيق yaml ، يجب أن يتم إنشاء الشفرة من قبلنا ، يقوم المولد بإنشاء DTO وفقًا للمواصفات ويعلم العملاء والخوادم كيفية التعامل معهم. يذهب الجيل إلى لغتين - golang و php . هذا يبقي المكتبات متسقة. المولد مكتوب بلغة golang ، والذي استلم اسم gogi به.

البحث عن الحدث في كافكا هو شيء نموذجي. يوجد حل من الإصدار الرئيسي لمؤسسة كافكا كونفلوينت ، وهناك نكادي ، وهو حل من "إخواننا" في مجال Zalando. يتمثل دافعنا في البدء بفانيليا كافكا في ترك الحل مجانيًا حتى نقرر أخيرًا ما إذا كنا سنستخدمه في كل مكان ، وأيضًا نترك مجالًا للمناورة والتحسينات: نريد دعمًا لـ JSON RPC 2.0 ، ومولدات لغتين ، ونرى ماذا.

ومن المفارقات أنه حتى في مثل هذه الحالة السعيدة ، عندما يكون هناك عمل مماثل لشركة زالاندو ، التي اتخذت قرارًا مماثلاً ، لا يمكننا استخدامها بفعالية.

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

أحداث حافلة

أو حافلة الحدث. هذه مجرد بوابة http عديمي الجنسية تأخذ عدة أدوار مهمة:

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

لماذا

نحن نعمل في شركة كبيرة مع عملية انسيابية. لماذا تغيير شيء ما؟ هذه تجربة ونتوقع الحصول على العديد من الفوائد.

1: تبادل 1+ (واحد إلى كثير)

مع Kafka ، من السهل جدًا توصيل مستهلكين جدد بواجهة برمجة التطبيقات.

افترض أن لديك دليلًا يجب تحديثه في العديد من الأنظمة في وقت واحد (وفي بعض الأنظمة الجديدة). في السابق ، اخترعنا حزمة تقوم بتطبيق set-API ، وتم إبلاغ عناوين المستهلكين إلى النظام الرئيسي. الآن يرسل النظام الرئيسي تحديثات للموضوع وكل شخص مهتم بالقراءة. لقد ظهر نظام جديد - قاموا بتوقيعه على الموضوع. نعم ، حزمة أيضا ، ولكن أبسط.

في حالة أداة الاسترداد ، وهي قطعة من BOB ، من المريح بالنسبة لنا أن نبقيها متزامنة من خلال Kafka. يقول الدفع أنهم أعادوا الأموال: BOB ، RT اكتشفت ذلك ، غيرت وضعهم ، اكتشفت خدمة التهيئة المالية عن ذلك وطردت شيكًا.



لدينا خطط لتقديم خدمة إشعارات واحدة ، والتي من شأنها إخطار العميل بالأخبار المتعلقة بطلبه / عوائده. الآن تنتشر هذه المسؤولية بين النظم. سيكون كافياً بالنسبة لنا لتدريس خدمة الإشعارات لالتقاط المعلومات ذات الصلة من كافكا والرد عليها (وتعطيل هذه الإشعارات في الأنظمة الأخرى). لن تكون هناك حاجة للتبادلات المباشرة الجديدة.

البيانات مدفوعة

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

سجل النسخ المتماثل

لا تختفي الرسائل بعد القراءة ، كما في RabbitMQ. عندما يحتوي الحدث على معلومات كافية للمعالجة ، لدينا تاريخ من التغييرات الأخيرة على الكائن ، وإذا أمكن ، القدرة على تطبيق هذه التغييرات.

تعتمد فترة تخزين سجل النسخ المتماثل على كثافة الكتابة لهذا الموضوع ، حيث يتيح لك Kafka وضع قيود بمرونة على وقت التخزين وحجم البيانات. بالنسبة للموضوعات المكثفة ، من المهم أن يتوفر لجميع المستهلكين الوقت الكافي لقراءة المعلومات قبل اختفائها ، حتى في حالة عدم القدرة على التشغيل على المدى القصير. عادةً ما يتم تخزين بيانات وحدات الأيام ، وهو ما يكفي تمامًا للحصول على الدعم.



ثم إعادة سرد بعض الوثائق ، لأولئك الذين ليسوا على دراية كافكا (الصورة هي أيضا من الوثائق)

هناك قوائم انتظار في AMQP: نكتب رسائل إلى قائمة الانتظار للمستهلك. كقاعدة عامة ، تتم معالجة قائمة انتظار واحدة بواسطة نظام واحد بنفس منطق العمل. إذا كنت بحاجة إلى إخطار عدة أنظمة ، يمكنك تعليم التطبيق أن يكتب في قوائم انتظار متعددة أو تكوين التبادل مع آلية fanout ، التي تقوم بنسخها بنفسها.

يحتوي Kafka على موضوع تجريد مماثل تكتب فيه الرسائل ، لكنها لا تختفي بعد القراءة. بشكل افتراضي ، عند الاتصال بكافكا ، تتلقى جميع الرسائل ، وفي الوقت نفسه هناك فرصة لحفظ المكان الذي تركته فيه. وهذا يعني أنك تقرأ بالتتابع ، ولا يمكنك وضع علامة على الرسالة كمقروءة ، ولكن يمكنك حفظ المعرف ، الذي يستمر في القراءة منه. يُطلق على المعرف الذي تتوقف عنده إزاحة ، والآلية هي إزاحة الالتزام.

وفقا لذلك ، يمكن تنفيذ منطق مختلف. على سبيل المثال ، لدينا BOB في 4 حالات لدول مختلفة - لامودا في روسيا وكازاخستان وأوكرانيا وروسيا البيضاء. نظرًا لنشرها بشكل منفصل ، فإن لديها القليل من التكوينات الخاصة بها ومنطق العمل الخاص بها. في الرسالة ، نشير إلى البلد الذي يشير إليه. يقرأ كل مستهلك BOB في كل بلد بمجموعة مختلفة ، وإذا كانت الرسالة لا تنطبق عليه ، فتخطاها ، على سبيل المثال ارتكاب تعويض على الفور +1. إذا تمت قراءة نفس الموضوع من خلال خدمة الدفع الخاصة بنا ، فعندئذ يتم ذلك مع مجموعة منفصلة ، وبالتالي لا تتداخل الإزاحة.

متطلبات الحدث:

• اكتمال البيانات. أتمنى أن يكون هناك ما يكفي من البيانات في هذا الحدث حتى يمكن معالجتها.

• النزاهة. نقوم بتفويض حافلة الأحداث للتحقق من أن الحدث ثابت ويمكنه التعامل معه.
• النظام مهم. في حالة العودة ، نحن مضطرون للعمل مع التاريخ. مع الإخطارات ، لا يكون الترتيب مهمًا ، إذا كانت إعلامات متجانسة ، فسيكون البريد الإلكتروني هو نفسه بغض النظر عن الترتيب الذي وصل أولاً. في حالة العودة ، هناك عملية واضحة ، إذا قمت بتغيير الطلب ، فستكون هناك استثناءات ، لن يتم إنشاء أو إعادة الأموال - سننتهي بحالة مختلفة.
• الاتساق. لدينا مستودع ، والآن بدلاً من API ، نقوم بإنشاء الأحداث. نحن بحاجة إلى وسيلة لنقل المعلومات بسرعة وبتكلفة منخفضة عن الأحداث الجديدة والتغييرات إلى الأحداث الموجودة في خدماتنا. يتم تحقيق ذلك باستخدام مواصفات شائعة في مستودع git ومولدات الشفرات. لذلك ، يتم تنسيق العملاء والخوادم في الخدمات المختلفة معنا.

كافكا في لامودا

لدينا ثلاث منشآت كافكا:

1. سجلات.
2. البحث والتطوير.
3. الأحداث الحافلة.

اليوم نحن نتحدث فقط عن النقطة الأخيرة. في أحداث حافلة ، ليس لدينا منشآت كبيرة جدا - 3 وسطاء (خوادم) وما مجموعه 27 موضوعا. كقاعدة عامة ، موضوع واحد هو عملية واحدة. لكن هذه لحظة حساسة ، والآن سنتطرق إليها.



أعلاه هو مخطط rps. تتميز عملية استرداد الأموال بخط الفيروز (نعم ، الخط الموجود على محور X) ، والوردي هو عملية تحديث المحتوى.

يحتوي كتالوج Lamoda على ملايين المنتجات ، مع تحديث البيانات طوال الوقت. بعض المجموعات تخرج عن الموضة ، يتم إصدار مجموعات جديدة بدلاً منها ، وتظهر نماذج جديدة باستمرار في الكتالوج. نحاول أن نتنبأ بما سيكون مثيرًا للاهتمام لعملائنا غدًا ، لذلك نشتري باستمرار أشياء جديدة ونصوِّرها ونحدّث النافذة.

القمم الوردية هي تحديث للمنتج ، أي تغييرات في المنتجات. يمكن أن نرى أن الرجال التقطوا الصور ، والتقطوا الصور ، ثم مرة أخرى! - تحميل حزمة من الأحداث.

أحداث لامودا تستخدم الحالات

نحن نستخدم الهندسة المعمارية المشيدة لمثل هذه العمليات:

• تتبع حالات العودة : الحث على اتخاذ الإجراءات وتتبع الحالات من جميع الأنظمة المعنية. الدفع ، الحالات ، المالية ، الإخطارات. جربنا هنا النهج ، وصنعنا الأدوات ، وجمعنا جميع الأخطاء ، وكتبنا المستندات وأخبرنا الزملاء بكيفية استخدامها.
• تحديث بطاقات المنتج: التكوين ، البيانات الوصفية ، الخصائص. يقرأ نظام واحد (الذي يعرض) ، والعديد من الكتابة.
• البريد الإلكتروني والدفع والرسائل القصيرة : يتم جمع الطلب ، وصل الطلب ، تم قبول الإرجاع ، وما إلى ذلك ، الكثير منهم.
• المخزون ، تحديث المستودع - تحديث كمي للعناصر ، مجرد أرقام: الاستلام في المستودع ، العودة. من الضروري أن تعمل جميع الأنظمة المتعلقة بحفظ البضائع مع البيانات الأكثر صلة. الآن نظام ترقية الصرف معقد للغاية ، سوف يقوم كافكا بتبسيطه.
• تحليل البيانات (قسم البحث والتطوير) ، أدوات ML ، التحليلات ، الإحصاءات. نريد أن تكون المعلومات شفافة - لأن هذا كافكا مناسب تمامًا.

الآن ، الجزء الأكثر إثارة للاهتمام هو حول الأقماع المحنطة والاكتشافات المثيرة للاهتمام التي وقعت على مدى ستة أشهر.

قضايا التصميم

لنفترض أننا نريد عمل شيء جديد - على سبيل المثال ، نقل عملية التسليم بأكملها إلى كافكا. يتم الآن تنفيذ جزء من العملية في معالجة الطلبات في BOB. وراء نقل الطلب إلى خدمة التوصيل ، النقل إلى مستودع وسيط ، وما إلى ذلك ، هناك نموذج حالة. هناك متراصة كاملة ، حتى اثنين ، بالإضافة إلى مجموعة من واجهات برمجة التطبيقات للتسليم. انهم يعرفون الكثير عن التسليم.

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

دفق البيانات

في حالة كافكا ، يطرح السؤال عن تنظيم تدفق البيانات. ترتبط هذه المهمة باختيار الإستراتيجية لعدة نقاط ، وسوف نمر بها جميعًا.

في موضوع واحد أو في مختلف؟

لدينا مواصفات الحدث. في BOB ، نكتب أن مثل هذا الطلب يجب أن يتم تسليمه ، ونشير إلى: رقم الطلب ، وتكوينه ، وبعض SKU والرموز الشريطية ، إلخ. عندما تصل البضاعة إلى المستودع ، سيتمكن التسليم من استلام الحالات والطوابع الزمنية وكل ما هو مطلوب. لكننا نريد كذلك تلقي تحديثات على هذه البيانات في BOB. نحن نواجه العملية العكسية للحصول على البيانات من التسليم. هل هذا هو نفس الحدث؟ أم هو تبادل منفصل يستحق موضوع منفصل؟

على الأرجح ، ستكون متشابهة جدًا ، وإغراء جعل موضوع واحد غير معقول ، لأن الموضوع المنفصل هو مستهلكين منفصلين ، تكوينات منفصلة ، جيل منفصل من كل هذا. لكن ليس حقيقة.

مجال جديد أم حدث جديد؟

ولكن إذا كنت تستخدم نفس الأحداث ، فثمة مشكلة أخرى. على سبيل المثال ، لا تستطيع جميع أنظمة التسليم إنشاء DTO التي يمكنها إنشاء BOBs. نرسل لهم معرفًا ، لكنهم لا يحفظونهم ، لأنهم لا يحتاجون إليه ، ومن وجهة نظر بدء عملية حافلة الحدث ، هذا الحقل مطلوب.

إذا قدمنا ​​قاعدة لحافلة الأحداث التي يتطلبها هذا الحقل ، فسنضطر إلى تعيين قواعد تحقق إضافية في BOB أو في معالج حدث البداية. يبدأ التحقق من الصحة في الزحف على الخدمة - فهي ليست مريحة للغاية.

— . , - , , , , . — . — , . JSON .

refunds . -, refund update, type, , update . «» , , type.

Kafka Avro , Confluent. . replication log, «». , , : , . , , , .

partitions

Kafka partitions. , , , .

Kafka . partition, . . , , , . , , , Kafka partition, Kafka — , .

Kafka ? ( JSON) key. -, , partition .

refunds , partition, , . - , partition.

Events vs commands

, . Event — : , - - (something_happened), , item refund. - , «item » refund , « refund» - .

, , — , - . something_happened (item_canceled, refund_refunded), something_should_be_done. , item .

, , . , . , do_something. , - ; , ; , -, - . , do_something, , .



RabbitMQ, , http, response — , . Kafka, , Kafka, , , .

, - , - . , , - . , «item_ready_to_refund», , refund , , «money_refunded». , .

الفروق الدقيقة

: , - , , . , offset , .

, , . , events-bus, , PostgreSQL, MySQL UNSIGNED INT, PostgreSQL INT. , Id . Symfony . , , , , offset, , . , Symfony , offset.

- — , Kafka , . . .

Kafka tooling offset. , — , , redeployments. Kafka tooling offset, .

— replication log vs rdkafka.so — . PHP, PHP, , , Kafka rdkafka.so, - . , , , - . , .

partitions, consumers >= topic partitions . , . , partitions. , partition, 20 , , . , , partitions.

مراقبة

, , , , .

, , , , , , . Kafka , . , .



, , , events-bus , . , Refund Tool , BOB - ( ).



consumer-group lag. , . , 0, . Kafka , .

Burrow , Kafka. API consumer-group , . Failed warning, , — , . , .



API. bob-live-fifa, partition refund.update.v1, , lag 0 — offset -.



updated_at SLA (stuck) . , , . Cron, , 5 refund ( ), - , . Cron, , 0, .

, , :

• ;
• ;
• .

, — API Kafka, .
-, HighLoad++ , , .
-, KnowledgeConf . , 26 , .
PHP Russia ++ ( DevOpsConf ) — , .