إنشاء واستهلاك روابط الويب للطيور
طائر
27/01/2022
البريد الإلكتروني
1 min read
النقاط الرئيسية
تتيح لك الويب هوكس من بيرد تلقي بيانات الحدث في الوقت الفعلي بشكل فوري—بدون استعلام، بدون مهام كرون، وبدون صداع حدود المعدل.
ت eliminates الويب هوكس تعقيد إدارة النوافذ الزمنية، مما يمنع تفويت الأحداث والتعامل مع السجلات المكررة.
مثالي للأتمتة في الأسفل: تحديث القوائم، بدء الرحلات، تعزيز لوحات المعلومات، أو مزامنة الأنظمة الداخلية.
توجهك الدليل لبناء خط أنابيب استيعاب كامل على AWS: تخزين S3، معالجة Lambda، وموازن تحميل التطبيق.
يعمل S3 كطبقة التخزين المركزية لحمولات الويب هوكس، مع كتابة كل دفعة كملف JSON مسطح.
تتعامل وظائف Lambda مع كل من الاستيعاب (تخزين الدفعات الخام) والتحويل (تحويل JSON إلى CSV).
تجمع بيرد الأحداث—تتضمن كل دفعة ويب هوك معرف فريد
x-messagesystems-batch-id، مما يسمح بفحوصات العرض وإزالة التكرار.يجب أن تظل Lambda المستهلك فعالة لأن بيرد تعيد المحاولات إذا لم يستجب نقطة النهاية خلال ~10 ثوانٍ.
يوصى باستخدام AWS ALB (مقابل API Gateway) من أجل البساطة، وفعالية التكلفة، والتعامل المباشر مع طلبات HTTP POST.
تم تكوين DNS (Route 53 أو مزود خارجي) لربط اسم مضيف صديق بنقطة النهاية ALB.
بعد الإعداد، تدفع بيرد بيانات الحدث مباشرة وبموثوقية إلى خط أنابيب AWS الخاص بك للمعالجة غير المتزامنة.
يغطي الدليل أيضًا أفضل الممارسات: أذونات IAM الأقل، قيود التخزين المؤقت، تجنب المحفزات التكرارية، وتنظيم سير العمل متعدد Lambda.
أهم النقاط في الأسئلة والأجوبة
ما هو الهدف الرئيسي من Webhooks الأحداث في الوقت الحقيقي لطيور؟
لإرسال بيانات الحدث مباشرة إلى نقطة نهاية المرسل في الوقت الفعلي، مما يتيح الأتمتة الفورية دون الحاجة إلى الاستعلام أو استدعاءات API المحدودة المعدل.
لماذا تعتبر الويب هوكس أفضل من سحب البيانات عبر API للمرسلين الكبار؟
نظرًا لأن استدعاءات واجهة برمجة التطبيقات تحتاج إلى إدارة نافذة زمنية، مما قد يؤدي إلى فجوات في البيانات أو تكرارها، وقد تضرب حدود المعدل - فإن الويب هوك يتخلص من كل ذلك من خلال دفع البيانات بشكل مستمر.
ما هي خدمات AWS المستخدمة في أنبوب إدخال الويب الموصى به؟
أمازون S3 (التخزين)، AWS Lambda (المعالجة)، مُوازن تحميل التطبيقات (مستمع HTTP)، وخيارياً Route 53 (DNS).
كيف تعالج شركة Bird بيانات أحداث الدفعة؟
ترسل Bird عدة أحداث معًا في حمولة، كل منها مخصص له معرف دفعة فريد (x-messagesystems-batch-id) للتتبع، وإعادة المحاولات، وإزالة التكرار.
ما الذي يحفز دالة لامبدا المستهلك؟
تحول ALB طلبات POST الواردة من الويب هوك مباشرة إلى Lambda، التي تستخرج الحمولة وتكتبها إلى S3.
لماذا يجب تخزين دفعة webhook الخام في S3 قبل معالجتها؟
لضمان سرعة الاستيعاب (<10 ثواني) حتى لا يتوقف الاتصال، ولإخراج المعالجة الأثقل إلى خط أنابيب غير متزامن منفصل.
ماذا تفعل دالة Lambda الثانية؟
يتم تفعيله بواسطة كائنات S3 جديدة، يتحقق من صحة JSON، يحولها إلى CSV، ويكتب الناتج المعالج إلى دلو S3 منفصل.
لماذا نستخدم دلو S3 منفصل لملفات CSV المعالجة؟
لتجنب المشغلات المتكررة (كتابة ملف جديد تمت معالجته مرة أخرى إلى نفس السطل سيؤدي إلى إعادة تشغيل لامبدا بلا نهاية).
ما الأذونات التي تتطلبها وظائف Lambda؟
يحتاج Lambda المستهلك إلى أذونات PutObject في S3؛ يحتاج Lambda المعالجة إلى GetObject لسلة المصدر و PutObject للسلة الوجهة.
لماذا يُوصى باستخدام AWS ALB بدلاً من API Gateway؟
تكون ALBs أرخص وأبسط، ومثالية لتوجيه HTTPS POST المباشر؛ قد يقوم API Gateway بتغيير تنسيق الحمولة وزيادة التعقيد.
كيف يقوم المرسلون بتكوين الويب هوك في بيرد؟
من خلال توفير نقطة نهاية HTTPS (سجل DNS لـ ALB)، واختيار حساب فرعي، واختيار الأحداث، وحفظ إعدادات webhook.
ما هي الخيارات المتاحة لتخزين البيانات المعالجة أو تحليلها؟
تحميل إلى قواعد البيانات (PostgreSQL، DynamoDB، RDS)، إدخال إلى أنظمة ETL، أو استعلام مباشرة باستخدام أدوات مثل Athena.
تعتبر Webhooks الأحداث في الوقت الفعلي من Bird أداة قيمة للغاية للمرسلين للحصول على البيانات المدفوعة تلقائيًا إلى أنظمتهم. يمكن أن تحفز هذه العملية الأتمتة اللاحقة مثل تحديث قوائم البريد الإلكتروني، أو تفعيل رحلات البريد الإلكتروني التلقائية، أو ملء لوحات المعلومات الداخلية. بينما يمكن الوصول إلى نفس بيانات الأحداث عبر واجهة مستخدم Bird باستخدام بحث الأحداث، أو برمجيًا من خلال الاستفادة من واجهة برمجة التطبيقات للأحداث، فإن القيود المفروضة على عدد السجلات التي يتم إرجاعها في طلب واحد أو القيود المفروضة على نقطة نهاية واجهة برمجة التطبيقات يمكن أن تجعل كلا الطريقتين مقيدتين للمرسلين الكبار والمتطورين.
تمكن Webhooks الأحداث في الوقت الفعلي المرسل من تكوين نقطة نهاية يرسل إليها Bird البيانات، ويمكن استهلاك البيانات دون الحاجة إلى جدولة مهام cron التي تسحب البيانات. هناك أيضًا تكاليف لوجستية عند سحب البيانات مقارنة بالحصول على البيانات المدفوعة إليك، مثل الحاجة لتحديد الفترة الزمنية والمعايير التي يجب استخدامها لكل طلب واجهة برمجة التطبيقات. إذا لم تتماشى الفترات الزمنية بشكل مثالي، فإنك تخاطر بفقدان البيانات، وإذا تداخلت الفترات الزمنية، فستحتاج إلى التعامل مع السجلات المكررة للبيانات. مع Webhooks في الوقت الفعلي، يتم ببساطة دفع بيانات الأحداث إلى نقطة النهاية الخاصة بك حالما تصبح متاحة داخل Bird.
بينما قد تكون فوائد تلقي بيانات الأحداث في الوقت الفعلي لتحفيز عمليات الأتمتة التالية مفهومة على الفور من قبل العديد من المرسلين، فإن العملية الفعلية لتنفيذ واستهلاك Webhooks قد تكون مخيفة. قد يكون هذا صحيحًا بشكل خاص إذا كنت غير مألوف بالمكونات التقنية لإنشاء نقطة نهاية والتعامل مع البيانات برمجيًا. هناك خدمات متاحة ستستهلك بيانات Webhook مختلفة من Bird وتخرجها إلى قاعدة البيانات الخاصة بك تلقائيًا - مثال على ذلك هو StitchData، الذي كتبنا عنه في الماضي. ومع ذلك، إذا كنت ترغب في مزيد من التحكم في العملية، يمكنك بسهولة بناء المكونات بنفسك. فيما يلي دليل بسيط لمساعدة المرسلين على الشعور بالراحة عند إنشاء Webhook أحداث من Bird واستهلاك البيانات باستخدام البنية التحتية داخل AWS.
تعتبر Webhooks الأحداث في الوقت الفعلي من Bird أداة قيمة للغاية للمرسلين للحصول على البيانات المدفوعة تلقائيًا إلى أنظمتهم. يمكن أن تحفز هذه العملية الأتمتة اللاحقة مثل تحديث قوائم البريد الإلكتروني، أو تفعيل رحلات البريد الإلكتروني التلقائية، أو ملء لوحات المعلومات الداخلية. بينما يمكن الوصول إلى نفس بيانات الأحداث عبر واجهة مستخدم Bird باستخدام بحث الأحداث، أو برمجيًا من خلال الاستفادة من واجهة برمجة التطبيقات للأحداث، فإن القيود المفروضة على عدد السجلات التي يتم إرجاعها في طلب واحد أو القيود المفروضة على نقطة نهاية واجهة برمجة التطبيقات يمكن أن تجعل كلا الطريقتين مقيدتين للمرسلين الكبار والمتطورين.
تمكن Webhooks الأحداث في الوقت الفعلي المرسل من تكوين نقطة نهاية يرسل إليها Bird البيانات، ويمكن استهلاك البيانات دون الحاجة إلى جدولة مهام cron التي تسحب البيانات. هناك أيضًا تكاليف لوجستية عند سحب البيانات مقارنة بالحصول على البيانات المدفوعة إليك، مثل الحاجة لتحديد الفترة الزمنية والمعايير التي يجب استخدامها لكل طلب واجهة برمجة التطبيقات. إذا لم تتماشى الفترات الزمنية بشكل مثالي، فإنك تخاطر بفقدان البيانات، وإذا تداخلت الفترات الزمنية، فستحتاج إلى التعامل مع السجلات المكررة للبيانات. مع Webhooks في الوقت الفعلي، يتم ببساطة دفع بيانات الأحداث إلى نقطة النهاية الخاصة بك حالما تصبح متاحة داخل Bird.
بينما قد تكون فوائد تلقي بيانات الأحداث في الوقت الفعلي لتحفيز عمليات الأتمتة التالية مفهومة على الفور من قبل العديد من المرسلين، فإن العملية الفعلية لتنفيذ واستهلاك Webhooks قد تكون مخيفة. قد يكون هذا صحيحًا بشكل خاص إذا كنت غير مألوف بالمكونات التقنية لإنشاء نقطة نهاية والتعامل مع البيانات برمجيًا. هناك خدمات متاحة ستستهلك بيانات Webhook مختلفة من Bird وتخرجها إلى قاعدة البيانات الخاصة بك تلقائيًا - مثال على ذلك هو StitchData، الذي كتبنا عنه في الماضي. ومع ذلك، إذا كنت ترغب في مزيد من التحكم في العملية، يمكنك بسهولة بناء المكونات بنفسك. فيما يلي دليل بسيط لمساعدة المرسلين على الشعور بالراحة عند إنشاء Webhook أحداث من Bird واستهلاك البيانات باستخدام البنية التحتية داخل AWS.
تعتبر Webhooks الأحداث في الوقت الفعلي من Bird أداة قيمة للغاية للمرسلين للحصول على البيانات المدفوعة تلقائيًا إلى أنظمتهم. يمكن أن تحفز هذه العملية الأتمتة اللاحقة مثل تحديث قوائم البريد الإلكتروني، أو تفعيل رحلات البريد الإلكتروني التلقائية، أو ملء لوحات المعلومات الداخلية. بينما يمكن الوصول إلى نفس بيانات الأحداث عبر واجهة مستخدم Bird باستخدام بحث الأحداث، أو برمجيًا من خلال الاستفادة من واجهة برمجة التطبيقات للأحداث، فإن القيود المفروضة على عدد السجلات التي يتم إرجاعها في طلب واحد أو القيود المفروضة على نقطة نهاية واجهة برمجة التطبيقات يمكن أن تجعل كلا الطريقتين مقيدتين للمرسلين الكبار والمتطورين.
تمكن Webhooks الأحداث في الوقت الفعلي المرسل من تكوين نقطة نهاية يرسل إليها Bird البيانات، ويمكن استهلاك البيانات دون الحاجة إلى جدولة مهام cron التي تسحب البيانات. هناك أيضًا تكاليف لوجستية عند سحب البيانات مقارنة بالحصول على البيانات المدفوعة إليك، مثل الحاجة لتحديد الفترة الزمنية والمعايير التي يجب استخدامها لكل طلب واجهة برمجة التطبيقات. إذا لم تتماشى الفترات الزمنية بشكل مثالي، فإنك تخاطر بفقدان البيانات، وإذا تداخلت الفترات الزمنية، فستحتاج إلى التعامل مع السجلات المكررة للبيانات. مع Webhooks في الوقت الفعلي، يتم ببساطة دفع بيانات الأحداث إلى نقطة النهاية الخاصة بك حالما تصبح متاحة داخل Bird.
بينما قد تكون فوائد تلقي بيانات الأحداث في الوقت الفعلي لتحفيز عمليات الأتمتة التالية مفهومة على الفور من قبل العديد من المرسلين، فإن العملية الفعلية لتنفيذ واستهلاك Webhooks قد تكون مخيفة. قد يكون هذا صحيحًا بشكل خاص إذا كنت غير مألوف بالمكونات التقنية لإنشاء نقطة نهاية والتعامل مع البيانات برمجيًا. هناك خدمات متاحة ستستهلك بيانات Webhook مختلفة من Bird وتخرجها إلى قاعدة البيانات الخاصة بك تلقائيًا - مثال على ذلك هو StitchData، الذي كتبنا عنه في الماضي. ومع ذلك، إذا كنت ترغب في مزيد من التحكم في العملية، يمكنك بسهولة بناء المكونات بنفسك. فيما يلي دليل بسيط لمساعدة المرسلين على الشعور بالراحة عند إنشاء Webhook أحداث من Bird واستهلاك البيانات باستخدام البنية التحتية داخل AWS.
تكوين نقطة نهاية هدف الويب
عند إنشاء حدث من Bird، نريد أن يتم بث بيانات ذلك الحدث في الوقت الحقيقي إلى نقطة نهاية في AWS حتى نتمكن من استهلاك واستخدام تلك البيانات برمجيًا. سيتم إرسال البيانات من Bird إلى نقطة نهاية مستهدفة، والتي ستقوم بإعادة توجيه الحمولة إلى دالة lambda التي ستقوم بمعالجة وتخزين البيانات في دلو S3. يمكن رؤية مخطط توضيحي عالي المستوى لتدفق البيانات الموصوف أدناه:
المكون | المسؤولية |
|---|---|
Webhooks من Bird | إصدار دفعات أحداث في الوقت الحقيقي كطلبات POST عبر HTTP |
موازن تحميل التطبيقات | استقبال حركة مرور الويب الخارجية وتوجيه الطلبات |
Lambda (المستهلك) | الاحتفاظ بدفعات الويب الخام إلى S3 بكفاءة |
Amazon S3 | تخزين حمولات الأحداث المجتمعة كملفات JSON مسطحة |
Lambda (المعالج) | تحويل أو تحميل البيانات المخزنة بشكل غير متزامن |
لتنفيذ هذا العمل، دعنا نبنيها فعليًا بالترتيب العكسي بدءًا من إنشاء دلو S3 حيث سنقوم بتخزين بيانات الأحداث الخاصة بنا ثم نعمل عائدين - بإضافة كل مكون يغذي ما أنشأناه.
عند إنشاء حدث من Bird، نريد أن يتم بث بيانات ذلك الحدث في الوقت الحقيقي إلى نقطة نهاية في AWS حتى نتمكن من استهلاك واستخدام تلك البيانات برمجيًا. سيتم إرسال البيانات من Bird إلى نقطة نهاية مستهدفة، والتي ستقوم بإعادة توجيه الحمولة إلى دالة lambda التي ستقوم بمعالجة وتخزين البيانات في دلو S3. يمكن رؤية مخطط توضيحي عالي المستوى لتدفق البيانات الموصوف أدناه:
المكون | المسؤولية |
|---|---|
Webhooks من Bird | إصدار دفعات أحداث في الوقت الحقيقي كطلبات POST عبر HTTP |
موازن تحميل التطبيقات | استقبال حركة مرور الويب الخارجية وتوجيه الطلبات |
Lambda (المستهلك) | الاحتفاظ بدفعات الويب الخام إلى S3 بكفاءة |
Amazon S3 | تخزين حمولات الأحداث المجتمعة كملفات JSON مسطحة |
Lambda (المعالج) | تحويل أو تحميل البيانات المخزنة بشكل غير متزامن |
لتنفيذ هذا العمل، دعنا نبنيها فعليًا بالترتيب العكسي بدءًا من إنشاء دلو S3 حيث سنقوم بتخزين بيانات الأحداث الخاصة بنا ثم نعمل عائدين - بإضافة كل مكون يغذي ما أنشأناه.
عند إنشاء حدث من Bird، نريد أن يتم بث بيانات ذلك الحدث في الوقت الحقيقي إلى نقطة نهاية في AWS حتى نتمكن من استهلاك واستخدام تلك البيانات برمجيًا. سيتم إرسال البيانات من Bird إلى نقطة نهاية مستهدفة، والتي ستقوم بإعادة توجيه الحمولة إلى دالة lambda التي ستقوم بمعالجة وتخزين البيانات في دلو S3. يمكن رؤية مخطط توضيحي عالي المستوى لتدفق البيانات الموصوف أدناه:
المكون | المسؤولية |
|---|---|
Webhooks من Bird | إصدار دفعات أحداث في الوقت الحقيقي كطلبات POST عبر HTTP |
موازن تحميل التطبيقات | استقبال حركة مرور الويب الخارجية وتوجيه الطلبات |
Lambda (المستهلك) | الاحتفاظ بدفعات الويب الخام إلى S3 بكفاءة |
Amazon S3 | تخزين حمولات الأحداث المجتمعة كملفات JSON مسطحة |
Lambda (المعالج) | تحويل أو تحميل البيانات المخزنة بشكل غير متزامن |
لتنفيذ هذا العمل، دعنا نبنيها فعليًا بالترتيب العكسي بدءًا من إنشاء دلو S3 حيث سنقوم بتخزين بيانات الأحداث الخاصة بنا ثم نعمل عائدين - بإضافة كل مكون يغذي ما أنشأناه.
إنشاء دلو S3 لتخزين بيانات الويب هوك
قبل إنشاء مُوازن التحميل لدينا لقبول البيانات، أو دالة اللambda لدينا لتخزين البيانات، نحتاج أولاً إلى إنشاء دلو S3 حيث ستُخزن البيانات. بينما يوفر S3 تخزينًا ممتازًا لبيانات webhook، يجب على المؤسسات التي تستخدم أيضًا قواعد بيانات PostgreSQL لمعالجة الأحداث تنفيذ إجراءات النسخ الاحتياطي والاستعادة المناسبة لحماية بياناتها المهيكلة بجانب استراتيجية تخزين S3 الخاصة بها. للقيام بذلك، انتقل إلى خدمة S3 ضمن AWS واضغط على "إنشاء دلو". ستُطلب منك تعيين اسم لدلوك وتحديد المنطقة – تأكد من استخدام نفس المنطقة مثل ALB ودالة lambda الخاصة بك. عندما يتم إنشاء دلو S3 الخاص بك، سيكون فارغًا – إذا كنت ترغب في تنظيم البيانات داخل مجلد، يمكنك إما إنشاء الدليل المقصود الآن، أو سيتم إنشاء الدليل عندما تخزن دالة lambda الخاصة بك الملف. في هذا المثال، قمنا بتسمية دلو S3 الخاص بنا بـ “bird-webhooks” وأنشأنا مجلدًا باسم “ب بيانات الأحداث” لتخزين بيانات الأحداث لدينا – سترى هذه الأسماء المذكورة في دالة lambda الخاصة بنا أدناه.
قبل إنشاء مُوازن التحميل لدينا لقبول البيانات، أو دالة اللambda لدينا لتخزين البيانات، نحتاج أولاً إلى إنشاء دلو S3 حيث ستُخزن البيانات. بينما يوفر S3 تخزينًا ممتازًا لبيانات webhook، يجب على المؤسسات التي تستخدم أيضًا قواعد بيانات PostgreSQL لمعالجة الأحداث تنفيذ إجراءات النسخ الاحتياطي والاستعادة المناسبة لحماية بياناتها المهيكلة بجانب استراتيجية تخزين S3 الخاصة بها. للقيام بذلك، انتقل إلى خدمة S3 ضمن AWS واضغط على "إنشاء دلو". ستُطلب منك تعيين اسم لدلوك وتحديد المنطقة – تأكد من استخدام نفس المنطقة مثل ALB ودالة lambda الخاصة بك. عندما يتم إنشاء دلو S3 الخاص بك، سيكون فارغًا – إذا كنت ترغب في تنظيم البيانات داخل مجلد، يمكنك إما إنشاء الدليل المقصود الآن، أو سيتم إنشاء الدليل عندما تخزن دالة lambda الخاصة بك الملف. في هذا المثال، قمنا بتسمية دلو S3 الخاص بنا بـ “bird-webhooks” وأنشأنا مجلدًا باسم “ب بيانات الأحداث” لتخزين بيانات الأحداث لدينا – سترى هذه الأسماء المذكورة في دالة lambda الخاصة بنا أدناه.
قبل إنشاء مُوازن التحميل لدينا لقبول البيانات، أو دالة اللambda لدينا لتخزين البيانات، نحتاج أولاً إلى إنشاء دلو S3 حيث ستُخزن البيانات. بينما يوفر S3 تخزينًا ممتازًا لبيانات webhook، يجب على المؤسسات التي تستخدم أيضًا قواعد بيانات PostgreSQL لمعالجة الأحداث تنفيذ إجراءات النسخ الاحتياطي والاستعادة المناسبة لحماية بياناتها المهيكلة بجانب استراتيجية تخزين S3 الخاصة بها. للقيام بذلك، انتقل إلى خدمة S3 ضمن AWS واضغط على "إنشاء دلو". ستُطلب منك تعيين اسم لدلوك وتحديد المنطقة – تأكد من استخدام نفس المنطقة مثل ALB ودالة lambda الخاصة بك. عندما يتم إنشاء دلو S3 الخاص بك، سيكون فارغًا – إذا كنت ترغب في تنظيم البيانات داخل مجلد، يمكنك إما إنشاء الدليل المقصود الآن، أو سيتم إنشاء الدليل عندما تخزن دالة lambda الخاصة بك الملف. في هذا المثال، قمنا بتسمية دلو S3 الخاص بنا بـ “bird-webhooks” وأنشأنا مجلدًا باسم “ب بيانات الأحداث” لتخزين بيانات الأحداث لدينا – سترى هذه الأسماء المذكورة في دالة lambda الخاصة بنا أدناه.
إنشاء دالة لامبدا لاستهلاك البيانات
سيتم إجراء المعالجة الفعلية وتخزين البيانات بواسطة وظيفة لامبدا يتم استدعاؤها بواسطة موازن التحميل الخاص بالتطبيق لدينا (ALB).
الخطوة الأولى هي إنشاء وظيفة لامبدا الخاصة بك عن طريق التنقل إلى خدمة لامبدا داخل AWS والنقر على "إنشاء وظيفة". سيتم مطالبتك بتعيين اسم لوظيفة لامبدا الخاصة بك واختيار لغة البرمجة التي تريد كتابة وظيفتك بها. في هذا المثال، نستخدم Python كلغة تشغيل.
الآن نحتاج إلى تطوير وظيفة لامبدا الخاصة بنا. لحظة، دعنا نفترض أن موازن التحميل الخاص بالتطبيق لدينا قد تم تكوينه وأنه يقوم بإعادة توجيه حمولة الويب إلى وظيفة لامبدا الخاصة بنا - ستتلقى وظيفة لامبدا حمولة تتضمن جميع الرؤوس والجسم. يتم تمرير الحمولة إلى وظيفة لامبدا الخاصة بنا باستخدام الكائن "event" كقاموس. يمكنك الرجوع إلى الرؤوس وجسم الحمولة بشكل مستقل عن طريق الوصول إلى كائنات "headers" و "body" داخل الحمولة. في هذا المثال، سنقوم ببساطة بقراءة رأس "x-messagesystems-batch-id"، حيث أن معرف الدفعة هو قيمة فريدة تم إنشاؤها بواسطة Bird لدفعة الويب، وسنستخدمها كاسم ملف عند تخزين الجسم كملف ثابت في S3؛ ومع ذلك، قد ترغب في إضافة وظائف إضافية مثل فحوصات المصادقة أو معالجة الأخطاء، حسب الحاجة.
عند تخزين الحمولة كملف ثابت في S3، سنحتاج إلى تحديد اسم دلو S3، والموقع، واسم الملف الذي سيتم تخزين بيانات الحمولة فيه. في وظيفة لامبدا النموذجية لدينا، نقوم بذلك ضمن وظيفة "store_batch". في هذا المثال، سنقوم بتخزين الدفعة بالكامل كملف واحد، مما يساعد على التأكد من جمع البيانات وتخزينها قبل انتهاء مدة الاتصال بين Bird ونقطة النهاية الخاصة بك. في حين أنه يمكنك تعديل إعدادات مهلة الاتصال على موازن التحميل الخاص بك، فلا توجد ضمانات بأن الاتصال لن ينتهي عند جانب النقل (في هذه الحالة Bird) أو أن الاتصال لن يتم إنهاؤه قبل أن تنتهي وظيفة لامبدا الخاصة بك من التنفيذ. من الممارسات الجيدة الحفاظ على وظيفة المستهلك الخاصة بك فعالة قدر الإمكان واحتياج أنشطة معالجة البيانات لعمليات ما بعد المعالجة حيثما كان ذلك ممكنًا – مثل تحويل الحمولة بتنسيق JSON المُجمع إلى ملف CSV، أو تحميل بيانات الحدث إلى قاعدة بيانات.
من المهم ملاحظة أنه قد تحتاج إلى تحديث الأذونات لوظيفة لامبدا الخاصة بك. ستحتاج دور التنفيذ الخاص بك إلى أذونات PutObject و GetObject لـ S3. من الممارسات الجيدة فرض مبدأ الحد الأدنى من الامتيازات، لذلك أوصي بتعيين هذه الأذونات فقط لدلو S3 حيث سيتم تخزين حمولات الويب.
يمكن العثور على عينة من وظيفة لامبدا الخاصة بالمستهلك لدينا هنا.
بملاحظة سريعة عن معرف الدفعة: ستقوم Bird بتجميع الأحداث في حمولة واحدة، حيث قد يحتوي كل دفعة على 1 إلى 350 سجل حدث أو أكثر. سيتم منح الدفعة معرف دفعة فريدة، يمكن استخدامها لعرض حالة الدفعة من خلال الاستفادة من API الويب للأحداث أو داخل حسابك لدى Bird من خلال النقر على تيار الويب واختيار "حالة الدفعة". في حالة عدم القدرة على تسليم حمولة الويب، مثل أثناء انتهاء مهلة الاتصال، ستقوم Bird تلقائيًا بتكرار المحاولة للدفعة باستخدام نفس معرف الدفعة. يمكن أن يحدث هذا عندما تعمل وظيفة لامبدا الخاصة بك بالقرب من الحد الأقصى لوقت الرحلة لمدة 10 ثوان، وهو سبب لزيادة تحسين وظيفة المستهلك لتقليل زمن التنفيذ.
للتعامل مع جميع أنشطة معالجة البيانات، أوصي بإنشاء وظيفة لامبدا منفصلة تُنفذ كلما تم إنشاء ملف جديد على دلو S3 – بهذه الطريقة، يتم تنفيذ معالجة البيانات بشكل غير متزامن مع نقل البيانات، ولا يوجد خطر لفقدان البيانات بسبب اتصال تم إنهاؤه. سأناقش وظيفة لامبدا المعالجة في قسم لاحق.
سيتم إجراء المعالجة الفعلية وتخزين البيانات بواسطة وظيفة لامبدا يتم استدعاؤها بواسطة موازن التحميل الخاص بالتطبيق لدينا (ALB).
الخطوة الأولى هي إنشاء وظيفة لامبدا الخاصة بك عن طريق التنقل إلى خدمة لامبدا داخل AWS والنقر على "إنشاء وظيفة". سيتم مطالبتك بتعيين اسم لوظيفة لامبدا الخاصة بك واختيار لغة البرمجة التي تريد كتابة وظيفتك بها. في هذا المثال، نستخدم Python كلغة تشغيل.
الآن نحتاج إلى تطوير وظيفة لامبدا الخاصة بنا. لحظة، دعنا نفترض أن موازن التحميل الخاص بالتطبيق لدينا قد تم تكوينه وأنه يقوم بإعادة توجيه حمولة الويب إلى وظيفة لامبدا الخاصة بنا - ستتلقى وظيفة لامبدا حمولة تتضمن جميع الرؤوس والجسم. يتم تمرير الحمولة إلى وظيفة لامبدا الخاصة بنا باستخدام الكائن "event" كقاموس. يمكنك الرجوع إلى الرؤوس وجسم الحمولة بشكل مستقل عن طريق الوصول إلى كائنات "headers" و "body" داخل الحمولة. في هذا المثال، سنقوم ببساطة بقراءة رأس "x-messagesystems-batch-id"، حيث أن معرف الدفعة هو قيمة فريدة تم إنشاؤها بواسطة Bird لدفعة الويب، وسنستخدمها كاسم ملف عند تخزين الجسم كملف ثابت في S3؛ ومع ذلك، قد ترغب في إضافة وظائف إضافية مثل فحوصات المصادقة أو معالجة الأخطاء، حسب الحاجة.
عند تخزين الحمولة كملف ثابت في S3، سنحتاج إلى تحديد اسم دلو S3، والموقع، واسم الملف الذي سيتم تخزين بيانات الحمولة فيه. في وظيفة لامبدا النموذجية لدينا، نقوم بذلك ضمن وظيفة "store_batch". في هذا المثال، سنقوم بتخزين الدفعة بالكامل كملف واحد، مما يساعد على التأكد من جمع البيانات وتخزينها قبل انتهاء مدة الاتصال بين Bird ونقطة النهاية الخاصة بك. في حين أنه يمكنك تعديل إعدادات مهلة الاتصال على موازن التحميل الخاص بك، فلا توجد ضمانات بأن الاتصال لن ينتهي عند جانب النقل (في هذه الحالة Bird) أو أن الاتصال لن يتم إنهاؤه قبل أن تنتهي وظيفة لامبدا الخاصة بك من التنفيذ. من الممارسات الجيدة الحفاظ على وظيفة المستهلك الخاصة بك فعالة قدر الإمكان واحتياج أنشطة معالجة البيانات لعمليات ما بعد المعالجة حيثما كان ذلك ممكنًا – مثل تحويل الحمولة بتنسيق JSON المُجمع إلى ملف CSV، أو تحميل بيانات الحدث إلى قاعدة بيانات.
من المهم ملاحظة أنه قد تحتاج إلى تحديث الأذونات لوظيفة لامبدا الخاصة بك. ستحتاج دور التنفيذ الخاص بك إلى أذونات PutObject و GetObject لـ S3. من الممارسات الجيدة فرض مبدأ الحد الأدنى من الامتيازات، لذلك أوصي بتعيين هذه الأذونات فقط لدلو S3 حيث سيتم تخزين حمولات الويب.
يمكن العثور على عينة من وظيفة لامبدا الخاصة بالمستهلك لدينا هنا.
بملاحظة سريعة عن معرف الدفعة: ستقوم Bird بتجميع الأحداث في حمولة واحدة، حيث قد يحتوي كل دفعة على 1 إلى 350 سجل حدث أو أكثر. سيتم منح الدفعة معرف دفعة فريدة، يمكن استخدامها لعرض حالة الدفعة من خلال الاستفادة من API الويب للأحداث أو داخل حسابك لدى Bird من خلال النقر على تيار الويب واختيار "حالة الدفعة". في حالة عدم القدرة على تسليم حمولة الويب، مثل أثناء انتهاء مهلة الاتصال، ستقوم Bird تلقائيًا بتكرار المحاولة للدفعة باستخدام نفس معرف الدفعة. يمكن أن يحدث هذا عندما تعمل وظيفة لامبدا الخاصة بك بالقرب من الحد الأقصى لوقت الرحلة لمدة 10 ثوان، وهو سبب لزيادة تحسين وظيفة المستهلك لتقليل زمن التنفيذ.
للتعامل مع جميع أنشطة معالجة البيانات، أوصي بإنشاء وظيفة لامبدا منفصلة تُنفذ كلما تم إنشاء ملف جديد على دلو S3 – بهذه الطريقة، يتم تنفيذ معالجة البيانات بشكل غير متزامن مع نقل البيانات، ولا يوجد خطر لفقدان البيانات بسبب اتصال تم إنهاؤه. سأناقش وظيفة لامبدا المعالجة في قسم لاحق.
سيتم إجراء المعالجة الفعلية وتخزين البيانات بواسطة وظيفة لامبدا يتم استدعاؤها بواسطة موازن التحميل الخاص بالتطبيق لدينا (ALB).
الخطوة الأولى هي إنشاء وظيفة لامبدا الخاصة بك عن طريق التنقل إلى خدمة لامبدا داخل AWS والنقر على "إنشاء وظيفة". سيتم مطالبتك بتعيين اسم لوظيفة لامبدا الخاصة بك واختيار لغة البرمجة التي تريد كتابة وظيفتك بها. في هذا المثال، نستخدم Python كلغة تشغيل.
الآن نحتاج إلى تطوير وظيفة لامبدا الخاصة بنا. لحظة، دعنا نفترض أن موازن التحميل الخاص بالتطبيق لدينا قد تم تكوينه وأنه يقوم بإعادة توجيه حمولة الويب إلى وظيفة لامبدا الخاصة بنا - ستتلقى وظيفة لامبدا حمولة تتضمن جميع الرؤوس والجسم. يتم تمرير الحمولة إلى وظيفة لامبدا الخاصة بنا باستخدام الكائن "event" كقاموس. يمكنك الرجوع إلى الرؤوس وجسم الحمولة بشكل مستقل عن طريق الوصول إلى كائنات "headers" و "body" داخل الحمولة. في هذا المثال، سنقوم ببساطة بقراءة رأس "x-messagesystems-batch-id"، حيث أن معرف الدفعة هو قيمة فريدة تم إنشاؤها بواسطة Bird لدفعة الويب، وسنستخدمها كاسم ملف عند تخزين الجسم كملف ثابت في S3؛ ومع ذلك، قد ترغب في إضافة وظائف إضافية مثل فحوصات المصادقة أو معالجة الأخطاء، حسب الحاجة.
عند تخزين الحمولة كملف ثابت في S3، سنحتاج إلى تحديد اسم دلو S3، والموقع، واسم الملف الذي سيتم تخزين بيانات الحمولة فيه. في وظيفة لامبدا النموذجية لدينا، نقوم بذلك ضمن وظيفة "store_batch". في هذا المثال، سنقوم بتخزين الدفعة بالكامل كملف واحد، مما يساعد على التأكد من جمع البيانات وتخزينها قبل انتهاء مدة الاتصال بين Bird ونقطة النهاية الخاصة بك. في حين أنه يمكنك تعديل إعدادات مهلة الاتصال على موازن التحميل الخاص بك، فلا توجد ضمانات بأن الاتصال لن ينتهي عند جانب النقل (في هذه الحالة Bird) أو أن الاتصال لن يتم إنهاؤه قبل أن تنتهي وظيفة لامبدا الخاصة بك من التنفيذ. من الممارسات الجيدة الحفاظ على وظيفة المستهلك الخاصة بك فعالة قدر الإمكان واحتياج أنشطة معالجة البيانات لعمليات ما بعد المعالجة حيثما كان ذلك ممكنًا – مثل تحويل الحمولة بتنسيق JSON المُجمع إلى ملف CSV، أو تحميل بيانات الحدث إلى قاعدة بيانات.
من المهم ملاحظة أنه قد تحتاج إلى تحديث الأذونات لوظيفة لامبدا الخاصة بك. ستحتاج دور التنفيذ الخاص بك إلى أذونات PutObject و GetObject لـ S3. من الممارسات الجيدة فرض مبدأ الحد الأدنى من الامتيازات، لذلك أوصي بتعيين هذه الأذونات فقط لدلو S3 حيث سيتم تخزين حمولات الويب.
يمكن العثور على عينة من وظيفة لامبدا الخاصة بالمستهلك لدينا هنا.
بملاحظة سريعة عن معرف الدفعة: ستقوم Bird بتجميع الأحداث في حمولة واحدة، حيث قد يحتوي كل دفعة على 1 إلى 350 سجل حدث أو أكثر. سيتم منح الدفعة معرف دفعة فريدة، يمكن استخدامها لعرض حالة الدفعة من خلال الاستفادة من API الويب للأحداث أو داخل حسابك لدى Bird من خلال النقر على تيار الويب واختيار "حالة الدفعة". في حالة عدم القدرة على تسليم حمولة الويب، مثل أثناء انتهاء مهلة الاتصال، ستقوم Bird تلقائيًا بتكرار المحاولة للدفعة باستخدام نفس معرف الدفعة. يمكن أن يحدث هذا عندما تعمل وظيفة لامبدا الخاصة بك بالقرب من الحد الأقصى لوقت الرحلة لمدة 10 ثوان، وهو سبب لزيادة تحسين وظيفة المستهلك لتقليل زمن التنفيذ.
للتعامل مع جميع أنشطة معالجة البيانات، أوصي بإنشاء وظيفة لامبدا منفصلة تُنفذ كلما تم إنشاء ملف جديد على دلو S3 – بهذه الطريقة، يتم تنفيذ معالجة البيانات بشكل غير متزامن مع نقل البيانات، ولا يوجد خطر لفقدان البيانات بسبب اتصال تم إنهاؤه. سأناقش وظيفة لامبدا المعالجة في قسم لاحق.
إنشاء موازن تحميل تطبيقات
لكي نتلقى حزمة بيانات webhook، نحتاج إلى توفير نقطة نهاية لإرسال الحزم إليها. نقوم بذلك عن طريق إنشاء موازن تحميل تطبيق داخل AWS من خلال الانتقال إلى EC2 > موازين التحميل والنقر على "إنشاء موازن تحميل". سيتم مطالبتك باختيار نوع موازن التحميل الذي تريد إنشاؤه - بالنسبة لهذا، نريد إنشاء موازن تحميل تطبيق. نحتاج إلى استخدام موازن تحميل تطبيق (ALB) لبناء مستهلكنا لأن أحداث webhooks سيتم إرسالها كطلب HTTP، وتستخدم ALBs لتوجيه طلبات HTTP داخل AWS. يمكننا تنفيذ بوابة HTTP كبديل؛ ومع ذلك، نستخدم ALB لهذا المشروع لأنه أخف وزنًا وأكثر فعالية من حيث التكلفة من بوابة HTTP. من المهم أن نلاحظ أنه إذا اخترت استخدام بوابة HTTP، قد يختلف تنسيق الحدث عن ALB، وبالتالي سيتعين على وظيفة lambda الخاصة بك التعامل مع كائن الطلب وفقًا لذلك.
بمجرد إنشاء ALB الخاص بك، سيتم مطالبتك بتعيين اسم لـ ALB الخاص بك وتكوين الإعدادات الخاصة بالمخطط والأمان/الوصول - نظرًا لأننا نخطط لتلقي بيانات الأحداث من مصدر خارجي (Bird)، سنريد أن يكون ALB الخاص بنا متاحًا على الإنترنت. ضمن "المستمعون والتوجيه"، يجب أن يستمع ALB لطلبات HTTPS على المنفذ 443، ونريد إنشاء مجموعة أهداف تشير إلى وظيفة lambda الخاصة بنا حتى يقوم ALB بتمرير الطلبات الواردة إلى وظيفة lambda التي أنشأناها أعلاه. عليك أيضًا التأكد من أن مجموعة الأمان لديها إذن لقبول الحركة عبر المنفذ 443.
لكي نتلقى حزمة بيانات webhook، نحتاج إلى توفير نقطة نهاية لإرسال الحزم إليها. نقوم بذلك عن طريق إنشاء موازن تحميل تطبيق داخل AWS من خلال الانتقال إلى EC2 > موازين التحميل والنقر على "إنشاء موازن تحميل". سيتم مطالبتك باختيار نوع موازن التحميل الذي تريد إنشاؤه - بالنسبة لهذا، نريد إنشاء موازن تحميل تطبيق. نحتاج إلى استخدام موازن تحميل تطبيق (ALB) لبناء مستهلكنا لأن أحداث webhooks سيتم إرسالها كطلب HTTP، وتستخدم ALBs لتوجيه طلبات HTTP داخل AWS. يمكننا تنفيذ بوابة HTTP كبديل؛ ومع ذلك، نستخدم ALB لهذا المشروع لأنه أخف وزنًا وأكثر فعالية من حيث التكلفة من بوابة HTTP. من المهم أن نلاحظ أنه إذا اخترت استخدام بوابة HTTP، قد يختلف تنسيق الحدث عن ALB، وبالتالي سيتعين على وظيفة lambda الخاصة بك التعامل مع كائن الطلب وفقًا لذلك.
بمجرد إنشاء ALB الخاص بك، سيتم مطالبتك بتعيين اسم لـ ALB الخاص بك وتكوين الإعدادات الخاصة بالمخطط والأمان/الوصول - نظرًا لأننا نخطط لتلقي بيانات الأحداث من مصدر خارجي (Bird)، سنريد أن يكون ALB الخاص بنا متاحًا على الإنترنت. ضمن "المستمعون والتوجيه"، يجب أن يستمع ALB لطلبات HTTPS على المنفذ 443، ونريد إنشاء مجموعة أهداف تشير إلى وظيفة lambda الخاصة بنا حتى يقوم ALB بتمرير الطلبات الواردة إلى وظيفة lambda التي أنشأناها أعلاه. عليك أيضًا التأكد من أن مجموعة الأمان لديها إذن لقبول الحركة عبر المنفذ 443.
لكي نتلقى حزمة بيانات webhook، نحتاج إلى توفير نقطة نهاية لإرسال الحزم إليها. نقوم بذلك عن طريق إنشاء موازن تحميل تطبيق داخل AWS من خلال الانتقال إلى EC2 > موازين التحميل والنقر على "إنشاء موازن تحميل". سيتم مطالبتك باختيار نوع موازن التحميل الذي تريد إنشاؤه - بالنسبة لهذا، نريد إنشاء موازن تحميل تطبيق. نحتاج إلى استخدام موازن تحميل تطبيق (ALB) لبناء مستهلكنا لأن أحداث webhooks سيتم إرسالها كطلب HTTP، وتستخدم ALBs لتوجيه طلبات HTTP داخل AWS. يمكننا تنفيذ بوابة HTTP كبديل؛ ومع ذلك، نستخدم ALB لهذا المشروع لأنه أخف وزنًا وأكثر فعالية من حيث التكلفة من بوابة HTTP. من المهم أن نلاحظ أنه إذا اخترت استخدام بوابة HTTP، قد يختلف تنسيق الحدث عن ALB، وبالتالي سيتعين على وظيفة lambda الخاصة بك التعامل مع كائن الطلب وفقًا لذلك.
بمجرد إنشاء ALB الخاص بك، سيتم مطالبتك بتعيين اسم لـ ALB الخاص بك وتكوين الإعدادات الخاصة بالمخطط والأمان/الوصول - نظرًا لأننا نخطط لتلقي بيانات الأحداث من مصدر خارجي (Bird)، سنريد أن يكون ALB الخاص بنا متاحًا على الإنترنت. ضمن "المستمعون والتوجيه"، يجب أن يستمع ALB لطلبات HTTPS على المنفذ 443، ونريد إنشاء مجموعة أهداف تشير إلى وظيفة lambda الخاصة بنا حتى يقوم ALB بتمرير الطلبات الواردة إلى وظيفة lambda التي أنشأناها أعلاه. عليك أيضًا التأكد من أن مجموعة الأمان لديها إذن لقبول الحركة عبر المنفذ 443.
إنشاء سجل DNS لموازن الحمل
لتسهيل استخدام واجهة ALB الخاصة بنا كنقطة نهائية، سنقوم بإنشاء سجل A في DNS يشير إلى واجهة ALB الخاصة بنا. وللقيام بذلك، يمكننا استخدام خدمة AWS Route 53 (أو مزود DNS الحالي لديك) وإنشاء سجل A لاسم المضيف الذي تريد استخدامه كنقطة نهائية (على سبيل المثال، spevents.<your_domain>). عند العمل مع DNS على نطاق واسع على AWS، كن على علم بأن هناك حدود DNS غير موثقة يمكن أن تؤثر على التطبيقات ذات الحجم الكبير، خاصة تلك التي تعالج كميات كبيرة من حركة المرور الصادرة مثل أنظمة تسليم البريد الإلكتروني. يجب تكوين سجل A للإشارة إلى واجهة ALB التي أنشأناها. إذا كنت تستخدم Route 53 لإدارة سجلات DNS، يمكنك الإشارة مباشرة إلى مثيل ALB من خلال تمكين
لتسهيل استخدام واجهة ALB الخاصة بنا كنقطة نهائية، سنقوم بإنشاء سجل A في DNS يشير إلى واجهة ALB الخاصة بنا. وللقيام بذلك، يمكننا استخدام خدمة AWS Route 53 (أو مزود DNS الحالي لديك) وإنشاء سجل A لاسم المضيف الذي تريد استخدامه كنقطة نهائية (على سبيل المثال، spevents.<your_domain>). عند العمل مع DNS على نطاق واسع على AWS، كن على علم بأن هناك حدود DNS غير موثقة يمكن أن تؤثر على التطبيقات ذات الحجم الكبير، خاصة تلك التي تعالج كميات كبيرة من حركة المرور الصادرة مثل أنظمة تسليم البريد الإلكتروني. يجب تكوين سجل A للإشارة إلى واجهة ALB التي أنشأناها. إذا كنت تستخدم Route 53 لإدارة سجلات DNS، يمكنك الإشارة مباشرة إلى مثيل ALB من خلال تمكين
لتسهيل استخدام واجهة ALB الخاصة بنا كنقطة نهائية، سنقوم بإنشاء سجل A في DNS يشير إلى واجهة ALB الخاصة بنا. وللقيام بذلك، يمكننا استخدام خدمة AWS Route 53 (أو مزود DNS الحالي لديك) وإنشاء سجل A لاسم المضيف الذي تريد استخدامه كنقطة نهائية (على سبيل المثال، spevents.<your_domain>). عند العمل مع DNS على نطاق واسع على AWS، كن على علم بأن هناك حدود DNS غير موثقة يمكن أن تؤثر على التطبيقات ذات الحجم الكبير، خاصة تلك التي تعالج كميات كبيرة من حركة المرور الصادرة مثل أنظمة تسليم البريد الإلكتروني. يجب تكوين سجل A للإشارة إلى واجهة ALB التي أنشأناها. إذا كنت تستخدم Route 53 لإدارة سجلات DNS، يمكنك الإشارة مباشرة إلى مثيل ALB من خلال تمكين
إنشاء Webhook لطائر
الآن نحن مستعدون لإنشاء Webhook في Bird واستخدام اسم المضيف المحدد بواسطة سجل A أعلاه كنقطة نهاية مستهدفة. لإنشاء Webhook، انتقل إلى قسم Webhooks داخل حسابك في Bird وانقر على "إنشاء Webhook". سيطُلب منك تعيين اسم لـ Webhook الخاص بك وتوفير عنوان URL المستهدف - يجب أن يكون الهدف هو اسم المضيف لسجل A الذي أنشأته مسبقًا. لاحظ أن عنوان URL المستهدف قد يتطلب إدراج "HTTPS://" في العنوان.
بمجرد الانتهاء، تحقق من تحديد الحساب الفرعي والأحداث الصحيحة، واضغط على "إنشاء Webhook" ل保存 إعداداتك. ستتدفق بيانات الأحداث لجميع أنواع الأحداث المحددة الآن إلى عنوان URL المستهدف وسيتم استهلاكها بواسطة ALB لدينا لمعالجة البيانات في الأسفل.
الآن نحن مستعدون لإنشاء Webhook في Bird واستخدام اسم المضيف المحدد بواسطة سجل A أعلاه كنقطة نهاية مستهدفة. لإنشاء Webhook، انتقل إلى قسم Webhooks داخل حسابك في Bird وانقر على "إنشاء Webhook". سيطُلب منك تعيين اسم لـ Webhook الخاص بك وتوفير عنوان URL المستهدف - يجب أن يكون الهدف هو اسم المضيف لسجل A الذي أنشأته مسبقًا. لاحظ أن عنوان URL المستهدف قد يتطلب إدراج "HTTPS://" في العنوان.
بمجرد الانتهاء، تحقق من تحديد الحساب الفرعي والأحداث الصحيحة، واضغط على "إنشاء Webhook" ل保存 إعداداتك. ستتدفق بيانات الأحداث لجميع أنواع الأحداث المحددة الآن إلى عنوان URL المستهدف وسيتم استهلاكها بواسطة ALB لدينا لمعالجة البيانات في الأسفل.
الآن نحن مستعدون لإنشاء Webhook في Bird واستخدام اسم المضيف المحدد بواسطة سجل A أعلاه كنقطة نهاية مستهدفة. لإنشاء Webhook، انتقل إلى قسم Webhooks داخل حسابك في Bird وانقر على "إنشاء Webhook". سيطُلب منك تعيين اسم لـ Webhook الخاص بك وتوفير عنوان URL المستهدف - يجب أن يكون الهدف هو اسم المضيف لسجل A الذي أنشأته مسبقًا. لاحظ أن عنوان URL المستهدف قد يتطلب إدراج "HTTPS://" في العنوان.
بمجرد الانتهاء، تحقق من تحديد الحساب الفرعي والأحداث الصحيحة، واضغط على "إنشاء Webhook" ل保存 إعداداتك. ستتدفق بيانات الأحداث لجميع أنواع الأحداث المحددة الآن إلى عنوان URL المستهدف وسيتم استهلاكها بواسطة ALB لدينا لمعالجة البيانات في الأسفل.
معالجة بيانات حدث الويب
اعتمادًا على الغرض المقصود من تخزين بيانات حدث الطائر، قد يتم تلبية متطلباتك ببساطة عن طريق تخزين الحمولة JSON كملف مسطح. قد يكون لديك أيضًا عملية ETL سفلية قائمة بالفعل قادرة على استهلاك وتحميل البيانات بتنسيق JSON. في كلتا الحالتين، قد تتمكن من استخدام الملف المسطح الذي تم إنشاؤه بواسطة لامبدا المعالجة لدينا أعلاه كما هو.
بدلاً من ذلك، قد تحتاج إلى تحويل البيانات - مثل تحويلها من تنسيق JSON إلى تنسيق CSV - أو تحميل البيانات مباشرة إلى قاعدة بيانات. في هذا المثال، سنقوم بإنشاء دالة لامبدا بسيطة سوف تحول بيانات webhook من تنسيق JSON الأصلي إلى ملف CSV يمكن تحميله في قاعدة بيانات.
اعتمادًا على الغرض المقصود من تخزين بيانات حدث الطائر، قد يتم تلبية متطلباتك ببساطة عن طريق تخزين الحمولة JSON كملف مسطح. قد يكون لديك أيضًا عملية ETL سفلية قائمة بالفعل قادرة على استهلاك وتحميل البيانات بتنسيق JSON. في كلتا الحالتين، قد تتمكن من استخدام الملف المسطح الذي تم إنشاؤه بواسطة لامبدا المعالجة لدينا أعلاه كما هو.
بدلاً من ذلك، قد تحتاج إلى تحويل البيانات - مثل تحويلها من تنسيق JSON إلى تنسيق CSV - أو تحميل البيانات مباشرة إلى قاعدة بيانات. في هذا المثال، سنقوم بإنشاء دالة لامبدا بسيطة سوف تحول بيانات webhook من تنسيق JSON الأصلي إلى ملف CSV يمكن تحميله في قاعدة بيانات.
اعتمادًا على الغرض المقصود من تخزين بيانات حدث الطائر، قد يتم تلبية متطلباتك ببساطة عن طريق تخزين الحمولة JSON كملف مسطح. قد يكون لديك أيضًا عملية ETL سفلية قائمة بالفعل قادرة على استهلاك وتحميل البيانات بتنسيق JSON. في كلتا الحالتين، قد تتمكن من استخدام الملف المسطح الذي تم إنشاؤه بواسطة لامبدا المعالجة لدينا أعلاه كما هو.
بدلاً من ذلك، قد تحتاج إلى تحويل البيانات - مثل تحويلها من تنسيق JSON إلى تنسيق CSV - أو تحميل البيانات مباشرة إلى قاعدة بيانات. في هذا المثال، سنقوم بإنشاء دالة لامبدا بسيطة سوف تحول بيانات webhook من تنسيق JSON الأصلي إلى ملف CSV يمكن تحميله في قاعدة بيانات.
إنشاء لامدا لمعالجة البيانات
كما هو الحال مع دالة لامبادا لاستهلاك بيانات واجهة الويب، نحتاج إلى إنشاء دالة لامبادا جديدة من خلال الانتقال إلى خدمة لامبادا داخل AWS والضغط على "إنشاء دالة." ستظهر هذه الدالة الجديدة عندما يتم إنشاء ملف جديد في دلو S3 الخاص بنا - ستقوم بقراءة البيانات وتحويلها إلى ملف CSV جديد.
تقبل دالة لامبادا معلومات الملف كحدث. في دالة لامبادا النموذجية، سترى أننا أولاً لدينا سلسلة من فحوصات التحقق للتأكد من أن البيانات كاملة ومهيكلة كما هو متوقع. بعد ذلك، نقوم بتحويل الحمولة بتنسيق JSON إلى ملف CSV باستخدام مكتبة "csv" وكتابة ذلك إلى ملف مؤقت. تقتصر دالات لامبادا على كتابة الملفات المحلية في دليل "tmp/"، لذلك نقوم بإنشاء ملف CSV مؤقت ونسميه وفقًا للتقليد <batch_id>.csv. السبب وراء استخدام batch_id هنا هو ببساطة للتأكد من أن أي عمليات متوازية تعمل نتيجة تلقي عدة حمولة واجهة ويب لن تتداخل مع بعضها البعض، حيث سيكون لكل دفعة من واجهة الويب batch_id فريد.
بمجرد تحويل البيانات بالكامل إلى CSV، نقرأ بيانات CSV كتيار بايت، ونحذف الملف المؤقت، ونحفظ بيانات CSV كملف جديد على S3. من المهم ملاحظة أنه يلزم دلو S3 مختلف للإخراج، وإلا فإننا نعرض أنفسنا لإنشاء حلقة متكررة يمكن أن تؤدي إلى زيادة استخدام لامبادا وزيادة التكاليف. سنحتاج إلى تحديد دلو S3 وأين نريد تخزين ملف CSV الخاص بنا داخل دالة لامبادا لدينا. اتبع نفس الإجراء كما سبق لإنشاء دلو S3 جديد لتخزين ملف CSV الخاص بنا.
لاحظ أن دليل tmp محدود ب512 ميغا بايت من المساحة، لذا من المهم حذف الملف المؤقت لاحقًا لضمان وجود مساحة كافية للتنفيذات المستقبلية. السبب في استخدامنا لملف مؤقت، بدلاً من الكتابة مباشرة إلى S3، هو تبسيط الاتصال بـ S3 من خلال وجود طلب واحد.
تمامًا كما هو الحال مع دالة لامبادا للاستهلاك، قد تحتاج إلى تحديث الأذونات لدالة لامبادا الخاصة بعمليتك. تتطلب هذه الدالة أن تكون دور التنفيذ لديه أذونات GetObject لدلو S3 المدخل، وكلا من PutObject وGetObject لدلو S3 الناتج.
يمكن العثور على نموذج دالة لامبادا المعالجة الخاصة بنا هنا.
كما هو الحال مع دالة لامبادا لاستهلاك بيانات واجهة الويب، نحتاج إلى إنشاء دالة لامبادا جديدة من خلال الانتقال إلى خدمة لامبادا داخل AWS والضغط على "إنشاء دالة." ستظهر هذه الدالة الجديدة عندما يتم إنشاء ملف جديد في دلو S3 الخاص بنا - ستقوم بقراءة البيانات وتحويلها إلى ملف CSV جديد.
تقبل دالة لامبادا معلومات الملف كحدث. في دالة لامبادا النموذجية، سترى أننا أولاً لدينا سلسلة من فحوصات التحقق للتأكد من أن البيانات كاملة ومهيكلة كما هو متوقع. بعد ذلك، نقوم بتحويل الحمولة بتنسيق JSON إلى ملف CSV باستخدام مكتبة "csv" وكتابة ذلك إلى ملف مؤقت. تقتصر دالات لامبادا على كتابة الملفات المحلية في دليل "tmp/"، لذلك نقوم بإنشاء ملف CSV مؤقت ونسميه وفقًا للتقليد <batch_id>.csv. السبب وراء استخدام batch_id هنا هو ببساطة للتأكد من أن أي عمليات متوازية تعمل نتيجة تلقي عدة حمولة واجهة ويب لن تتداخل مع بعضها البعض، حيث سيكون لكل دفعة من واجهة الويب batch_id فريد.
بمجرد تحويل البيانات بالكامل إلى CSV، نقرأ بيانات CSV كتيار بايت، ونحذف الملف المؤقت، ونحفظ بيانات CSV كملف جديد على S3. من المهم ملاحظة أنه يلزم دلو S3 مختلف للإخراج، وإلا فإننا نعرض أنفسنا لإنشاء حلقة متكررة يمكن أن تؤدي إلى زيادة استخدام لامبادا وزيادة التكاليف. سنحتاج إلى تحديد دلو S3 وأين نريد تخزين ملف CSV الخاص بنا داخل دالة لامبادا لدينا. اتبع نفس الإجراء كما سبق لإنشاء دلو S3 جديد لتخزين ملف CSV الخاص بنا.
لاحظ أن دليل tmp محدود ب512 ميغا بايت من المساحة، لذا من المهم حذف الملف المؤقت لاحقًا لضمان وجود مساحة كافية للتنفيذات المستقبلية. السبب في استخدامنا لملف مؤقت، بدلاً من الكتابة مباشرة إلى S3، هو تبسيط الاتصال بـ S3 من خلال وجود طلب واحد.
تمامًا كما هو الحال مع دالة لامبادا للاستهلاك، قد تحتاج إلى تحديث الأذونات لدالة لامبادا الخاصة بعمليتك. تتطلب هذه الدالة أن تكون دور التنفيذ لديه أذونات GetObject لدلو S3 المدخل، وكلا من PutObject وGetObject لدلو S3 الناتج.
يمكن العثور على نموذج دالة لامبادا المعالجة الخاصة بنا هنا.
كما هو الحال مع دالة لامبادا لاستهلاك بيانات واجهة الويب، نحتاج إلى إنشاء دالة لامبادا جديدة من خلال الانتقال إلى خدمة لامبادا داخل AWS والضغط على "إنشاء دالة." ستظهر هذه الدالة الجديدة عندما يتم إنشاء ملف جديد في دلو S3 الخاص بنا - ستقوم بقراءة البيانات وتحويلها إلى ملف CSV جديد.
تقبل دالة لامبادا معلومات الملف كحدث. في دالة لامبادا النموذجية، سترى أننا أولاً لدينا سلسلة من فحوصات التحقق للتأكد من أن البيانات كاملة ومهيكلة كما هو متوقع. بعد ذلك، نقوم بتحويل الحمولة بتنسيق JSON إلى ملف CSV باستخدام مكتبة "csv" وكتابة ذلك إلى ملف مؤقت. تقتصر دالات لامبادا على كتابة الملفات المحلية في دليل "tmp/"، لذلك نقوم بإنشاء ملف CSV مؤقت ونسميه وفقًا للتقليد <batch_id>.csv. السبب وراء استخدام batch_id هنا هو ببساطة للتأكد من أن أي عمليات متوازية تعمل نتيجة تلقي عدة حمولة واجهة ويب لن تتداخل مع بعضها البعض، حيث سيكون لكل دفعة من واجهة الويب batch_id فريد.
بمجرد تحويل البيانات بالكامل إلى CSV، نقرأ بيانات CSV كتيار بايت، ونحذف الملف المؤقت، ونحفظ بيانات CSV كملف جديد على S3. من المهم ملاحظة أنه يلزم دلو S3 مختلف للإخراج، وإلا فإننا نعرض أنفسنا لإنشاء حلقة متكررة يمكن أن تؤدي إلى زيادة استخدام لامبادا وزيادة التكاليف. سنحتاج إلى تحديد دلو S3 وأين نريد تخزين ملف CSV الخاص بنا داخل دالة لامبادا لدينا. اتبع نفس الإجراء كما سبق لإنشاء دلو S3 جديد لتخزين ملف CSV الخاص بنا.
لاحظ أن دليل tmp محدود ب512 ميغا بايت من المساحة، لذا من المهم حذف الملف المؤقت لاحقًا لضمان وجود مساحة كافية للتنفيذات المستقبلية. السبب في استخدامنا لملف مؤقت، بدلاً من الكتابة مباشرة إلى S3، هو تبسيط الاتصال بـ S3 من خلال وجود طلب واحد.
تمامًا كما هو الحال مع دالة لامبادا للاستهلاك، قد تحتاج إلى تحديث الأذونات لدالة لامبادا الخاصة بعمليتك. تتطلب هذه الدالة أن تكون دور التنفيذ لديه أذونات GetObject لدلو S3 المدخل، وكلا من PutObject وGetObject لدلو S3 الناتج.
يمكن العثور على نموذج دالة لامبادا المعالجة الخاصة بنا هنا.
قم بتكوين لامبدا للتنفيذ عند تخزين بيانات جديدة على S3
الآن بعد أن تم إنشاء دالة لامبدا لدينا لتحويل الملف من تنسيق JSON إلى CSV، نحتاج إلى تكوينها للت triggers عندما يتم إنشاء ملف جديد على دلو S3 الخاص بنا. للقيام بذلك، نحتاج إلى إضافة مشغل إلى دالة لامبدا الخاصة بنا من خلال فتح دالة لامبدا الخاصة بنا والنقر على "إضافة مشغل" في أعلى الصفحة. اختر "S3" وقدم اسم دلو S3 الذي يتم تخزين أحمال الويب الخام فيه. لديك أيضًا خيار تحديد بادئة و/أو لاحقة للملف للتصفية. بمجرد تكوين الإعدادات، يمكنك إضافة المشغل بالنقر على "إضافة" في أسفل الصفحة. الآن ستقوم دالة لامبدا المعالجة الخاصة بك بالتنفيذ كلما تم إضافة ملف جديد إلى دلو S3 الخاص بك.
الآن بعد أن تم إنشاء دالة لامبدا لدينا لتحويل الملف من تنسيق JSON إلى CSV، نحتاج إلى تكوينها للت triggers عندما يتم إنشاء ملف جديد على دلو S3 الخاص بنا. للقيام بذلك، نحتاج إلى إضافة مشغل إلى دالة لامبدا الخاصة بنا من خلال فتح دالة لامبدا الخاصة بنا والنقر على "إضافة مشغل" في أعلى الصفحة. اختر "S3" وقدم اسم دلو S3 الذي يتم تخزين أحمال الويب الخام فيه. لديك أيضًا خيار تحديد بادئة و/أو لاحقة للملف للتصفية. بمجرد تكوين الإعدادات، يمكنك إضافة المشغل بالنقر على "إضافة" في أسفل الصفحة. الآن ستقوم دالة لامبدا المعالجة الخاصة بك بالتنفيذ كلما تم إضافة ملف جديد إلى دلو S3 الخاص بك.
الآن بعد أن تم إنشاء دالة لامبدا لدينا لتحويل الملف من تنسيق JSON إلى CSV، نحتاج إلى تكوينها للت triggers عندما يتم إنشاء ملف جديد على دلو S3 الخاص بنا. للقيام بذلك، نحتاج إلى إضافة مشغل إلى دالة لامبدا الخاصة بنا من خلال فتح دالة لامبدا الخاصة بنا والنقر على "إضافة مشغل" في أعلى الصفحة. اختر "S3" وقدم اسم دلو S3 الذي يتم تخزين أحمال الويب الخام فيه. لديك أيضًا خيار تحديد بادئة و/أو لاحقة للملف للتصفية. بمجرد تكوين الإعدادات، يمكنك إضافة المشغل بالنقر على "إضافة" في أسفل الصفحة. الآن ستقوم دالة لامبدا المعالجة الخاصة بك بالتنفيذ كلما تم إضافة ملف جديد إلى دلو S3 الخاص بك.
تحميل البيانات إلى قاعدة البيانات
في هذا المثال، لن أغطي تحميل البيانات إلى قاعدة البيانات بالتفصيل، ولكن إذا كنت قد تابعت هذا المثال، لديك بعض الخيارات:
تحميل البيانات مباشرة إلى قاعدة البيانات الخاصة بك ضمن دالة المعالجة الخاصة بك
استهلاك ملف CSV الخاص بك باستخدام عملية ETL معروفة
سواء كنت تستخدم خدمة قاعدة بيانات AWS، مثل RDS أو DynamoDB، أو كانت لديك قاعدة بيانات PostgreSQL خاصة بك (أو مشابهة)، يمكنك الاتصال بخدمة قاعدة البيانات الخاصة بك مباشرة من دالة المعالجة الخاصة بك. على سبيل المثال، بنفس الطريقة التي استدعينا بها خدمة S3 باستخدام "boto3" في دالتنا، يمكنك أيضًا استخدام "boto3" لاستدعاء RDS أو DynamoDB. يمكن أيضًا استخدام خدمة AWS Athena لقراءة ملفات البيانات مباشرة من الملفات المسطحة، والوصول إلى البيانات باستخدام لغة استعلام تشبه SQL. أوصي بالرجوع إلى الوثائق الخاصة بالخدمة التي تستخدمها لمزيد من المعلومات حول كيفية إنجاز ذلك بأفضل طريقة داخل بيئتك.
وبالمثل، هناك العديد من الخدمات المتاحة التي يمكن أن تساعد في استهلاك ملفات CSV وتحميل البيانات إلى قاعدة بيانات. قد يكون لديك بالفعل عملية ETL معروفة يمكنك الاستفادة منها.
نأمل أن تجد هذا الدليل مفيدًا - نتمنى لك إرسالاً سعيداً!
في هذا المثال، لن أغطي تحميل البيانات إلى قاعدة البيانات بالتفصيل، ولكن إذا كنت قد تابعت هذا المثال، لديك بعض الخيارات:
تحميل البيانات مباشرة إلى قاعدة البيانات الخاصة بك ضمن دالة المعالجة الخاصة بك
استهلاك ملف CSV الخاص بك باستخدام عملية ETL معروفة
سواء كنت تستخدم خدمة قاعدة بيانات AWS، مثل RDS أو DynamoDB، أو كانت لديك قاعدة بيانات PostgreSQL خاصة بك (أو مشابهة)، يمكنك الاتصال بخدمة قاعدة البيانات الخاصة بك مباشرة من دالة المعالجة الخاصة بك. على سبيل المثال، بنفس الطريقة التي استدعينا بها خدمة S3 باستخدام "boto3" في دالتنا، يمكنك أيضًا استخدام "boto3" لاستدعاء RDS أو DynamoDB. يمكن أيضًا استخدام خدمة AWS Athena لقراءة ملفات البيانات مباشرة من الملفات المسطحة، والوصول إلى البيانات باستخدام لغة استعلام تشبه SQL. أوصي بالرجوع إلى الوثائق الخاصة بالخدمة التي تستخدمها لمزيد من المعلومات حول كيفية إنجاز ذلك بأفضل طريقة داخل بيئتك.
وبالمثل، هناك العديد من الخدمات المتاحة التي يمكن أن تساعد في استهلاك ملفات CSV وتحميل البيانات إلى قاعدة بيانات. قد يكون لديك بالفعل عملية ETL معروفة يمكنك الاستفادة منها.
نأمل أن تجد هذا الدليل مفيدًا - نتمنى لك إرسالاً سعيداً!
في هذا المثال، لن أغطي تحميل البيانات إلى قاعدة البيانات بالتفصيل، ولكن إذا كنت قد تابعت هذا المثال، لديك بعض الخيارات:
تحميل البيانات مباشرة إلى قاعدة البيانات الخاصة بك ضمن دالة المعالجة الخاصة بك
استهلاك ملف CSV الخاص بك باستخدام عملية ETL معروفة
سواء كنت تستخدم خدمة قاعدة بيانات AWS، مثل RDS أو DynamoDB، أو كانت لديك قاعدة بيانات PostgreSQL خاصة بك (أو مشابهة)، يمكنك الاتصال بخدمة قاعدة البيانات الخاصة بك مباشرة من دالة المعالجة الخاصة بك. على سبيل المثال، بنفس الطريقة التي استدعينا بها خدمة S3 باستخدام "boto3" في دالتنا، يمكنك أيضًا استخدام "boto3" لاستدعاء RDS أو DynamoDB. يمكن أيضًا استخدام خدمة AWS Athena لقراءة ملفات البيانات مباشرة من الملفات المسطحة، والوصول إلى البيانات باستخدام لغة استعلام تشبه SQL. أوصي بالرجوع إلى الوثائق الخاصة بالخدمة التي تستخدمها لمزيد من المعلومات حول كيفية إنجاز ذلك بأفضل طريقة داخل بيئتك.
وبالمثل، هناك العديد من الخدمات المتاحة التي يمكن أن تساعد في استهلاك ملفات CSV وتحميل البيانات إلى قاعدة بيانات. قد يكون لديك بالفعل عملية ETL معروفة يمكنك الاستفادة منها.
نأمل أن تجد هذا الدليل مفيدًا - نتمنى لك إرسالاً سعيداً!
