إنشاء أحداث في الوقت الفعلي تقريبًا باستخدام Fleet Engine وحل Fleet Events المرجعي

تُعدّ الإشارات التي يتم تلقّيها في الوقت الفعلي تقريبًا من أسطول المركبات العاملة على الأرض مفيدة للأنشطة التجارية بعدة طرق. على سبيل المثال، يمكن للأنشطة التجارية استخدامها لإجراء ما يلي:

  • تتبُّع أداء أسطولهم وتحديد المشاكل المحتملة في وقت مبكر
  • تحسين خدمة العملاء من خلال تقديم معلومات دقيقة عن الوقت المقدّر للوصول ومعلومات التتبُّع
  • خفض التكاليف من خلال تحديد أوجه القصور ومعالجتها
  • تحسين السلامة من خلال مراقبة سلوك السائق وتحديد المخاطر المحتملة
  • تحسين مسارات السائقين وجداولهم الزمنية لتحسين الكفاءة
  • الامتثال للوائح التنظيمية من خلال تتبُّع الموقع الجغرافي للمركبة وساعات الخدمة

يوضّح هذا المستند كيف يمكن للمطوّرين تحويل الإشارات من "خدمات التنقّل" في "منصة خرائط Google"‏ ("حلّ أسطول الميل الأخير" أو "حلّ الرحلات وعمليات التسليم عند الطلب") إلى أحداث مخصّصة قابلة للتنفيذ. يتم أيضًا تناول المفاهيم الأساسية وقرارات التصميم الخاصة بمرجع أحداث الأسطول لحلول المتوفرة على GitHub.

ينطبق هذا المستند على ما يلي:

  • مهندسون معماريون على دراية بخدمات التنقّل في "منصة خرائط Google" وأحد مكوناتها الأساسية، وهو Fleet Engine. إذا كنت جديدًا في مجال "خدمات التنقّل"، ننصحك بالتعرّف على حلّ Last Mile Fleet و/أو حلّ On-demand Rides and Deliveries، حسب احتياجاتك.
  • المعماريون الذين لديهم خبرة في Google Cloud بالنسبة إلى المستخدمين الجدد على Google Cloud، ننصح بقراءة إنشاء خطوط نقل بيانات البث على Google Cloud.
  • إذا كنت تستهدف بيئات أو حِزم برامج أخرى، ركِّز على فهم نقاط الدمج والاعتبارات الرئيسية في Fleet Engine، والتي من المفترض أن تظل سارية.
  • الأشخاص الذين لديهم اهتمام عام باستكشاف كيفية إنشاء الأحداث من أساطيل المركبات واستخدامها

في نهاية هذا المستند، يجب أن يكون لديك فهم أساسي للعناصر والاعتبارات الرئيسية لنظام البث، بالإضافة إلى وحدات الإنشاء من "منصة خرائط Google" وGoogle Cloud التي تشكّل حلّ Fleet Events المرجعي.

نظرة عامة على حلّ مرجع أحداث مجموعة الأجهزة

إنّ "حلّ مرجع أحداث الأسطول" هو حلّ مفتوح المصدر يتيح لعملاء وشركاء Mobility إنشاء أحداث رئيسية استنادًا إلى مكوّنات Fleet Engine وGoogle Cloud. يتيح الحل المرجعي حاليًا للعملاء استخدام Last Mile Fleet Solution، وسيتوفّر قريبًا دعم لخدمتَي "الرحلات عند الطلب" و"التوصيل".

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

  • تغيير في الوقت المقدَّر لوصول المهمة
  • التغيير النسبي في الوقت المقدَّر للوصول إلى وجهة المهمة
  • الوقت المتبقي للوصول إلى المهمة
  • المسافة المتبقية للوصول إلى المهمة
  • تغيير حالة TaskOutcome

يمكن تخصيص كل مكوّن من مكوّنات الحلّ المرجعي ليناسب احتياجات نشاطك التجاري.

الوحدات الأساسية المنطقية

المخطط : يعرض المخطط التالي الوحدات الأساسية عالية المستوى التي يتكوّن منها الحل المرجعي لأحداث أسطول المركبات

نظرة عامة على أحداث الأسطول والوحدات الأساسية المنطقية

