it-swarm.asia

باستخدام Kafka باعتباره Eventstore (CQRS). فكره جيده؟

على الرغم من أنني واجهت Kafka من قبل ، أدركت مؤخرًا أنه قد يتم استخدام Kafka (أساس) a CQRS ، eventstore .

واحدة من النقاط الرئيسية التي يدعمها كافكا:

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

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

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

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

178
Geert-Jan

من المفترض أن يكون تطبيق كافكا نظامًا للرسائل يحتوي على العديد من أوجه التشابه مع متجر الأحداث ، ولكن على حد تعبيره:

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

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

تحديث

وثائق كافكا :

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

تحديث 2

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

101
eulerfx

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

نستخدمها لعدة حالات استخدام لهذا النموذج على LinkedIn. على سبيل المثال ، يتوفر نظام معالجة الدفق المفتوح المصدر الخاص بنا ، Apache Samza ، مع دعم مدمج لمصادر الحدث.

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

لقد كتبت قليلا عن هذا النمط من استخدام كافكا هنا .

255
Jay Kreps

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

TL، DR. نعم أو لا ، وهذا يتوقف على استخدام مصادر الحدث الخاص بك.

هناك نوعان أساسيان من أنظمة مصادر الأحداث التي أعرفها.

معالجات الحدث المتلقين للمعلومات = نعم

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

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

مصدر الحقيقة الذي يسيطر عليه التطبيق = لا

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

عدم وجود كيان العزلة

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

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

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

عدم اكتشاف الصراع

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

(مزيد من المعلومات


تحديث لكل تعليق

تم حذف التعليق ، لكن السؤال كان مثل: ماذا يستخدم الناس لتخزين الأحداث بعد ذلك؟

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

في السيناريوهات الموزعة ، رأيت عدة تطبيقات مختلفة. يستخدم Jet's مشروع النمر Azure CosmosDB ، مع ميزة "تغيير التغذية" لإعلام المستمعين. تطبيق آخر مشابه سمعت عنه على AWS يستخدم DynamoDB مع ميزة Streams لإعلام المستمعين. من المحتمل أن يكون مفتاح القسم هو معرف الدفق لأفضل توزيع للبيانات (لتقليل مقدار الإفراط في التوفير). ومع ذلك ، فإن إعادة التشغيل الكاملة عبر التدفقات في Dynamo باهظة الثمن (القراءة والتكلفة). لذلك كان هذا الإعداد أيضًا لـ Dynamo Streams لتفريغ الأحداث إلى S3. عندما يأتي مستمع جديد عبر الإنترنت ، أو إذا كان مستمع حالي يريد إعادة قراءة كاملة ، فسوف يقرأ S3 للحاق بالركب أولاً.

مشروعي الحالي هو سيناريو متعدد المستأجرين ، وقمت بتدوير مشروعي على قمة بوستجرس. يبدو شيء مثل Citus مناسبًا لقابلية التوسع ، حيث يتم التقسيم حسب مجرى tent +.

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

27
Kasey Speakman

يمكنك استخدام Kafka كمتجر أحداث ، لكنني لا أوصي بذلك ، على الرغم من أنه قد يبدو خيارًا جيدًا:

  • لا تضمن Kafka إلا التسليم مرة واحدة على الأقل وهناك تكرارات في مخزن الأحداث لا يمكن إزالتها. التحديث: هنا يمكنك قراءة سبب صعوبة الأمر مع تطبيق كافكا وبعض آخر الأخبار حول كيفية تحقيق هذا السلوك أخيرًا: https://www.confluent.io/blog/exactly-once-semantics -هنا ، ممكن- heres-how-Apache-kafka-does-it/
  • نظرًا لعدم ثباتها ، لا توجد طريقة لمعالجة مخزن الأحداث عندما يتطور التطبيق وتحتاج الأحداث إلى تحويل (هناك بالطبع طرق مثل البث ، ولكن ...). مرة واحدة قد تقول أنك لن تحتاج أبدًا إلى تحويل الأحداث ، لكن هذا ليس افتراضًا صحيحًا ، فقد يكون هناك موقف تقوم فيه بالنسخ الاحتياطي للنسخة الأصلية ، لكن يمكنك ترقيته إلى أحدث الإصدارات. هذا هو الشرط الصحيح في الحدث يحركها المباني.
  • لن يصبح أي مكان للاستمرار في لقطات الكيانات/المجاميع وإعادة التشغيل أبطأ وأبطأ. يجب أن يكون إنشاء اللقطات ميزة لمتجر الأحداث من منظور طويل الأجل.
  • يتم توزيع أقسام كافكا المعطاة وهي صعبة الإدارة والنسخ الاحتياطي مقارنة مع قواعد البيانات. قواعد البيانات هي ببساطة أبسط :-)

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

