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

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

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

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

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

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

Design principles

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

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

مفاهيم البث

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

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

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

المساهمون

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

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