مقدمة
تُعدّ الطرق التقليدية لمعالجة واستقبال البيانات (مثل المعالجة الدفعية والاستطلاع) غير فعّالة في سياق الخدمات المصغرة المستخدمة في التطبيقات الحديثة. تعمل هذه الطرق على كميات هائلة من البيانات، مما يُؤخر النتيجة النهائية لمعالجتها ويُجبر على تراكم كميات كبيرة من البيانات قبل معالجتها. كما تُضيف هذه الطرق تعقيدًا إضافيًا مطلوبًا لمزامنة الموظفين، وقد تُؤدي إلى عدم استغلال بعضهم بشكل كافٍ على الرغم من استهلاكهم للموارد. في المقابل، نظرًا لأن الحوسبة السحابية تُتيح قابلية توسع سريعة للموارد المحلية، يُمكن معالجة البيانات الواردة آنيًا عن طريق تفويضها إلى عدة موظفين بالتوازي.
بث الأحداث هو نهجٌ لجمع الأحداث الواردة وتفويضها للمعالجة بمرونة، مع الحفاظ على تدفق مستمر للبيانات بين الأنظمة المختلفة. يضمن جدولة البيانات الواردة للمعالجة الفورية أقصى استفادة من الموارد واستجابة فورية. يفصل بث الأحداث بين المُنتجين والمستهلكين، مما يتيح لك الحصول على عدد غير متناسب من كلٍّ منهما حسب الحمل الحالي. وهذا يُتيح استجابات فورية للظروف الواقعية الديناميكية.
تُعد هذه الاستجابة بالغة الأهمية في مجالات مثل التداول المالي، ومراقبة المدفوعات، ومراقبة حركة المرور. على سبيل المثال، تستخدم أوبر بث الأحداث لربط مئات الخدمات المصغرة، وإرسال بيانات الأحداث من تطبيقات الركاب إلى السائقين آنيًا، وأرشفتها لتحليلها لاحقًا.
باستخدام بث الأحداث، بدلاً من انتظار العامل التقليدي لدفعة بيانات على فترات منتظمة، يمكن لوسيط الأحداث إخطار المستخدم (عادةً ما يكون خدمة مجهرية) فور وقوع الحدث وتزويده ببياناته. يتولى وسيط الأحداث توجيه الأحداث واستقبالها وتسليمها. كما يوفر تحمّلاً للأخطاء في حال فشل العامل أو رفضه معالجة حدث ما.
في هذه الورقة البحثية، سنستكشف نهج بث الأحداث وفوائده. كما سنقدم Apache Kafka، وهو وسيط أحداث مفتوح المصدر، وندرس دوره في هذا النهج.
هندسة تدفق الحدث
يُعدّ تدفق الأحداث، في جوهره، تطبيقًا لنمط معماري يُسمى "حانة/اشتراك". وبشكل عام، يتضمن هذا النمط ما يلي:
- المواضيع التي تتناولها الرسائل (بما في ذلك أي بيانات تريد توصيلها).
- الناشرون الذين ينتجون الرسائل
- المشتركين الذين يتلقون الرسائل ويتصرفون بناءً عليها
- وسيط رسائل يقبل الرسائل من الناشرين ويسلمها للمشتركين بالطريقة الأكثر فعالية.
الموضوع أشبه بالفئة التي ترتبط بها الرسالة. تُخزّن المواضيع تسلسل الرسائل باستمرار، وتضمن إضافة رسائل جديدة دائمًا في نهاية التسلسل. بمجرد إضافة رسالة إلى موضوع، لا يُمكن تغييرها لاحقًا.
في حالة البث الحدثي، تكون الفرضية مماثلة، ولكنها أكثر تخصصًا:
- يتم إرسال الأحداث والبيانات الوصفية ذات الصلة كرسائل.
- يتم عادةً تصنيف الأحداث في موضوع ما حسب وقت الوصول.
- يمكن للمشتركين (المعروفين أيضًا باسم المستهلكين) بث الأحداث من أي نقطة في السلسلة حتى اللحظة الحالية.
- على عكس النشر/الاشتراك الفعلي، يمكن الاحتفاظ بالأحداث المتعلقة بموضوع ما لفترة زمنية محددة أو الاحتفاظ بها إلى أجل غير مسمى (كأرشيف).
لا يفرض تدفق الأحداث أي قيود أو افتراضات حول طبيعة الحدث. بالنسبة للوسيط الأساسي، يعني هذا أن المُنتِج قد أبلغه بحدوث أمر ما. ما حدث بالفعل متروك لك لتحديده وإعطاء معنى لتطبيقك. لهذا السبب، من وجهة نظر الوسيط، تُسمى الأحداث رسائل أو سجلات بالتبادل.
ولتوضيح ذلك، فيما يلي رسم تخطيطي مفصل لهندسة تدفق أحداث Kafka من وثائق Confluent:
هناك نموذجان لكيفية استرجاع المستهلكين للبيانات من الوسيط: الدفع والسحب. يشير الدفع إلى بدء وسيط الحدث عملية إرسال البيانات إلى مستهلك متاح أولًا، بينما يعني السحب أن المستهلك يطلب السجلات المتاحة لاحقًا من الوسيط. يبدو هذا التمييز غير ضار، ولكن السحب يُفضل عمليًا.
من الأسباب الرئيسية لعدم شيوع استخدام الدفع الإلكتروني هو عدم قدرة الوسيط على التأكد من قدرة المستخدم على التفاعل مع الحدث. لذلك، قد يُرسل الحدث عدة مرات دون داعٍ مع ضرورة تخزينه في الموضوع. ينبغي على الوسيط أيضًا مراعاة تجميع الأحداث لزيادة الإنتاجية، وهو عكس فكرة بثها بأسرع ما يمكن.
إن قيام المستهلك بسحب البيانات عند جاهزيتها للمعالجة يُقلل من حركة البيانات غير الضرورية على الشبكة ويعزز موثوقيتها. هذا يضمن استلام البيانات فقط عند جاهزيتها للمعالجة. يعتمد وقت المعالجة على منطق العمل ويؤثر على جدولة عدد الموظفين. في كلتا الحالتين، يجب على الوسيط تذكر الأحداث التي أقرّ بها المستهلك.
الآن بعد أن تعرفت على ما هو بث الأحداث وما هي الهندسة المعمارية التي يعتمد عليها، ستتعرف على فوائد هذا النهج الديناميكي.
فوائد بث الأحداث
الفوائد الرئيسية لبث الحدث هي:
- الاتساق: يضمن وسيط الحدث إرسال الأحداث بشكل صحيح إلى جميع المستهلكين المهتمين.
- التسامح مع الخطأ: إذا فشل المستهلك في قبول حدث ما، فيمكن إعادة توجيهه إلى مكان آخر للتأكد من عدم ترك أي حدث دون معالجته.
- إمكانية إعادة الاستخدام: الأحداث المُخزّنة في سلسلة ثابتة. يُمكن إعادة تشغيلها بالكامل أو من نقطة زمنية مُحددة، مما يُتيح لك إعادة معالجة الأحداث في حال تغيّر منطق عملك.
- إمكانية التوسع: المنتجون والمستهلكون عبارة عن كيانات منفصلة ولا يتعين عليهم انتظار بعضهم البعض، مما يعني أنه يمكن توسيع نطاقهم بشكل ديناميكي أو تقليصه اعتمادًا على الطلب.
- سهولة الاستخدام: يتولى وسيط الحدث توجيه الأحداث وتخزينها، مما يؤدي إلى تلخيص المنطق المعقد والسماح لك بالتركيز على البيانات نفسها.
يجب أن يحتوي كل حدث على التفاصيل الضرورية فقط. عادةً ما يكون وسطاء الأحداث فعالين للغاية، ورغم أنه يُنصح بعدم انتهاء صلاحية الأحداث بعد تسجيلها في موضوع ما، إلا أنه لا ينبغي اعتبارهم قاعدة بيانات تقليدية.
على سبيل المثال، من الجيد إظهار تغيّر عدد مشاهدات مقالة ما، ولكن لا داعي لتخزين المقالة كاملةً وبياناتها الوصفية مع هذه المعلومة. بدلًا من ذلك، يمكن أن يتضمن الحدث مرجعًا لمعرّف المقالة في قاعدة بيانات خارجية. بهذه الطريقة، يُمكن تتبّع السجلّ دون إضافة معلومات غير ضرورية أو إفساد سلسلة النقاش.
ستتعرف الآن على Apache Kafka وغيره من وسطاء الأحداث المشهورين، وكيفية مقارنتهم، وكيفية ملاءمتهم لنظام بث الأحداث.
دور أباتشي كافكا
أباتشي كافكا هو وسيط أحداث مفتوح المصدر، مكتوب بلغة جافا، وتديره مؤسسة أباتشي للبرمجيات. يتكون من خوادم وعملاء موزعين يتواصلون باستخدام بروتوكول شبكة TCP مخصص لتحقيق أقصى أداء. يتميز كافكا بموثوقيته العالية وقابليته للتوسع، ويمكن تشغيله على الأجهزة الافتراضية، والأجهزة المادية، والحاويات، وبيئات سحابية أخرى.
لضمان الموثوقية، يُنشر كافكا كمجموعة من خادم واحد أو أكثر. يمكن لهذه المجموعة أن تمتد إلى عدة مناطق سحابية ومراكز بيانات. تتميز مجموعات كافكا بمقاومتها للأخطاء، مما يعني أنه في حالة تعطل الخادم أو انقطاعه، يُعاد تجميع الأجزاء المتبقية لضمان توافر عالٍ للعمليات دون أي تأثير خارجي أو فقدان للبيانات.
لتحقيق أقصى قدر من الكفاءة، لا تؤدي جميع خوادم كافكا الدور نفسه. تُجمّع بعض الخوادم معًا وتعمل كوسيط، مُشكّلةً طبقة تخزين لحفظ البيانات. يمكن دمج خوادم أخرى مع أنظمتك الحالية واستيعاب البيانات كتدفقات أحداث باستخدام كافكا كونيكت، وهي أداة لبث البيانات بشكل موثوق من الأنظمة الحالية (مثل قواعد البيانات العلائقية) إلى كافكا.
يعتبر كافكا المنتجين والمستهلكين عملاء له. كما شرحنا سابقًا، يكتب المنتجون الأحداث إلى وسيط كافكا، الذي يرسلها بدوره إلى المستهلكين المهتمين. في الإعداد الافتراضي، يضمن كافكا معالجة الحدث مرة واحدة فقط في النهاية بواسطة أحد المستهلكين.
في كافكا، تُقسّم المواضيع. هذا يعني توزيع الموضوع على أجزاء عبر وسطاء كافكا مختلفين، مما يضمن قابلية التوسع. كما يضمن كافكا إمكانية قراءة الأحداث المخزنة في مجموعة محددة من المواضيع وأقسامها دائمًا بنفس ترتيب كتابتها.
تجدر الإشارة إلى أن مجرد تقسيم موضوع لا يضمن التكرار، والذي لا يمكن تحقيقه إلا من خلال التكرار عبر المناطق ومراكز البيانات. من الشائع وجود ثلاث نسخ على الأقل من مجموعة في بيئة إنتاجية، مما يعني توفر ثلاث مجموعات من المواضيع والتقسيمات دائمًا.
تكامل كافكا
كما ذكرنا سابقًا، يُمكن استيراد البيانات من الأنظمة الحالية وتصديرها باستخدام Kafka Connect. وهو مُناسب لاستيراد قواعد بيانات كاملة أو تقارير أو مقاييس من خوادمك في مسارات منخفضة زمن الوصول. يُوفر Kafka Connect موصلات لأنظمة بيانات مُختلفة تُتيح لك إدارة البيانات بطريقة قياسية. ومن مزايا استخدام الموصلات بدلًا من حلولك الخاصة أن Connect قابل للتوسع افتراضيًا (يمكن تجميع عدة مُستخدمين معًا) ويُتابع التقدم تلقائيًا.
يتوفر عدد كبير من العملاء للتواصل مع كافكا عبر تطبيقاتك. يدعم العديد من لغات البرمجة، مثل جافا، سكالا، بايثون، .NET، C++، جو، وغيرها. كما تتوفر مكتبة عملاء عالية المستوى تُسمى كافكا ستريمز لجافا وسكالا. تُلخص هذه المكتبة المكونات الداخلية، وتتيح لك الاتصال بسهولة بخادم كافكا وبدء استقبال أحداث البث.
نتيجة
تتناول هذه المقالة نماذج نهج تدفق الأحداث الحديث لمعالجة البيانات والأحداث، ومزاياه مقارنةً بعمليات تصنيف البيانات التقليدية. كما تعرّفت على Apache Kafka كوسيط أحداث ونظام عملائه البيئي.
