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