يحتوي الحل المرجعي على المكوّنات التالية:

  • مصدر الحدث: المكان الذي يأتي منه مصدر أحداثك الأصلي. يتضمّن كل من حلّ أسطول الميل الأخير أو حلّ الرحلات وعمليات التسليم عند الطلب عملية دمج مع Cloud Logging تساعد في تحويل سجلّات طلبات بيانات من واجهة برمجة التطبيقات (RPC) في Fleet Engine إلى مصادر أحداث متاحة للمطوّرين. هذا هو المصدر الأساسي الذي يجب استخدامه.
  • المعالجة: سيتم تحويل سجلّات استدعاء الإجراء عن بُعد (RPC) الأولية إلى أحداث تغيير الحالة ضمن هذه الكتلة التي تحتسب على مجموعة من أحداث السجلّ. لرصد هذا التغيير، يتطلّب هذا المكوّن مخزن حالة حتى يمكن مقارنة الأحداث الواردة الجديدة بالأحداث السابقة لرصد التغيير. قد لا تتضمّن الأحداث دائمًا كل المعلومات التي تهمّك. في هذه الحالات، قد يؤدي هذا الحظر إلى إجراء عمليات بحث عن البيانات في الأنظمة الخلفية عند الحاجة.
    • مخزن الحالة: توفّر بعض أُطر المعالجة بيانات وسيطة ثابتة بذاتها. في حال عدم توفّرها، يمكنك تخزين الحالة بنفسك، بما أنّ هذه الحالة يجب أن تكون فريدة لكل مركبة ونوع حدث، لذا فإنّ خدمة تخزين البيانات من النوع K-V ستكون مناسبة.
  • المتلقّي (الأحداث المخصّصة): يجب إتاحة تغيير الحالة الذي تم رصده لأي تطبيق أو خدمة يمكن أن تستفيد منه. لذلك، من الطبيعي نشر هذا الحدث المخصّص إلى نظام تسليم الأحداث للاستهلاك في المراحل اللاحقة.
  • الخدمة النهائية: الرمز الذي يستهلك الأحداث التي تم إنشاؤها ويتّخذ إجراءات فريدة لحالة الاستخدام.

اختيار الخدمة

عند تنفيذ الحل المرجعي Last Mile Fleet Solution أو On-demand Rides and Deliveries Solution (سيتم إطلاقه في أواخر الربع الثالث من عام 2023)، يكون اختيار التكنولوجيا لكل من "المصدر" و"المستودع" أمرًا بسيطًا. من ناحية أخرى، تتضمّن "المعالجة" مجموعة كبيرة من الخيارات. اختار الحلّ المرجعي خدمات Google التالية.

المخطّط : يعرض المخطّط التالي خدمة Google Cloud لتنفيذ الحل المرجعي

مكوّنات الحلّ المرجعي لأحداث الأسطول

تنسيق مشروع Cloud

ننصحك باستخدام عملية نشر تتضمّن مشاريع متعددة. ويتيح لك ذلك فصل استخدامات Google Maps Platform وGoogle Cloud بشكل واضح وربطها بترتيب الفوترة الذي تختاره.

مصدر الحدث

تكتب Last Mile Fleet Solution وOn-demand Rides and Deliveries Solution حمولات طلبات البيانات من واجهة برمجة التطبيقات واستجاباتها إلى Cloud Logging. توفّر Cloud Logging السجلّات لخدمة واحدة أو أكثر من الخدمات التي تختارها. يُعدّ التوجيه إلى Cloud Pub/Sub خيارًا مثاليًا هنا، ويتيح تحويل السجلات إلى بث أحداث بدون ترميز.

حوض ماء

في Google Cloud، تُعدّ خدمة Cloud Pub/Sub نظامًا مناسبًا لتسليم الرسائل في الوقت الفعلي تقريبًا. وكما تم تسليم الأحداث من المصدر إلى Pub/Sub، يتم أيضًا نشر الأحداث المخصّصة إلى Pub/Sub للاستهلاك في المراحل اللاحقة.

