التالي هو دليل بسيط لمساعدة المرسلين على الشعور بالراحة عند إنشاء webhook لأحداث Bird واستهلاك البيانات باستخدام البنية التحتية داخل AWS.
تُعتبر webhooks الأحداث اللحظية من Bird أداة ذات قيمة كبيرة للمُرسلين للحصول على البيانات بشكل تلقائي في أنظمتهم. يمكن أن يُسهِل هذا عمليات التشغيل الآلي مثل تحديث قوائم البريد، أو بدء رحلات البريد الإلكتروني الآلي، أو ملء لوحات المعلومات الداخلية. بينما يمكن الوصول إلى نفس بيانات الأحداث عبر واجهة المستخدم لـ Bird باستخدام البحث في الأحداث، أو برمجيًا من خلال الاستفادة من واجهة برمجة تطبيقات الأحداث من Bird، فإن القيود المفروضة على عدد السجلات المعادة في طلب واحد أو حدود المعدل المفروضة على نقطة النهاية لواجهة برمجة التطبيقات يمكن أن تجعل كلا الأسلوبين مُقيّدين للمُرسلين الكبار والمعقدين.
تمكّن webhooks الأحداث اللحظية المُرسل من تكوين نقطة نهاية حيث تنقل Bird البيانات إليها، ويمكن استهلاك البيانات دون الحاجة إلى جدولة وظائف كرون لجلب البيانات. هناك أيضًا مقايضات لوجستية عند جلب البيانات بدلاً من دفعها إليك، مثل الحاجة لتحديد الفترة الزمنية والمعايير لاستخدامها في كل طلب لواجهة برمجة التطبيقات. إذا لم تصطف الفترات الزمنية بشكل مثالي فإنك تخاطر بفقدان البيانات، وإذا تداخلت الفترات الزمنية فإنك تحتاج إلى التعامل مع سجلات البيانات المكررة. مع webhooks اللحظية، تُرسل بيانات الأحداث ببساطة إلى نقطة النهاية الخاصة بك حيث تصبح متاحة ضمن Bird.
بينما يتم فهم فوائد الحصول على بيانات الأحداث في الوقت الحقيقي لتحفيز عمليات التشغيل الآلي مجموعة اتجاه الأسفل من قبل العديد من المرسلين، قد تكون عملية تنفيذ واستهلاك webhooks الفعلية مخيفة. يمكن أن يكون ذلك صحيحًا خاصةً إذا لم تكن معتادًا على المكونات التقنية لإنشاء نقطة نهاية ومعالجة البيانات برمجيًا. هناك خدمات متاحة تستهلك بيانات webhooks من Bird وتنقلها تلقائيًا إلى قاعدة البيانات الخاصة بك – أحد الأمثلة سيكون StitchData، الذي تحدثنا عنه في الماضي. ومع ذلك، إذا كنت ترغب في مزيد من التحكم في العملية يمكنك إنشاء المكونات بسهولة بنفسك. التالي هو دليل بسيط لمساعدة المرسلين على الشعور بالراحة عند إنشاء webhook لأحداث Bird واستهلاك البيانات باستخدام البنية التحتية داخل AWS.
تكوين وجهة نقطة نهاية Webhook
عندما يتم إنشاء حدث Bird، نريد أن يتم بث بيانات الحدث في الوقت الفعلي إلى نقطة نهاية في AWS حتى نتمكن من استهلاك تلك البيانات واستخدامها برمجيًا. سيتم إرسال البيانات من Bird إلى نقطة الهدف، والتي ستمرر الحزمة إلى دالة لامبدا ستقوم بمعالجة وتخزين البيانات في سعة تخزين S3. يمكن رؤية مخطط بياني عالي المستوى لتدفق البيانات الموضح أدناه:
لتنفيذ سير العمل هذا، دعنا نقوم ببنائها في الاتجاه المعاكس بدءًا بإنشاء سعة تخزين S3 حيث سنقوم بتخزين بيانات الحدث الخاصة بنا ثم العمل إلى الوراء - إضافة كل عنصر يكمل ما قمنا ببنائه.
إنشاء سعة تخزين S3 لتخزين بيانات الويب
قبل إنشاء محمل الموازنة لقبول البيانات، أو دالة اللامبدا لتخزين البيانات، نحتاج أولاً إلى إنشاء سعة تخزين S3 حيث سيتم تخزين البيانات. للقيام بذلك، انتقل إلى خدمة S3 داخل AWS واضغط على “إنشاء سعة تخزين.” ستتم مطالبتك بتعيين اسم لسعة التخزين الخاصة بك وتحديد المنطقة - تأكد من استخدام نفس المنطقة لمحمل الموازنة ALB ودالة اللامبدا. عندما يتم إنشاء سعة تخزين S3 الخاصة بك، ستكون فارغة - إذا كنت ترغب في تنظيم البيانات داخل مجلد، يمكنك إما إنشاء الدليل المقصود الآن، أو سيتم إنشاء الدليل عندما تقوم دالة اللامبدا الخاصة بك بتخزين الملف. في هذا المثال، قمنا بتسمية سعة تخزين S3 الخاصة بنا “bird-webhooks” وأنشأنا مجلدًا باسم “B Event Data” لتخزين بيانات الحدث الخاصة بنا - ستشاهد هذه الأسماء مشارة إليها في دالة اللامبدا الخاصة بنا أدناه.
إنشاء دالة لامبدا لاستهلاك البيانات
ستتم معالجة وتخزين البيانات فعليًا بواسطة دالة لامبدا يتم تنشيطها بواسطة محمل الموازنة التطبيقية الخاص بنا (ALB).
الخطوة الأولى هي إنشاء دالة لامبدا الخاصة بك عن طريق الانتقال إلى خدمة لامبدا داخل AWS والنقر على “إنشاء دالة.” ستتم مطالبتك بتعيين اسم لدالة لامبدا الخاصة بك وتحديد لغة البرمجة التي ستكتب فيها دالتك. في هذا المثال، نستخدم Python كلغة تشغيل.
الآن نحتاج إلى تطوير دالة اللامبدا الخاصة بنا. للحظة، دعنا نفترض أن محمل الموازنة التطبيقية الخاص بنا قد تم تكوينه ويمرر حزمة الويب لدالة اللامبدا الخاصة بنا - ستتلقى اللامبدا حزمة تتضمن الرؤوس والهيئة بالكامل. يتم تمرير الحزمة إلى دالة اللامبدا الخاصة بنا باستخدام الكائن "الحدث" كمعجم. يمكنك الرجوع إلى الرؤوس والهيئة الخاصة بالحزمة بشكل مستقل عن طريق الوصول إلى كائنات "headers" و"body" داخل الحزمة. في هذا المثال، سنقوم ببساطة بقراءة الرأس "x-messagesystems-batch-id"، حيث أن معرف الدفعة هو قيمة فريدة تم إنشاؤها بواسطة Bird لدفعة الويب، واستخدامها كاسم الملف عند تخزين الهيئة كملف مسطح في S3؛ ومع ذلك، قد ترغب في إضافة ميزات إضافية مثل التحقق من المصادقة أو معالجة الأخطاء حسب الحاجة.
عند تخزين الحزمة كملف مسطح على S3، سنحتاج إلى تحديد اسم سعة S3، الموقع، واسم الملف الذي سيتم تخزين بيانات الحزمة فيه. في دالة اللامبدا الخاصة بنا، نقوم بذلك ضمن الدالة "store_batch". في هذا المثال، سنقوم بتخزين الدفعة الكاملة كملف واحد، مما يساعد في ضمان جمع البيانات وتخزينها قبل انتهاء مهلة اتصال HTTP بين Bird ووجهة النهاية الخاصة بك. بينما يمكنك ضبط إعدادات مهلة الاتصال على محمل الموازنة الخاص بك، لا يوجد ضمان بأن الاتصال لن ينتهي على جانب الإرسال (في هذه الحالة Bird) أو أن الاتصال لن يتم إنهاءه قبل انتهاء تنفيذ دالة اللامبدا الخاصة بك. يعتبر من الأفضل الحفاظ على وظيفتك كعملية مستهلكة فعالة قدر الإمكان وترك أنشطة معالجة البيانات للعمليات اللاحقة حيث أمكن ذلك - مثل تحويل الحزمة بتنسيق JSON إلى ملف CSV، أو تحميل بيانات الحدث في قاعدة بيانات.
من المهم أن نلاحظ أنك قد تحتاج إلى تحديث الأذونات الخاصة بدالة اللامبدا الخاصة بك. ستحتاج دور التنفيذ الخاص بك إلى أذونات PutObject وGetObject لسعة S3. يُعتبر من الجيد فرض مبدأ أقل امتياز لذلك أوصي بتحديد هذه الأذونات فقط لسعة S3 التي سيتم فيها تخزين حزم الويب.
يمكنك العثور على عينة من دالة اللامبدا المستهلكة الخاصة بنا هنا.
كنبذة سريعة حول معرف الدفعة: سيقوم Bird بتجميع الأحداث في حزمة واحدة، حيث قد تحتوي كل دفعة على 1 إلى 350 سجل حدث أو أكثر. سيتم إعطاء الدفعة معرف دفعة فريد، يمكن استخدامه لعرض حالة الدفعة من خلال استخدام API Webhooks للحدث أو داخل حساب Bird الخاص بك بالنقر فوق تدفق الويب واختيار “حالة الدفعة.” في حال لم يتم تسليم حزمة الويب، مثل أثناء مهلة الاتصال، فسيقوم Bird تلقائيًا بإعادة المحاولة باستخدام نفس معرف الدفعة. يمكن أن يحدث ذلك عندما تعمل دالة اللامبدا الخاصة بك بالقرب من وقت الرحلة الكاملة الأقصى البالغ 10 ثوانٍ وهذا سبب لتحسين وظيفة المستهلك لتقليل وقت التنفيذ.
للتعامل مع جميع أنشطة معالجة البيانات، أوصي بإنشاء دالة لامبدا منفصلة يتم تنفيذها كلما تم إنشاء ملف جديد على سعة S3 - وبهذه الطريقة، يتم تنفيذ معالجة البيانات بشكل غير متزامن مع نقل البيانات، ولا يوجد خطر فقدان البيانات بسبب إنهاء الاتصال. أتحدث عن دالة اللامبدا الخاصة بالمعالجة في قسم لاحق.
إنشاء محمل موازنة التطبيقات
لتلقي حزمة ويب، نحتاج إلى توفير نقطة نهاية لإرسال الحزم إليها. نقوم بذلك عن طريق إنشاء محمل موازنة التطبيقات داخل AWS من خلال الانتقال إلى EC2 > محمل الموازنة والنقر على “إنشاء محمل موازنة.” ستتم مطالبتك باختيار نوع محمل الموازنة الذي تريد إنشاءه - بالنسبة لهذا، نريد إنشاء محمل موازنة التطبيقة. نحتاج إلى استخدام محمل موازنة التطبيق (ALB) لبناء مستهلكنا لأن إشعارات الويب للحدث سيتم إرسالها كطلب HTTP، وتُستخدم ALBs لتوجيه طلبات HTTP داخل AWS. يمكننا تنفيذ بوابة HTTP كبديل؛ ومع ذلك، نستخدم ALB لهذا المشروع لأنه أخف وزناً وأكثر فعالية من حيث التكلفة من بوابة HTTP. من المهم أن نلاحظ أنه إذا اخترت استخدام بوابة HTTP، فقد يكون تنسيق الحدث مختلفًا عن ALB، وبالتالي ستحتاج وظيفة اللامبدا الخاصة بك إلى التعامل مع كائن الطلب وفقًا لذلك.
بمجرد إنشاء ALB، ستتم مطالبتك بتعيين اسم لـ ALB الخاص بك وتكوين المخطط وإعدادات الوصول/الأمان - نظرًا لأننا نخطط لتلقي بيانات الحدث من مصدر خارجي (Bird)، سنرغب في أن يكون ALB الخاص بنا متاحًا على الإنترنت. تحت "المستمعين والتوجيه"، يجب أن يستمع ALB إلى HTTPS على المنفذ 443، ونريد إنشاء مجموعة مستهدفة تشير إلى دالة اللامبدا الخاصة بنا بحيث يقوم ALB بإعادة توجيه الطلبات الواردة إلى دالة اللامبدا المستهلكة التي أنشأناها أعلاه. تحتاج أيضًا إلى التأكد من أن المجموعة الأمنية لديها إذن لقبول الحركة عبر المنفذ 443.
إنشاء سجل DNS لمحمل الموازنة
لتسهيل استخدام ALB كنقطة نهاية، سنقوم بإنشاء سجل A في DNS يشير إلى ALB الخاص بنا. للقيام بذلك، يمكننا استخدام خدمة AWS Route 53 (أو مزود DNS الحالي الخاص بك) وإنشاء سجل A لاسم المضيف الذي ترغب في استخدامه كنقطة نهاية (مثل spevents.<your_domain>). يجب أن يتم تكوين سجل A للإشارة إلى ALB الذي أنشأناه. إذا كنت تستخدم Route 53 لإدارة سجلات DNS، يمكنك الرجوع إلى مثيل ALB مباشرةً عن طريق تمكين “Alias” واختيار ALB؛ وإلا، إذا كنت تستخدم مزود DNS خارجي، يجب أن توجه سجل A إلى عنوان IP العام لمثيل ALB.
أوصي باستخدام أداة مثل Postman لاختبار أن كل شيء قد تم تكوينه بشكل صحيح قبل تمكين الويب الخاص بـ Bird. يمكنك إجراء طلب POST إلى نقطة النهاية الخاصة بك وتأكيد استلام الرد. إذا لم يُرجع طلب POST الخاص بك استجابة، قد تحتاج إلى التحقق بأكثر من مره بأن ALB الخاص بك يستمع إلى المنفذ الصحيح.
إنشاء Webhook لـ Bird
الآن نحن جاهزون لإنشاء الويب في Bird واستخدام اسم المضيف الذي يحدده سجل A أعلاه كنقطة نهايتنا المستهدفة. لإنشاء الويب، انتقل إلى قسم الويب داخل حساب Bird الخاص بك وانقر على “إنشاء ويب.” ستتم مطالبتك بتعيين اسم للويب الخاص بك وتوفير عنوان URL الهدف - يجب أن يكون الهدف هو اسم المضيف لسجل A الذي قمت بإنشائه سابقًا. لاحظ أن عنوان URL الهدف قد يتطلب تضمين “HTTPS://” في URL.
بمجرد الانتهاء، تحقق من تحديد الحساب الفرعي والأحداث الصحيحة، واضغط على “إنشاء ويب” لحفظ التكوين الخاص بك. سيتم الآن تدفق بيانات الحدث لجميع أنواع الأحداث المختارة إلى عنوان URL الهدف لدينا وسيتم استهلاكها بواسطة ALB للتحليل اللاحق.
