التالي هو دليل بسيط لمساعدة المرسلين على الشعور بالراحة عند إنشاء webhook لأحداث Bird واستهلاك البيانات باستخدام البنية التحتية داخل AWS.
تُعتبر webhooks للأحداث من Bird في الوقت الفعلي أداة قيّمة للغاية للمرسلين للحصول على البيانات تلقائيًا نحو أنظمتهم. يمكن أن يقود هذا إلى أتمتة الأنظمة اللاحقة مثل تحديث قوائم المراسلة، وإطلاق رحلات البريد الإلكتروني الآلية، أو ملء لوحات القيادة الداخلية. بينما يمكن الوصول إلى نفس بيانات الحدث عبر واجهة المستخدم لBird باستخدام بحث الأحداث، أو برمجيًا باستخدام API الأحداث من Bird، فإن القيود المفروضة على عدد السجلات المعادة في طلب واحد أو حدود المعدل المفروضة على النهاية للعناصر يمكن أن تجعل كلتا الطريقتين مقيِّدتين بالنسبة للمرسلين الكبار والمتطورين.
تمكن webhooks للأحداث في الوقت الفعلي المرسل من تكوين نقطة نهاية حيث تقوم Bird بنقل البيانات إليها، ويمكن استهلاك البيانات دون الحاجة إلى جدولة وظائف cron التي تسحب البيانات. هناك أيضًا مقايضات لوجستية عند سحب البيانات مقارنة بالحصول على البيانات المرسلة إليك، مثل الاضطرار إلى تحديد الفترة الزمنية والمعايير التي يجب استخدامها لكل طلب API. إذا لم تتطابق الفترات الزمنية بدقة فقد تخاطر بفقدان البيانات، وإذا تداخلت الفترات الزمنية فستحتاج إلى التعامل مع سجلات البيانات المكررة. باستخدام webhooks في الوقت الفعلي، يتم ببساطة دفع بيانات الحدث إلى نقطة النهاية الخاصة بك حالما تتوفر داخل Bird.
بينما قد يتم فهم فوائد تلقي بيانات الأحداث في الوقت الفعلي لتحريك عمليات أتمتة الأنظمة اللاحقة على الفور من قبل العديد من المرسلين، قد تكون عملية تنفيذ واستهلاك webhooks مثيرة للتحدي. يمكن أن يكون هذا صحيحًا بشكل خاص إذا لم تكن لديك فكرة عن المكونات الفنية لإنشاء نقطة نهاية ومعالجة البيانات برمجيًا. هناك خدمات متاحة ستستهلك بيانات webhook من Bird وETL إلى قاعدة البيانات الخاصة بك تلقائيًا – على سبيل المثال StitchData، الذي تحدثنا عنه في مدونات سابقة. ومع ذلك، إذا كنت ترغب في مزيد من التحكم في العملية يمكنك بسهولة بناء المكونات بنفسك. فيما يلي دليل بسيط لمساعدة المرسلين على الشعور بالراحة عند إنشاء webhook للأحداث من Bird واستهلاك البيانات باستخدام البنية التحتية داخل AWS.
تكوين وجهة نقطة نهاية Webhook
عند إنشاء حدث Bird، نريد أن يتم تدفق بيانات الحدث في الوقت الفعلي إلى نقطة نهاية في AWS حتى نتمكن من استهلاك واستخدام تلك البيانات برمجيًا. سيتم إرسال البيانات من Bird إلى نقطة نهاية مستهدفة، والتي ستعمل على تمرير الحمولة إلى وظيفة لامبدا التي ستعالج وتخزن البيانات في دلو S3. يمكن رؤية مخطط عالي المستوى لتدفق البيانات الموضح أدناه:
لتنفيذ سير العمل هذا، دعنا نبنيها بالفعل بالترتيب العكسي بدءًا من إنشاء دلو S3 حيث سنخزن بيانات الحدث لدينا ومن ثم العمل للخلف – إضافة كل مكون يغذي ما بنينا.
إنشاء دلو S3 لتخزين بيانات ويبهوك
قبل إنشاء موازن التحميل الخاص بنا لقبول البيانات، أو وظيفة لامبدا الخاصة بنا لتخزين البيانات، نحتاج أولاً إلى إنشاء دلو S3 حيث سيتم تخزين البيانات. للقيام بذلك، انتقل إلى خدمة S3 داخل AWS واضغط على “إنشاء دلو”. سيتم مطالبتك بتعيين اسم لدلوك وتعيين المنطقة – تأكد من استخدام نفس المنطقة كما للALB ووظيفة لامبدا. عندما يُنشأ دلك S3، سيكون فارغًا – إذا كنت ترغب في تنظيم البيانات داخل مجلد، يمكنك إما إنشاء الدليل المقصود الآن، أو سيتم إنشاء الدليل عندما تقوم وظيفة لامبدا الخاصة بك بتخزين الملف. في هذا المثال، اسمنا دلو S3 "bird-webhooks" وأنشأنا مجلدًا باسم "B Event Data" لتخزين بيانات الحدث لدينا – سترى هذه الأسماء مرجعة في وظيفة لامبدا الخاصة بنا أدناه.
إنشاء وظيفة لامبدا لاستهلاك البيانات
ستُجرى معالجة وتخزين البيانات فعليًا بواسطة وظيفة لامبدا تُستدعى بواسطة موازن التحميل الخاص بتطبيقنا (ALB).
الخطوة الأولى هي إنشاء وظيفة لامبدا الخاصة بك عن طريق التنقل إلى خدمة لامبدا داخل AWS والنقر على “إنشاء وظيفة”. سيتم مطالبتك بتعيين اسم لوظيفة لامبدا واختيار أي لغة برمجية لكتابة وظيفتك فيها. في هذا المثال، نستخدم بايثون كلغة التنفيذ.
الآن نحتاج إلى تطوير وظيفة لامبدا الخاصة بنا. للحظة، دعونا نفترض أن موازن التحميل الخاص بتطبيقنا قد تم تكوينه ويمرر حمولة الويبهوك إلى وظيفة لامبدا الخاصة بنا – وظيفة لامبدا ستتلقى حمولة تشمل رؤوس كاملة وجسد. يتم تمرير الحمولة إلى وظيفة لامبدا الخاصة بنا باستخدام كائن “الحدث” كقاموس. يمكنك أن تراجع الرؤوس وجسد الحمولة بشكل مستقل من خلال الوصول إلى كائنات “الرؤوس” و“الجسد” داخل الحمولة. في هذا المثال، نحن ببساطة سنقرأ رأس "x-messagesystems-batch-id"، حيث يتم إنشاء معرف الدفع الفريد بواسطة Bird لدفعة الويبهوك، ونستخدمه كاسم الملف عندما نقوم بتخزين الجسد كملف مسطح في S3؛ ومع ذلك، قد ترغب في إضافة وظائف إضافية مثل الفحوصات الأمنية أو معالجة الأخطاء، حسب الحاجة.
عند تخزين الحمولة إلى ملف مسطح في S3، سنحتاج إلى تحديد اسم دلو S3، الموقع، واسم الملف حيث سيتم تخزين بيانات الحمولة. في وظيفة لامبدا النموذجية الخاصة بنا، نفعل ذلك داخل وظيفة "store_batch". في هذا المثال، نحن بصدد تخزين كامل الدفع كملف واحد، مما يساعد على ضمان أن البيانات تُجمع وتُخزن قبل انتهاء الاتصال HTTP بين Bird ونقطة النهاية الخاصة بك. بينما يمكنك تعديل إعدادات مهلة الاتصال على موازن التحميل الخاص بك، لا توجد ضمانات بأن الاتصال لن ينتهي في جانب الإرسال (في هذه الحالة Bird) أو أن الاتصال لن يتم إنهاؤه قبل انتهاء تنفيذ وظيفة لامبدا الخاصة بك. من الممارسات الجيدة أن تحافظ على وظيفة المستهلك فعالة قدر الإمكان واستخدام أنشطة معالجة البيانات للعمليات المحمولة حيثما أمكن – مثل تحويل الحمولة المجموعة بصيغة JSON إلى ملف CSV، أو تحميل بيانات الحدث إلى قاعدة بيانات.
من المهم أن تلاحظ أنه قد تحتاج إلى تحديث الأذونات لوظيفة لامبدا الخاصة بك. سيحتاج دور التنفيذ الخاص بك إلى أذونات PutObject وGetObject لـ S3. من الممارسات الجيدة فرض مبدأ الأقل امتياز، لذا أوصي بتعيين هذه الأذونات فقط لدلو S3 حيث سيتم تخزين دفعات الويبهوك.
يمكنك العثور على نموذج لوظيفة لامبدا الخاصة بنا هنا.
كملاحظة سريعة على معرف الدفع: سيقوم Bird بتجميع الأحداث في حمولة واحدة، حيث قد تحتوي كل دفعة على 1 إلى 350 أو أكثر من سجلات الحدث. ستُمنح الدفعة معرف دفع فريدًا، والذي يمكن استخدامه لعرض حالة الدفع عن طريق الاستفادة من API ويبهوك الأحداث أو داخل حساب 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 الخاص بك يستمع إلى المنفذ الصحيح.
إنشاء ويبهوك Bird
الآن نحن جاهزون لإنشاء ويبهوك في Bird واستخدام اسم المضيف المحدد بواسطة سجل A أعلاه كنقطة النهاية المستهدفة الخاصة بنا. لإنشاء الويبهوك، انتقل إلى قسم ويبهوك داخل حساب Bird الخاص بك واضغط على “إنشاء ويبهوك”. سيطلب منك تعيين اسم لويبهوك الخاص بك وتوفير عنوان URL مستهدف – يجب أن تكون الهدف اسم المضيف لسجل A الذي أنشأته سابقًا. لاحظ أن عنوان URL المستهدف قد يتطلب تضمين “HTTPS://” في URL.
بمجرد الانتهاء، تحقق من اختيار الحساب الفرعي الصحيح والأحداث، واضغط على “إنشاء ويبهوك” لحفظ تكوينك. ستتدفق الآن بيانات الحدث لجميع أنواع الأحداث المختارة إلى عنوان URL المستهدف لدينا وسيتم استهلاكها بواسطة ALB الخاص بنا للمعالجة اللاحقة.