قيد المعالجة

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

  • ‫Cloud Functions كمنصة حوسبة للإصدار الأوّلي (*)
    • بدون خادم، يمكن زيادة السعة أو خفضها باستخدام عناصر التحكّم في التوسّع لإدارة التكاليف
    • لغة Java كلغة برمجة بسبب توفّر مكتبات العملاء لواجهات برمجة التطبيقات ذات الصلة بـ Fleet Engine، ما يساهم في تسهيل عملية التنفيذ
  • Cloud Firestore كمخزن للحالة
    • متجر المفتاح/القيمة بدون خادم
  • ‫Cloud Pub/Sub كنقطة دمج مع المكوّنات الأولية والنهائية
    • عملية دمج غير محكمة الربط في الوقت الفعلي تقريبًا

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

*ملاحظة: تخطّط الحلول المرجعية لإصدار عمليات تنفيذ بديلة يمكن أن تساعد في تلبية المتطلبات المختلفة.

التفعيل

لجعل عملية نشر الحل المرجعي قابلة للتكرار والتخصيص، ويمكن التحكّم في رمز المصدر، وآمنة، تم اختيار Terraform كأداة للأتمتة. ‫Terraform هي أداة IaC (البنية الأساسية كرمز) مستخدَمة على نطاق واسع وتوفّر دعمًا شاملاً لخدمة Google Cloud.

وحدات Terraform

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

الوحدات النمطية المضمّنة في الحلّ المرجعي:

  • إعداد تسجيل البيانات في Fleet Engine: يمكنك إعداد عمليات الضبط ذات الصلة بـ Cloud Logging تلقائيًا لاستخدامها مع Fleet Engine. في الحل المرجعي، تُستخدَم هذه السمة لتوجيه السجلات ذات الصلة بخدمة Fleet Engine إلى موضوع Pub/Sub محدّد.
  • نشر وظيفة Fleet Events السحابية: تحتوي على نشر نموذج التعليمات البرمجية للوظيفة، وتتعامل أيضًا مع عملية إعداد أذونات الوصول المطلوبة لإجراء عمليات دمج آمنة بين المشاريع.
  • نشر الحلّ المرجعي الكامل: يستدعي هذا الإجراء الوحدتَين السابقتَين ويغطي الحلّ بأكمله.

الأمان

يتم استخدام "إدارة الهوية وإمكانية الوصول" لتطبيق مبادئ الحدّ الأدنى من الامتيازات إلى جانب أفضل ممارسات الأمان في Google Cloud، مثل انتحال هوية حساب الخدمة. يمكنك الرجوع إلى المقالات التالية للتعرّف بشكل أفضل على ما تقدّمه Google Cloud لمنحك المزيد من التحكّم في الأمان.

الإجراءات التالية

أنت الآن على استعداد للوصول إلى حلّ مرجع أحداث الأسطول واستكشافه بشكل أكبر. انتقِل إلى GitHub للبدء.

الملحق

جمع المتطلبات

ننصحك بجمع متطلباتك في وقت مبكر من العملية.

