أحداث Fleet Engine في الوقت الفعلي

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

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

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

هذا المستند مخصّص لما يلي:

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

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

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

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

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

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

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

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

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

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

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

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

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

عند تنفيذ الحلّ المرجعي لـ "حلّ Last Mile Fleet" أو "حلّ الرحلات والتوصيل عند الطلب" (سيتم طرحه في أواخر الربع الثالث من عام 2023)، يكون اختيار التكنولوجيا لـ "المصدر" و"المستودع" بسيطًا. من ناحية أخرى، تتوفّر مجموعة واسعة من الخيارات في "المعالجة". اختار الحلّ المرجعي خدمات Google التالية.

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

العناصر الأساسية للحلّ المرجعي "أحداث الأسطول"

تنسيق مشروع على السحابة الإلكترونية

ننصحك باستخدام عملية نشر متعددة المشاريع كإعداد تلقائي. يتيح لك ذلك الفصل بين استهلاك "منصة خرائط Google" وGoogle Cloud وربطهما بترتيب الفوترة الذي تختاره.

مصدر الحدث

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

Design principles

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

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

مفاهيم البث

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

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

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

المساهمون

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

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