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

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

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

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

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

  • مهندسون معماريون على دراية بخدمات التنقّل في Google Maps Platform وأحد مكوناتها الأساسية، وهو 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، وسيتم توفير دعم لخدمتَي On-demand Rides وDelivery في وقت لاحق.

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

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

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

المكوّنات الأساسية المنطقية

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

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

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

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

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

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

Design principles

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

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

مفاهيم البث

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

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

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

المساهمون

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

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