سیگنال‌های تقریباً واقعی از ناوگانی که روی زمین کار می‌کنند از طرق مختلفی برای کسب‌وکارها مفید هستند. به عنوان مثال، مشاغل می توانند از این موارد برای موارد زیر استفاده کنند:
- عملکرد ناوگان خود را زیر نظر داشته و مشکلات احتمالی را زودتر شناسایی کنید
- با ارائه ETAهای دقیق و اطلاعات ردیابی، خدمات مشتری را بهبود بخشید
- با شناسایی و رفع ناکارآمدی ها هزینه ها را کاهش دهید
- بهبود ایمنی با نظارت بر رفتار راننده و شناسایی خطرات احتمالی
- مسیرها و برنامه های راننده را برای بهبود کارایی بهینه کنید
- با ردیابی مکان خودرو و ساعات سرویس از مقررات پیروی کنید
این سند نشان می‌دهد که چگونه توسعه‌دهندگان می‌توانند سیگنال‌های « سرویس‌های تحرک » پلتفرم نقشه‌های Google (« راه‌حل ناوگان آخرین مایل» (LMFS) یا « راه‌حل سواری و تحویل برحسب تقاضا» (ODRD) را به رویدادهای سفارشی عملی تبدیل کنند. مفاهیم کلیدی و تصمیم‌های طراحی راه حل مرجع رویدادهای ناوگان موجود در GitHub نیز پوشش داده شده است.
این سند مربوط به:
- معمارانی که با « سرویس‌های تحرک » پلتفرم نقشه‌های گوگل و یکی از اجزای اصلی آن «موتور ناوگان» آشنا هستند. برای کسانی که تازه با "خدمات Mobility" آشنا شده اند، توصیه می کنیم بسته به نیاز خود با راه حل آخرین مایل ناوگان و/یا راه حل سواری و تحویل بر اساس تقاضا آشنا شوید.
- معمارانی آشنا با Google Cloud. برای کسانی که تازه وارد Google Cloud شده‌اند، ایجاد خطوط لوله داده‌های جریانی در Google Cloud یک پیشخوان توصیه می‌شود.
- اگر محیط‌ها یا پشته‌های نرم‌افزار دیگری را هدف قرار می‌دهید، بر درک نکات ادغام Fleet Engine و ملاحظات کلیدی تمرکز کنید، که همچنان باید قابل اجرا باشند.
- کسانی که علاقه عمومی به کاوش در مورد چگونگی ایجاد و استفاده از رویدادهای ناوگان دارند.
در پایان این سند، باید درک اساسی از عناصر و ملاحظات کلیدی یک سیستم پخش جریانی، همراه با بلوک‌های ساختمانی از پلتفرم نقشه‌های Google و Google Cloud که راه‌حل مرجع رویدادهای ناوگان را تشکیل می‌دهند، داشته باشید.
بررسی اجمالی راه حل مرجع رویدادهای ناوگان
راه حل مرجع رویدادهای ناوگان یک راه حل منبع باز است که به مشتریان و شرکای Mobility امکان می دهد رویدادهای کلیدی را در بالای اجزای Fleet Engine و Google Cloud ایجاد کنند. امروزه، راه حل مرجع از مشتریانی که از راه حل ناوگان آخرین مایل استفاده می کنند با پشتیبانی از سواری و تحویل بر اساس تقاضا پشتیبانی می کند.
راه حل به طور خودکار رویدادها را بر اساس تغییرات داده های خاص مرتبط با وظایف یا سفرها ایجاد می کند. می‌توانید از این رویدادها برای ارسال اعلان‌هایی مانند موارد زیر برای ذینفعان یا راه‌اندازی سایر اقدامات برای ناوگان خود استفاده کنید.
- تغییر ETA برای رسیدن کار
- تغییر ETA نسبی برای رسیدن کار
- زمان باقی مانده تا رسیدن کار
- فاصله باقی مانده تا رسیدن به کار
- تغییر وضعیت TaskOutcome
هر جزء از راه حل مرجع را می توان مطابق با نیازهای کسب و کار شما سفارشی کرد.
بلوک های ساختمانی منطقی
نمودار : نمودار زیر بلوک های ساختمانی سطح بالایی را نشان می دهد که راه حل مرجع Fleet Events را تشکیل می دهند
محلول مرجع شامل اجزای زیر است:
- منبع رویداد : جایی که جریان اصلی رویداد از آنجا می آید. هر دو " راه حل ناوگان آخرین مایل" یا " راه حل سواری و تحویل بر اساس تقاضا" با Cloud Logging یکپارچه شده اند که به تبدیل گزارش تماس های Fleet Engine RPC به جریان های رویداد در دسترس توسعه دهندگان کمک می کند. این منبع اصلی برای مصرف است.
- پردازش : گزارش‌های تماس خام RPC به رویدادهای تغییر حالت در این بلوک تبدیل می‌شوند که روی جریانی از رویدادهای گزارش محاسبه می‌شود. برای تشخیص چنین تغییری، این مؤلفه نیاز به ذخیره وضعیت دارد تا بتوان رویدادهای ورودی جدید را با موارد قبلی مقایسه کرد تا تغییرات را تشخیص دهد. رویدادها ممکن است همیشه شامل تمام اطلاعات مورد علاقه نباشند. در چنین مواردی، این بلوک ممکن است در صورت لزوم، تماس‌هایی را با backendها جستجو کند.
- ذخیره‌سازی دولتی : برخی از چارچوب‌های پردازشی داده‌های میانی را به‌خودی خود ارائه می‌دهند. اما در غیر این صورت، به منظور ذخیره حالت به تنهایی، از آنجایی که اینها باید منحصر به یک وسیله نقلیه و نوع رویداد باشند، یک سرویس پایداری داده نوع KV مناسب است.
- سینک (رویدادهای سفارشی) : تغییر وضعیت شناسایی شده باید در دسترس هر برنامه یا سرویسی باشد که می تواند از آن بهره مند شود. بنابراین، انتشار این رویداد سفارشی در یک سیستم تحویل رویداد برای مصرف پایین دست، یک انتخاب طبیعی است.
- سرویس Downstream : کدی که رویدادهای ایجاد شده را مصرف می کند و اقدامات منحصر به فرد مورد استفاده شما را انجام می دهد.
انتخاب خدمات
هنگامی که نوبت به اجرای راه حل مرجع برای " راه حل ناوگان آخرین مایل" یا " راه حل سواری و تحویل بر اساس تقاضا" (در اواخر سه ماهه سوم 2023) می رسد، انتخاب فناوری برای "Source" و "Sink" ساده است. از سوی دیگر. دست، "پردازش" دارای طیف گسترده ای از گزینه های راه حل مرجع خدمات گوگل زیر را انتخاب کرده است.
نمودار : نمودار زیر سرویس Google Cloud را برای پیاده سازی راه حل مرجع نشان می دهد
طرح‌بندی پروژه ابری
توصیه می کنیم به طور پیش فرض یک استقرار چند پروژه ای را اجرا کنید. این به این دلیل است که مصرف‌های پلتفرم نقشه‌های Google و Google Cloud کاملاً از هم جدا شده و به ترتیب صورت‌حساب انتخابی شما مرتبط باشد.
منبع رویداد
"Last Mile Fleet Solution" و " On-demand Rides and Deliveries Solution" درخواست API را می نویسند و به Cloud Logging پاسخ می دهند. Cloud Logging گزارش‌ها را به یک یا چند سرویس انتخابی تحویل می‌دهد. مسیریابی به Cloud Pub/Sub یک انتخاب عالی در اینجا است و امکان تبدیل گزارش‌ها را به جریان رویداد بدون کدنویسی فراهم می‌کند.
- ورود به سیستم | عملکرد ناوگان (برای کاربران LMFS)
- ورود به سیستم | پیشرفت سفر و سفارش (برای کاربران ODRD)
- مشاهده گزارش‌های هدایت‌شده به Pub/Sub : ورود به سیستم → نمای کلی ادغام Pub/Sub
غرق شدن
در Google Cloud، Cloud Pub/Sub سیستم تحویل پیام در زمان واقعی انتخابی است. درست مانند نحوه تحویل رویدادها از منبع به Pub/Sub، رویدادهای سفارشی نیز برای مصرف پایین‌دستی در Pub/Sub منتشر می‌شوند.
پردازش
اجزای زیر در پردازش رویدادها نقش دارند. مانند سایر بلوک‌های سازنده، اجزای پردازشی کاملاً بدون سرور هستند و به‌خوبی در مقیاس بالا و پایین مقیاس می‌شوند.
- توابع ابری به عنوان یک پلت فرم محاسباتی برای انتشار اولیه (*)
- بدون سرور، با کنترل‌های مقیاس‌بندی برای مدیریت هزینه‌ها، مقیاس را افزایش و کاهش می‌دهد
- جاوا به عنوان زبان برنامه نویسی با توجه به در دسترس بودن کتابخانه های مشتری برای API های مرتبط با Fleet Engine که به سهولت پیاده سازی کمک می کند.
- Cloud Firestore به عنوان یک فروشگاه دولتی
- فروشگاه Key-Value بدون سرور
- Cloud Pub/Sub به عنوان نقطه ادغام با اجزای بالادستی و پایین دستی
- ادغام تقریباً واقعی به صورت آزاد
توابع را می توان همانطور که با تنظیمات پیش فرض است استفاده کرد، اما می توان آن را مجدداً پیکربندی کرد. پارامترهای پیکربندی از طریق اسکریپت‌های استقرار تنظیم می‌شوند و با جزئیات در ماژول terraform README مربوطه مستند می‌شوند.
*توجه: این راه حل مرجع قصد دارد پیاده سازی های جایگزینی را منتشر کند که می تواند به نیازهای مختلف کمک کند.
استقرار
برای اینکه فرآیند استقرار راه حل مرجع تکرارپذیر، قابل تنظیم، کد منبع قابل کنترل و ایمن باشد، Terraform به عنوان ابزار اتوماسیون انتخاب شده است. Terraform یک ابزار IaC (زیرساخت به عنوان کد) است که به طور گسترده ای پذیرفته شده است که از Google Cloud پشتیبانی می کند.
- ارائه‌دهنده پلتفرم Google Cloud : اسناد منبع پشتیبانی شده توسط «ارائه‌دهنده پلتفرم Google Cloud»
- بهترین روش‌ها برای استفاده از Terraform : راهنمایی غنی در مورد بهترین روش در Google Cloud
- Terraform Registry : ماژول های اضافی که توسط گوگل و انجمن پشتیبانی می شوند
ماژول های Terraform
به جای ساخت یک ماژول استقرار راه حل مرجع یکپارچه بزرگ، بلوک های اتوماسیون قابل استفاده مجدد به عنوان ماژول های Terraform پیاده سازی می شوند که می توانند به طور مستقل مورد استفاده قرار گیرند. ماژول ها طیف گسترده ای از متغیرهای قابل تنظیم را ارائه می دهند که اکثر آنها دارای مقادیر پیش فرض هستند تا بتوانید به سرعت شروع به کار کنید، اما همچنین انعطاف پذیری برای سفارشی سازی بر اساس نیازها و ترجیحات خود را داشته باشید.
ماژول های موجود در راه حل مرجع:
- پیکربندی ورود به سیستم Fleet Engine : تنظیمات مربوط به Cloud Logging را برای استفاده با Fleet Engine به صورت خودکار انجام دهید. در راه حل مرجع، از آن برای مسیریابی گزارش های مربوط به Fleet Engine به یک موضوع Pub/Sub مشخص استفاده می شود.
- استقرار عملکرد ابر رویدادهای ناوگان : شامل استقرار کد تابع نمونه است و همچنین خودکارسازی تنظیمات مجوز مورد نیاز برای یکپارچه سازی بین پروژه ای ایمن را انجام می دهد.
- استقرار راه حل مرجع کل : دو ماژول قبلی را فراخوانی می کند و کل راه حل را پیچیده می کند.
امنیت
IAM برای اعمال اصول حداقل امتیاز همراه با بهترین شیوه‌های امنیتی Google Cloud مانند جعل هویت حساب سرویس اتخاذ شده است. برای درک بهتر آنچه که Google Cloud برای کنترل بیشتر بر امنیت به شما ارائه می دهد، به مقالات زیر مراجعه کنید.
اقدامات بعدی
اکنون آماده دسترسی و کاوش بیشتر به راه حل مرجع رویدادهای ناوگان هستید. برای شروع به GitHub بروید.
ضمیمه
خواسته های خود را جمع آوری کنید
ما توصیه می کنیم که در مراحل اولیه نیازهای خود را جمع آوری کنید.
ابتدا، جزئیات مربوط به اینکه چرا علاقه مند هستید یا نیاز به استفاده از رویدادهای نزدیک به زمان واقعی دارید را ثبت کنید. در اینجا چند سوال وجود دارد که به شما کمک می کند تا نیازهای خود را متبلور کنید.
- برای مفید بودن جریان رویداد چه اطلاعاتی لازم است؟
- آیا می‌توان نتیجه را صرفاً از داده‌های جمع‌آوری‌شده یا تولید شده در سرویس‌های Google به دست آورد؟ یا، آیا غنی سازی داده ها با سیستم های خارجی یکپارچه مورد نیاز است؟ اگر چنین است، آن سیستم ها چیست و چه رابط های یکپارچه ای ارائه می کنند؟
- معیارهایی که می خواهید به عنوان یک کسب و کار اندازه گیری کنید چیست؟ چگونه تعریف می شوند؟
- اگر نیاز به محاسبه معیارها در سراسر رویدادها دارید، چه نوع تجمعی لازم است؟ سعی کنید مراحل منطقی را طرح ریزی کنید. (به عنوان مثال، ETA/ATA را در برابر SLOها در یک بخش از ناوگان در ساعات اوج مصرف برای محاسبه عملکرد تحت محدودیت منابع مقایسه کنید.)
- چرا به یک مدل مبتنی بر رویداد یا به جای دسته ای علاقه مند هستید؟ آیا این برای تأخیر کمتر (زمان برای اقدام) یا برای یکپارچگی ضعیف (چابکی) است؟
- اگر برای تاخیر کم، "کم" را تعریف کنید. دقیقه؟ ثانیه ها؟ فرعی؟ و چه تاخیری؟
- آیا قبلاً روی یک پشته فناوری و مهارت های مرتبط به عنوان یک تیم سرمایه گذاری کرده اید؟ اگر بله، چیست و چه نقاط ادغامی را فراهم می کند؟
- آیا هنگام پردازش رویدادهایی که از ناوگان شما می آیند، الزاماتی وجود دارد که سیستم های فعلی شما نمی توانند برآورده کنند یا ممکن است با آن مشکل داشته باشند؟
اصول طراحی
همیشه داشتن یک فرآیند فکری برای دنبال کردن مفید است. این به تصمیم گیری های طراحی منسجم کمک می کند، به خصوص زمانی که گزینه های مختلفی برای انتخاب دارید.
- پیش فرض به گزینه های ساده تر.
- پیش‌فرض روی زمان تا ارزش کوتاه‌تر است. کد کمتر، منحنی یادگیری کمتر.
- برای تأخیر و کارایی، هدف خود را رسیدن به نواری که تعیین کرده اید داشته باشید، نه حداکثر بهینه سازی. همچنین از بهینه سازی شدید اجتناب کنید زیرا اغلب منجر به افزایش پیچیدگی می شود.
- در مورد هزینه هم همینطور. هزینه را معقول نگه دارید ممکن است هنوز در وضعیتی نباشید که بتوانید متعهد به استفاده از خدمات با ارزش اما نسبتاً گران‌تر باشید.
- در مرحله آزمایشی، کاهش مقیاس می تواند به اندازه افزایش مقیاس مهم باشد. پلتفرمی را در نظر بگیرید که انعطاف‌پذیری را برای افزایش مقیاس با کلاه و همچنین کاهش (در حالت ایده‌آل تا صفر) فراهم می‌کند تا در هنگام انجام هیچ کاری خرج نکنید. عملکرد بالا با زیرساخت همیشه روشن را می توان بعداً در سفر در نظر گرفت، زمانی که به نیازهای آن اطمینان دارید.
- مشاهده کنید و اندازه گیری کنید تا بتوانید بعداً محل کار بیشتر را تشخیص دهید.
- سرویس‌ها را به‌طور ضعیفی مرتبط نگه دارید. تعویض قطعه قطعه بعدا آسان تر می شود.
- آخرین اما نه کم اهمیت، امنیت نمی تواند سست شود. به عنوان یک سرویس در حال اجرا در یک محیط ابری عمومی، هیچ دری ناامن به سیستم نمی تواند وجود داشته باشد.
مفاهیم جریانی
اگر در مورد رویداد مبتنی بر یا پخش جریانی نسبتاً تازه کار هستید، مفاهیم کلیدی وجود دارد که ارزش آگاهی از آنها را دارد، که برخی از آنها می توانند بسیار متفاوت از پردازش دسته ای باشند.
- مقیاس : برخلاف پردازش دسته‌ای، که معمولاً ایده خوبی از میزان داده‌های مورد پردازش دارید، در جریان نمی‌توانید. یک ترافیک در یک شهر می تواند اتفاقات زیادی را به طور ناگهانی از یک منطقه خاص ایجاد کند، و شما هنوز هم باید بتوانید آن را پردازش کنید.
- پنجره سازی : به جای پردازش یک به یک رویدادها، اغلب اتفاق می افتد که می خواهید رویدادها را در یک جدول زمانی در "پنجره های" کوچکتر به عنوان واحدی برای محاسبه گروه بندی کنید. استراتژی‌های پنجره‌سازی مختلفی مانند «پنجره‌های ثابت (مثلاً هر روز تقویم)»، «پنجره‌های کشویی (5 دقیقه آخر)»، «پنجره‌های جلسه (در طول این سفر)» وجود دارد که باید از بین آنها انتخاب کنید. هرچه این پنجره طولانی تر باشد، تاخیر در تولید نتایج بیشتر می شود. مدل و پیکربندی مناسبی را انتخاب کنید که نیازهای شما را برآورده کند.
- راه اندازی : مواردی وجود دارد که شما چاره ای جز داشتن پنجره های نسبتا طولانی ندارید. با این حال، شما نمی خواهید برای تولید رویدادها منتظر پایان پنجره باشید، بلکه در عوض، نتایج میانی را در این بین منتشر کنید. این مفهوم را می توان برای موارد استفاده که در آن ابتدا نتایج سریع را برگرداند و سپس بعداً آنها را تصحیح کرد، پیاده سازی کرد. تصور کنید که وضعیت متوسط را در 25٪، 50٪، 75٪ تکمیل یک تحویل منتشر کنید.
- ترتیب : رویدادها لزوماً به ترتیبی که ایجاد شده است به سیستم نمی رسند. به خصوص برای موارد استفاده با درگیر شدن ارتباط از طریق شبکه های تلفن همراه که تاخیر و مسیرهای مسیریابی پیچیده را اضافه می کند. شما باید از تفاوت بین "زمان رویداد" (زمانی که رویداد واقعاً رخ داده است) و "زمان فرآیند" (زمانی که رویداد به سیستم می رسد) آگاه باشید و بر اساس آن رویدادها را مدیریت کنید. به طور کلی، شما می خواهید رویدادها را بر اساس "زمان رویداد" پردازش کنید.
- تحویل پیام - حداقل یک بار در مقابل دقیقاً یک بار : پلتفرم رویدادهای مختلف پشتیبانی متفاوتی از آنها دارند. بسته به مورد استفاده خود، باید راهبردهای تلاش مجدد یا حذف مجدد را در نظر بگیرید.
- کامل بودن : درست مانند تغییر سفارش، احتمال گم شدن پیام ها وجود دارد. این می تواند به دلیل خاموش شدن برنامه و دستگاه به دلیل عمر باتری دستگاه، آسیب غیر عمدی به تلفن، از دست رفتن اتصال در حین حضور در تونل، یا پیامی باشد که دریافت شده است اما فقط خارج از یک پنجره قابل قبول است. چگونه ناقص بودن بر نتایج شما تأثیر می گذارد؟
این یک لیست کامل نیست بلکه یک مقدمه است. در اینجا چند مطالعه بسیار توصیه شده است که می تواند به شما کمک کند درک خود را از هر یک بیشتر عمیق تر کنید.
مشارکت کنندگان
گوگل این سند را حفظ می کند. مشارکت کنندگان زیر در ابتدا آن را نوشتند.
نویسندگان اصلی:
- مری پیشنی | مدیر محصول، پلتفرم نقشه های گوگل
- اتل بائو | مهندس نرم افزار، پلتفرم نقشه های گوگل
- مهند المیسکی | مهندس نرم افزار، پلتفرم نقشه های گوگل
- نائویا موریتانی | مهندس راه حل، پلتفرم نقشه های گوگل