إنّ الإشارات التي يتم تلقيها في وقت قريب من الوقت الفعلي من الأسطول الذي يعمل على الأرض مفيدة للأنشطة التجارية بعدة طرق. على سبيل المثال، يمكن للأنشطة التجارية استخدام هذه الأدوات لإجراء ما يلي:
- تتبُّع أداء أسطولها وتحديد المشاكل المحتملة في وقت مبكر on
- تحسين خدمة العملاء من خلال توفير الوقت المقدّر للوصول ومعلومات التتبّع الدقيقة
- تقليل التكاليف من خلال تحديد نقاط الضعف ومعالجتها
- تحسين السلامة من خلال مراقبة سلوك السائق وتحديد المخاطر المحتملة
- تحسين مسارات السائق والجداول الزمنية لزيادة الكفاءة
- الامتثال للوائح التنظيمية من خلال تتبُّع الموقع الجغرافي للمركبة وساعات الخدمة
يوضّح هذا المستند كيفية تحويل الإشارات من "خدمات التنقل" ("Last Mile Fleet Solution" (LMFS) أو "On-demand Rides and Deliveries Solution" (ODRD) في منصة "خرائط Google" إلى أحداث مخصّصة قابلة للتنفيذ. نتناول أيضًا المفاهيم الرئيسية وقرارات التصميم المتعلقة بالحل المرجعي لفعاليات الأسطول المتوفّر على GitHub.
يرتبط هذا المستند بما يلي:
- المهندسون المعماريون المطلعون على "خدمات التنقل" في "منصة خرائط Google" وأحد مكوّناتها الأساسية، وهو "محرك الأسطول" بالنسبة إلى المستخدمين الجدد في "خدمات التنقل"، ننصحك بالتعرّف على حلّ أسطول Last Mile و/أو حلّ الركوب والتوصيل عند الطلب، استنادًا إلى احتياجاتك.
- المهندسون المعماريون المطلعون على Google Cloud بالنسبة إلى المستخدمين الجدد في Google Cloud، ننصحك بالاطّلاع على مقالة إنشاء قنوات بيانات البث على Google Cloud قبل قراءة هذه المقالة.
- إذا كنت تستهدِف بيئات أو حِزم برامج أخرى، ركِّز على فهم نقاط دمج Fleet Engine والعوامل الرئيسية التي يجب مراعاتها، والتي من المفترض أن تظلّ سارية.
- الذين لديهم اهتمام عام باستكشاف كيفية إنشاء واستخدام أحداث الأساطيل
بحلول نهاية هذا المستند، من المفترض أن يكون لديك فهم أساسي ل العناصر الرئيسية والاعتبارات المتعلّقة بنظام البث، بالإضافة إلى وحدات التأسيس من "منصّة خرائط Google" وGoogle Cloud التي تشكّل الحلّ المرجعي لأحداث الأسطول.
نظرة عامة على الحلول المرجعية لفعاليات الأسطول
"الحلّ المرجعي لأحداث Fleet" هو حلّ مفتوح المصدر يتيح لعملاء وشركائنا في Mobility إنشاء أحداث رئيسية بالإضافة إلى Fleet Engine ومكوّنات Google Cloud. في الوقت الحالي، يتيح الحل المرجعي للعملاء استخدام "حلّ أسطول النقل للمرحلة الأخيرة" مع إتاحة "الرحلات عند الطلب" و"التوصيل" في المستقبل.
ينشئ الحلّ الأحداث تلقائيًا استنادًا إلى التغييرات في بيانات معيّنة مرتبطة بالمهام أو الرحلات. يمكنك استخدام هذه الأحداث لإرسال إشعارات مثل الإشعارات التالية إلى الأطراف المعنية أو بدء إجراءات أخرى لمجموعة أجهزتك.
- تغيير وقت الوصول المقدَّر للمهمة
- تغيير في الوقت المقدَّر النسبي للوصول إلى المهمة
- الوقت المتبقّي لوصول المهمة
- المسافة المتبقية للوصول إلى المهمة
- تغيير حالة TaskOutcome
يمكن تخصيص كل مكوّن من المكوّنات في الحلّ المرجعي ليناسب احتياجات نشاطك التجاري.
الوحدات الأساسية المنطقية
المخطّط البياني : يعرض المخطّط البياني التالي الوحدات الأساسية العالية المستوى التي تشكّل الحل المرجعي لأحداث الأسطول.
يحتوي الحل المرجعي على المكوّنات التالية:
- مصدر الحدث: المكان الذي ينبع منه مصدر الأحداث الأصلي تم دمج كل من "Last Mile Fleet Solution" أو "حلول الرحلات والتسليمات عند الطلب" مع ميزة "تسجيل الدخول باستخدام السحابة الإلكترونية" (Cloud Logging) التي تساعد في تحويل سجلات مكالمات Fleet Engine RPC إلى ساحات للفعاليات متاحة للمطوّرين. وهذا هو المصدر الأساسي الذي يجب استخدامه.
- المعالجة: يتم تحويل سجلّات المكالمات الأوّلية لاستدعاء الإجراء عن بُعد (RPC) إلى أحداث تغيير الحالة
ضمن هذه المجموعة التي تُجري العمليات الحسابية على مجموعة من أحداث السجلّ. لرصد هذا
التغيير، يتطلّب هذا المكوّن ذاكرة حالة حتى تتمكّن من مقارنة الأحداث الجديدة الواردة
بالأحداث السابقة لرصد التغيير. قد لا تشمل الأحداث دائمًا
كل المعلومات ذات الصلة. في هذه الحالات، قد تُجري هذه الحظر
عمليات بحث عن الخلفيات حسب الحاجة.
- مخزّن الحالة: توفّر بعض إطارات العمل للمعالجة بيانات مؤقتة مستدامة بحد ذاتها. وإذا لم يكن الأمر كذلك، يمكنك استخدام خدمة ثبات بيانات من النوع "مفتاح/قيمة" لحفظ الحالة بنفسك، لأنّ هذه البيانات يجب أن تكون فريدة لكل مركبة ونوع حدث.
- الوجهة (الأحداث المخصّصة): يجب إتاحة تغيير الحالة الذي تم رصده ل أي تطبيق أو خدمة يمكنهما الاستفادة منه. لذلك، من الطبيعي أن يكون الحدث المخصّص هذا هو الخيار المفضّل لنشره في نظام إرسال الأحداث بهدف استهلاكه في مرحلة ما بعد المعالجة.
- الخدمة في مرحلة ما بعد المعالجة: الرمز الذي يستخدِم الأحداث التي تم إنشاؤها ويتّخذ إجراءات فريدة لحالة الاستخدام
اختيار الخدمة
في ما يتعلّق بتنفيذ الحلّ المرجعي لـ "Last Mile Fleet Solution" أو "حلول الرحلات والتسليمات عند الطلب عند الطلب" (يتوفّر في أواخر الربع الثالث من عام 2023)، يجب أن تكون عملية اختيار التكنولوجيا في كل من "Source" و"Sink" واضحة. من ناحية أخرى، يشتمل خيار "المعالجة" على مجموعة كبيرة من الخيارات. اختار الحل المرجعي خدمات Google التالية.
المخطّط البياني : يعرض المخطّط البياني التالي خدمة Google Cloud لتنفيذ الحلّ المرجعي.
تنسيق مشروع Cloud
ننصحك باستخدام الإعداد التلقائي لنشر مشاريع متعددة. وذلك كي يتم الفصل تمامًا بين استهلاك "منصة خرائط Google" وGoogle Cloud وربطها بترتيب الفوترة الذي تختاره.
مصدر الحدث
يُسجِّل "حلّ أسطول Last Mile" و "حلّ عمليات التسليم والرحلات عند الطلب" حمولات طلبات واجهة برمجة التطبيقات واستجاباتها في سجلّ تسجيل البيانات في السحابة الإلكترونية. تُرسِل خدمة Cloud Logging السجلات إلى خدمة واحدة أو أكثر من الخدمات التي تختارها. إنّ توجيه البيانات إلى Cloud Pub/Sub هو خيار مثالي هنا، ويسمح بتحويل السجلات إلى بث أحداث بدون ترميز.
- التسجيل | أداء ملفّات الأسطول (لمستخدمي LMFS)
- التسجيل | الرحلة والطلب التقدم (لمستخدمي ODRD)
- عرض السجلات التي يتم توجيهها إلى Pub/Sub : التسجيل → نظرة عامة على دمج 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.
- موفِّر Google Cloud Platform: مستندات المورد المتوافق مع "موفِّر Google Cloud Platform"
- أفضل الممارسات لاستخدام Terraform: إرشادات مفصّلة حول أفضل طريقة لاعتماده في Google Cloud
- Terraform Registry: وحدات إضافية متوافقة مع Google والمنتدى
وحدات Terraform
بدلاً من إنشاء وحدة واحدة كبيرة ومتكاملة لنشر الحل المرجعي، يتم تنفيذ وحدات التشغيل الآلي القابلة لإعادة الاستخدام كوحدات Terraform التي يمكن استخدامها بشكلٍ مستقل. توفر الوحدات مجموعة كبيرة من المتغيرات القابلة للتهيئة، ومعظمها يحتوي على قيم افتراضية حتى تتمكن من البدء بسرعة، مع التمتع أيضًا بالمرونة في التخصيص بناءً على احتياجاتك وتفضيلاتك.
الوحدات المضمّنة في الحلّ المرجعي:
- إعدادات تسجيل Fleet Engine: يمكنك إعداد ميزة تسجيل Cloud logging تلقائيًا لاستخدامها مع Fleet Engine. في الحل المرجعي، يتم استخدام هذه السمة لتوجيه السجلات المتعلّقة بـ Fleet Engine إلى موضوع Pub/Sub محدّد.
- نشر وظائف السحابة الإلكترونية لأحداث الأسطول: يحتوي على نموذج لنشر التعليمات البرمجية للوظيفة ويعالج أيضًا التشغيل الآلي لإعدادات الأذونات المطلوبة لدمج آمن بين المشاريع.
- نشر الحل المرجعي الكامل: لاستدعاء الوحدتين السابقتين وتضمين الحل بأكمله في التفاف للحل بأكمله
الأمان
يتمّ استخدام إدارة الهوية وإمكانية الوصول لتطبيق مبادئ الحدّ الأدنى من الأذونات مع أفضل ممارسات الأمان في Google Cloud، مثل انتحال هوية حساب الخدمة. يمكنك الرجوع إلى مقالات Google Cloud التالية للتعرّف بشكل أفضل على الميزات التي تقدّمها لك لمنحك المزيد من التحكّم في الأمان.
الإجراءات التالية
يمكنك الآن الوصول إلى الحلّ المرجعي لفعاليات الأسطول واستكشافه. انتقِل إلى GitHub للبدء.
الملحق
جمع المتطلبات
ننصحك بجمع متطلباتك في وقت مبكر من العملية.
أولاً، سجِّل التفاصيل حول سبب اهتمامك باستخدام الأحداث التي تحدث في الوقت الفعلي تقريبًا أو الحاجة إلى استخدامها. إليك بعض الأسئلة لمساعدتك في تحديد احتياجاتك بوضوح.
- ما هي المعلومات المطلوبة لكي يكون مصدر أحداث مفيدًا؟
- هل يمكن اشتقاق النتيجة من البيانات التي تمّ رصدها أو إنشاؤها في خدمات Google فقط؟ أو هل يلزم إثراء البيانات باستخدام الأنظمة الخارجية المتكاملة؟ إذا كان الأمر كذلك، ما هي هذه الأنظمة وما هي واجهات الدمج التي توفرها؟
- ما هي المقاييس التي تريد قياسها بصفتك نشاطًا تجاريًا؟ كيف يتم تحديد هذه الأنواع؟
- إذا كنت بحاجة إلى احتساب المقاييس على مستوى الأحداث، ما هو نوع التجميع الذي يتطلّب ذلك؟ حاوِل ترتيب الخطوات المنطقية. (مثال: قارِن بين وقت الوصول المقدَّر (ETA) أو وقت الوصول الفعلي (ATA) وحدود الخدمة الدنيا (SLO) على مستوى مجموعة فرعية من الأسطول خلال ساعات الذروة لحساب الأداء في ظلّ قيود الموارد.)
- لماذا أنت مهتم بالنموذج المستند إلى الحدث أو بدلاً من العرض المجمّع؟ هل هذا لخفض وقت الاستجابة (الوقت اللازم لتنفيذ إجراء) أو لدمج غير محكم؟
- إذا كان وقت الاستجابة منخفضًا، حدِّد "منخفض". دقائق؟ ثوانٍ؟ أقل من ثانية؟ وما وقت الاستجابة؟
- هل استثمرت بالفعل في مكدس للتكنولوجيا والمهارات ذات الصلة كفريق؟ إذا كان الأمر كذلك، فما هي نقاط الدمج التي يوفرها؟
- هل هناك أي متطلبات لا تستطيع أنظمتك الحالية تلبيتها أو قد تواجهها عند معالجة الأحداث القادمة من أسطولك؟
Design principles
من المفيد دائمًا أن يكون لديك بعض عملية التفكير لتتبعها. يساعد ذلك في اتخاذ قرارات تصميمية متّسقة، خاصةً عندما يكون لديك مجموعة متنوعة من الخيارات للاختيار من بينها.
- الخيارات الأسهل تلقائيًا
- ضبط الخيار التلقائي على وقت أقصر إلى قيمة أقل. رمز أقل، منحنى تعلُّم أقل
- بالنسبة إلى وقت الاستجابة والأداء، استهدِف تحقيق المستوى الذي حدّدته، وليس الحد الأقصى للتحسين. تجنَّب أيضًا التحسين المفرط لأنّه يؤدي غالبًا إلى زيادة الصعوبة.
- ينطبق الشيء نفسه على التكلفة. حافظ على التكلفة المعقولة. قد لا تكون في مرحلة تسمح لك بالالتزام باستخدام خدمات قيمة للغاية ولكنها باهظة التكلفة نسبيًا.
- في المرحلة التجريبية، لا تقل أهمية تقليص الحجم عن أهمية توسيع نطاق النشاط التجاري. فكّر في منصة توفر المرونة في التوسعة مع الحد الأقصى كذلك وتخفيضها (من الناحية المثالية إلى الصفر) بحيث لا تنفق في حالة عدم اتخاذ أي إجراء. يمكن التفكير في تحقيق أداء عالٍ باستخدام بنية أساسية تعمل دائمًا في وقت لاحق من الرحلة، عندما تكون متأكدًا من احتياجاتها.
- راقِب وقارِس حتى تتمكّن لاحقًا من تحديد الجوانب التي تحتاج إلى مزيد من العمل عليها.
- يجب إبقاء الخدمات مرتبطة ببعضها بشكل فضفاض. ويسهّل ذلك التبديل بين القطع لاحقًا.
- أخيرًا وليس آخرًا، يجب أن تكون إجراءات الأمان مشددة. وبما أنّها خدمة تعمل على بيئة سحابة إلكترونية عامة، لا يمكن أن تكون هناك أي أبواب غير آمنة للوصول إلى النظام.
مفاهيم البث
إذا كنت مبتدئًا نسبيًا في استخدام ميزة "الاستناد إلى الأحداث" أو ميزة "البث"، هناك مفاهيم رئيسية يُرجى أخذها في الاعتبار، وبعضها قد يختلف كثيرًا عن المعالجة المجمّعة.
- الحجم : على عكس المعالجة المجمّعة، حيث يكون لديك عادةً معرفة جيدة بكمية البيانات التي يجب معالجتها، لا يمكنك ذلك في البث. يمكن أن تؤدي ازدحامات المرور في مدينة إلى إنشاء الكثير من الأحداث فجأة من منطقة معيّنة، ويجب أن تظل قادرًا على معالجتها.
- النطاق الزمني : بدلاً من معالجة الأحداث الواحد تلو الآخر، غالبًا ما يكون مطلوبًا تجميع الأحداث على مستوى مخطط زمني في "نطاقات زمنية" أصغر كأحد الوحدات الحسابية. هناك استراتيجيات مختلفة لتحديد الفترات الزمنية، مثل "فترات زمنية ثابتة (مثل كل يوم تقويمي)" و"فترات زمنية متغيّرة (آخر 5 دقائق)" و"فترات الجلسات (خلال هذه الرحلة)"، ويجب الاختيار من بينها. وكلما طالت الفترة، طالت فترة تأخّر ظهور النتائج. اختَر النموذج والإعداد المناسبَين اللذَين يستوفيان متطلباتك.
- تشغيل : في بعض الحالات، ليس لديك خيار آخر سوى أن يكون لديك فترات زمنية أطول نسبيًا. ومع ذلك، لا تريد الانتظار حتى نهاية النافذة لإنشاء الأحداث، ولكن بدلاً من ذلك، يمكنك عرض نتائج مؤقتة في هذه الفترة. يمكن تطبيق هذا المفهوم على حالات الاستخدام التي يكون فيها مفيدًا عرض نتائج سريعة أولاً، ثم تصحيحها لاحقًا. تخيّل إرسال حالة وسيطة عند اكتمال 25% و50% و75% من عملية الإرسال.
- الترتيب : لا تصل الأحداث بالضرورة إلى النظام بالترتيب الذي تم فيه إنشاؤها. ويُنصح باستخدام هذا الإعداد بشكل خاص لحالات الاستخدام التي تتضمّن اتصالات عبر شبكات الجوّال التي تؤدي إلى تأخير ومسارات توجيه معقّدة. يجب أن تكون على دراية بالفرق بين "وقت الحدث" (وقت وقوع الحدث فعليًا) و "وقت المعالجة" (وقت وصول الحدث إلى النظام) ومعالجة الأحداث وفقًا لذلك. بشكل عام، تريد معالجة الأحداث استنادًا إلى "وقت الحدث".
- تسليم الرسائل: مرة واحدة على الأقل مقابل مرة واحدة بالضبط: توفّر منصّات الأحداث المختلفة دعمًا مختلفًا لهذه الميزة. استنادًا إلى حالة الاستخدام، عليك التفكير في استراتيجيات إعادة المحاولة أو إزالة التكرار.
- الاكتمال : تمامًا مثل تغيير الترتيب، هناك احتمال أن يتم فقدان الرسائل. قد يرجع ذلك إلى إيقاف التطبيق والجهاز بسبب عمر بطارية الجهاز أو تلف الهاتف غير المقصود أو فقدان الاتصال أثناء الاتصال عبر نفق أو رسالة تم استلامها ولكن خارج الموعد المقبول. كيف سيؤثّر عدم اكتمال البيانات في النتائج التي تحقّقها؟
هذه ليست قائمة كاملة، بل هي مقدّمة. إليك بعض المراجع التي ننصح بها بشدة والتي يمكن أن تساعدك في فهم كل موضوع بشكل أفضل.
المساهمون
تحتفظ Google بهذا المستند. كتب المساهمون التاليون هذه المقالة في الأصل.
المؤلفون الرئيسيون:
- ماري بيشني | مديرة المنتج، "منصة خرائط Google"
- إيثيل باو| مهندسة البرامج، "منصة خرائط Google"
- مهند الميسكي | مهندس برمجيات، "منصة خرائط Google"
- ناويا موريتانيو | مهندس حلول، منصة خرائط Google