متجر الأحداث عبارة عن خدمة معقدة تتطلب أكثر من ما يمكن أن تقدمه كافكا إذا كنت جادًا في تطبيق مصادر الأحداث و CQRS و Sagas وغيرها من الأنماط في الهندسة المعمارية للأحداث والمحافظة على الأداء العالي.

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

يرجى إلقاء نظرة على eventuate.io microservices إطار عمل مفتوح المصدر لاكتشاف المزيد حول المشاكل المحتملة: http://eventuate.io/

تحديث اعتبارًا من 8 فبراير 2018

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

  1. لا تستخدم Spring - إنه شيء رائع (استخدمه كثيرًا بنفسي) ، ولكنه ثقيل وبطيء في نفس الوقت. وليس منصة منصة microservice على الإطلاق. إنه إطار عمل "فقط" لمساعدتك على تنفيذ واحد (الكثير من العمل وراء هذا ..). الأُطُر الأخرى خفيفة الوزن "فقط" REST أو JPA أو أطر عمل مختلفة التركيز. أوصي على الأرجح منصة ميكروسيرفيس كاملة مفتوحة المصدر الأفضل في فئتها والتي تعود إلى جذور جافا الخالصة: https://github.com/networknt

إذا كنت تتساءل عن الأداء ، يمكنك مقارنة نفسك مع مجموعة المعايير الحالية. https://github.com/networknt/microservices-framework-benchmark

  1. لا تستخدم كافكا على الإطلاق :-)) إنها نصف مزحة. يعني في حين أن كافكا رائع ، إلا أنه نظام مركزي للوسيط. أعتقد أن المستقبل في أنظمة المراسلة بدون وسيط. قد تتفاجأ ولكن هناك أنظمة كافكا أسرع :-) ، بالطبع يجب أن تنزل إلى المستوى الأدنى. انظروا إلى كرونيكل.

  2. بالنسبة إلى متجر الأحداث ، أوصي بامتداد Postgresql المتميز الذي يسمى TimescaleDB ، والذي يركز على معالجة بيانات مواعيد العرض عالية الأداء (الأحداث هي timeseries) في حجم كبير. بالطبع CQRS ، يتم إنشاء مصادر الأحداث (إعادة التشغيل ، إلخ. الميزات) في إطار light4j خارج الصندوق الذي يستخدم Postgres كتخزين منخفض.

  3. للمراسلة ، حاول إلقاء نظرة على Chronicle Queue ، Map ، Engine ، Network. أعني التخلص من هذا الوسط الوسيط القديم الحلول وتذهب مع نظام المراسلة الصغيرة (مضمن). قائمة انتظار Chronicle هي في الواقع أسرع من Kafka. لكنني أوافق على أنه ليس كل ما في حل واحد وتحتاج إلى القيام ببعض التطوير وإلا يمكنك شراء الإصدار Enterprise (المدفوع واحد). في النهاية ، سيتم دفع الجهود المبذولة لبناء طبقة الرسائل الخاصة بك من Chronicle عن طريق إزالة عبء الحفاظ على مجموعة Kafka.

13
kensai

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

بخصوص:

القدرة على إعادة تشغيل سجل الأحداث الذي يسمح للمشتركين الجدد بالتسجيل في النظام بعد وقوعه.

هذا يمكن أن يكون خادعا. غطيت ذلك بالتفصيل هنا: https://stackoverflow.com/a/48482974/741970

6
Dmitry Minkovsky