أولاً، سجِّل التفاصيل حول سبب اهتمامك باستخدام الأحداث شبه الآنية أو حاجتك إلى استخدامها. في ما يلي بعض الأسئلة لمساعدتك في تحديد احتياجاتك.

  • ما هي المعلومات المطلوبة ليكون مصدر الأحداث مفيدًا؟
    • هل يمكن استخلاص النتيجة من البيانات التي تم جمعها أو إنتاجها في خدمات Google فقط؟ أو هل يجب إثراء البيانات باستخدام أنظمة خارجية مدمجة؟ إذا كان الأمر كذلك، فما هي هذه الأنظمة وما هي واجهات التكامل التي توفّرها؟
    • ما هي المقاييس التي تريد قياسها كنشاط تجاري؟ كيف يتم تحديدها؟
    • إذا كنت بحاجة إلى احتساب المقاييس على مستوى الأحداث، ما هو نوع التجميع المطلوب؟ حاول ترتيب الخطوات المنطقية. (مثال: قارِن بين الوقت المقدَّر للوصول/الوقت الفعلي للوصول ومؤشرات مستوى الخدمة على مستوى مجموعة فرعية من الأسطول خلال ساعات الذروة لاحتساب الأداء في ظل قيود الموارد.
  • لماذا أنت مهتم بنموذج مستند إلى الأحداث بدلاً من نموذج الدفعات؟ هل هذا لتقليل وقت الاستجابة (الوقت المستغرق لتنفيذ الإجراء) أو لدمج غير محكم (المرونة)؟
    • إذا كان وقت الاستجابة منخفضًا، حدِّد القيمة "low". دقائق؟ ثوانٍ؟ أقل من ثانية؟ وما هو وقت الاستجابة؟
  • هل سبق لك الاستثمار في مجموعة من التقنيات والمهارات ذات الصلة كفريق؟ إذا كان الأمر كذلك، ما هو وما هي نقاط الدمج التي يوفّرها؟
    • هل هناك أي متطلبات لا يمكن لأنظمتك الحالية تلبيتها أو قد تواجه صعوبة في معالجة الأحداث الواردة من أسطولك؟

Design principles

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

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

مفاهيم البث

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

  • الحجم : على عكس المعالجة المجمّعة التي يمكنك فيها عادةً معرفة حجم البيانات المطلوب معالجتها، لا يمكنك ذلك في البث. يمكن أن يؤدي الازدحام المروري في مدينة إلى إنشاء الكثير من الأحداث فجأة من منطقة معيّنة، وسيظل عليك معالجتها.
  • التقسيم إلى نوافذ : بدلاً من معالجة الأحداث واحدًا تلو الآخر، قد تحتاج في كثير من الأحيان إلى تجميع الأحداث على مدى فترة زمنية في "نوافذ" أصغر كوحدة للحساب. تتوفّر استراتيجيات مختلفة لتقسيم البيانات إلى نوافذ، مثل "النوافذ الثابتة (مثل كل يوم تقويمي)" و"النوافذ المنزلقة (آخر 5 دقائق)" و"نوافذ الجلسات (أثناء هذه الرحلة)"، وعليك الاختيار من بينها. وكلما طالت الفترة، زادت التأخيرات في عرض النتائج. اختَر النموذج والإعدادات المناسبة التي تلبي متطلباتك.
  • التشغيل : في بعض الحالات، لا يكون لديك خيار آخر سوى استخدام فترات زمنية أطول نسبيًا. ومع ذلك، لا تريد الانتظار حتى نهاية الفترة الزمنية لإنتاج الأحداث، بل تريد بدلاً من ذلك عرض نتائج وسيطة في الفترة الزمنية. يمكن تطبيق هذا المفهوم في حالات الاستخدام التي يكون فيها قيمة في عرض نتائج سريعة أولاً، ثم تصحيحها لاحقًا. لنفترض أنّك تريد إرسال حالة وسيطة عند اكتمال عملية التسليم بنسبة %25 و%50 و% 75.
  • الترتيب : لا تصل الأحداث بالضرورة إلى النظام بالترتيب الذي تم إنشاؤها به. وينطبق ذلك بشكل خاص على حالات الاستخدام التي تتضمّن التواصل عبر شبكات الجوّال، ما يؤدي إلى حدوث تأخير ومسارات توجيه معقّدة. عليك أن تكون على دراية بالفرق بين "وقت الحدث" (الوقت الذي وقع فيه الحدث فعليًا) و "وقت المعالجة" (الوقت الذي وصل فيه الحدث إلى النظام) والتعامل مع الأحداث وفقًا لذلك. بشكل عام، يجب معالجة الأحداث استنادًا إلى "وقت الحدث".
  • تسليم الرسائل: مرة واحدة على الأقل مقابل مرة واحدة بالضبط: تتيح منصات الأحداث المختلفة إمكانية استخدام أي من الخيارين. استنادًا إلى حالة الاستخدام، عليك مراعاة استراتيجيات إعادة المحاولة أو إزالة التكرار.
  • الشمولية : كما هو الحال مع تغيير ترتيب الرسائل، هناك احتمال بفقدان بعض الرسائل. قد يرجع ذلك إلى إيقاف تشغيل التطبيق والجهاز بسبب عمر بطارية الجهاز أو حدوث تلف غير مقصود في الهاتف أو فقدان الاتصال أثناء التواجد في نفق أو تلقّي رسالة ولكن خارج نطاق زمني مقبول. كيف سيؤثر عدم الاكتمال في نتائجك؟

هذه القائمة ليست كاملة، ولكنّها مقدّمة. في ما يلي بعض القراءات التي ننصح بها بشدة والتي يمكن أن تساعدك في تعميق فهمك لكل منها.

المساهمون

تتولّى Google صيانة هذا المستند. كتب المساهمون التاليون هذا المحتوى في الأصل.

المؤلفون الرئيسيون: