إنشاء أحداث في الوقت الفعلي تقريبًا باستخدام 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 التي تشكّل الحل المرجعي لأحداث الأسطول.

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

إنّ "حلّ مرجع أحداث الأسطول" هو حلّ مفتوح المصدر يتيح لعملاء وشركاء 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" و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 محدّد.
  • نشر وظيفة السحابة الإلكترونية الخاصة بأحداث الأسطول: يحتوي على عملية نشر نموذج الرمز البرمجي للوظيفة، ويتولّى أيضًا تنفيذ عملية إعداد الأذونات المطلوبة لتنفيذ عملية دمج آمنة بين المشاريع.
  • نشر الحلّ المرجعي الكامل: يستدعي هذا الإجراء الوحدتَين السابقتَين ويغطي الحلّ بأكمله.

الأمان

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

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

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

الملحق

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

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

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

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

Design principles

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

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

مفاهيم البث

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

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

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

المساهمون

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

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