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

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

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

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

يرتبط هذا المستند بما يلي:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

تشير "أحداث الأسطول" إلى مكونات أساسية لإنشاء الحلول.

تنسيق مشروع Cloud

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

مصدر الحدث

يُسجِّل "حلّ أسطول Last Mile" و "حلّ عمليات التسليم والرحلات عند الطلب" حمولات طلبات واجهة برمجة التطبيقات واستجاباتها في سجلّ تسجيل البيانات في السحابة الإلكترونية. تُرسِل خدمة Cloud Logging السجلات إلى خدمة واحدة أو أكثر من الخدمات التي تختارها. إنّ توجيه البيانات إلى Cloud Pub/Sub هو خيار مثالي هنا، ويسمح بتحويل السجلات إلى بث أحداث بدون ترميز.

حوض ماء

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

قيد المعالجة

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

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

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

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

التفعيل

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

وحدات Terraform

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

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

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

الأمان

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

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

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

الملحق

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

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

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

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

Design principles

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

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

مفاهيم البث

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

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

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

المساهمون

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

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