سیگنال‌های تقریباً هم‌زمان از ناوگان درحال کار روی زمین به روش‌های مختلفی برای کسب‌وکارها مفید است. برای مثال، کسب‌وکارها می‌توانند از این موارد برای کارهای زیر استفاده کنند:
- عملکرد ناوگان خود را نظارت کنند و مشکلات احتمالی را زودتر شناسایی کنند
- با ارائه زمان تخمینی ورود دقیق و اطلاعات پیگیری، خدمات مشتری را بهبود دهید
- کاهش هزینه‌ها با شناسایی و رفع ناکارآمدی‌ها
- بهبود ایمنی با نظارت بر رفتار راننده و شناسایی خطرات احتمالی
- بهینه‌سازی مسیرها و زمان‌بندی‌های راننده برای بهبود کارایی
- با ردیابی مکان خودرو و ساعت‌های خدمات، از مقررات پیروی کنید
این سند نشان می‌دهد که توسعه‌دهندگان چگونه می‌توانند نشان‌های «خدمات جابه‌جایی» Google Maps Platform («راهکار ناوگان مرحله آخر» (LMFS) یا «راهکار تحویل و سواری درخواستی» (ODRD) را به رویدادهای سفارشی قابل‌اجرا تبدیل کنند. مفاهیم کلیدی و تصمیمات طراحی راه‌حل مرجع رویدادهای ناوگان موجود در GitHub نیز پوشش داده شده است.
این سند مربوط به موارد زیر است:
- معمارانی که با «خدمات جابه‌جایی» پلاتفرم Google Maps و یکی از مؤلفه‌های اصلی آن، «موتور ناوگان»، آشنایی دارند. برای کسانی که با «خدمات جابه‌جایی» آشنایی ندارند، توصیه می‌کنیم بسته به نیازهایتان با Last Mile Fleet Solution و/یا On-demand Rides and Deliveries Solution آشنا شوید.
- معماران آشنا با Google Cloud. برای کسانی که با Google Cloud آشنایی ندارند، ساختن خطوط لوله داده جاری‌سازی در Google Cloud پیش‌خوانی توصیه‌شده است.
- اگر محیط‌ها یا پشته‌های نرم‌افزاری دیگری را هدف قرار می‌دهید، بر درک نقاط ادغام Fleet Engine و ملاحظات کلیدی تمرکز کنید که همچنان باید قابل‌اجرا باشند.
- افرادی که به‌طور کلی علاقه‌مند به کاوش در نحوه تولید و استفاده از رویدادهای ناوگان هستند.
در پایان این سند، باید درک پایه‌ای از عناصر کلیدی و ملاحظات یک سیستم جاری‌سازی، همراه با بلوک‌های ساختمانی از Google Maps Platform و Google Cloud که راهکار مرجع رویدادهای ناوگان را تشکیل می‌دهند، داشته باشید.
نمای کلی راهکار مرجع رویدادهای ناوگان
«راهکار مرجع رویدادهای ناوگان» راهکاری متن‌باز است که به مشتریان و شرکای «جابه‌جایی» امکان می‌دهد رویدادهای کلیدی را در بالای «موتور ناوگان» و مؤلفه‌های Google Cloud تولید کنند. امروز، راه‌حل مرجع از مشتریانی که از «راه‌حل ناوگان مایل آخر» استفاده می‌کنند پشتیبانی می‌کند و پشتیبانی از «سفر و ارسال درخواستی» به‌زودی اضافه می‌شود.
این راه‌حل به‌طور خودکار رویدادهایی را براساس تغییرات داده‌های خاص مرتبط با تکالیف یا سفرها تولید می‌کند. می‌توانید از این رویدادها برای ارسال اعلان‌هایی مثل موارد زیر به ذینفعان یا راه‌اندازی کنش‌های دیگر برای ناوگانتان استفاده کنید.
- تغییر زمان تخمینی رسیدن برای رسیدن به تکلیف
- تغییر زمان تخمینی رسیدن نسبی برای رسیدن تکلیف
- زمان باقی‌مانده تا رسیدن به تکلیف
- فاصله باقی‌مانده تا رسیدن به تکلیف
- تغییر وضعیت TaskOutcome
هر مؤلفه از راهکار مرجع را می‌توان برای مطابقت با نیازهای کسب‌وکارتان سفارشی‌سازی کرد.
واحدهای سازنده منطقی
نمودار : نمودار زیر بلوک‌های ساختمانی سطح بالا را نشان می‌دهد که راهکار مرجع «رویدادهای ناوگان» را تشکیل می‌دهند
Reference Solution شامل مؤلفه‌های زیر است:
- منبع رویداد: جایی که جریان رویداد اصلی از آن می‌آید. هر دو «راهکار ناوگان مایل آخر» یا «راهکار سواری و تحویل درخواستی» با Cloud Logging ادغام شده‌اند که به تبدیل گزارش‌های تماس RPC موتور ناوگان به جریان‌های رویداد دردسترس برای توسعه‌دهندگان کمک می‌کند. این منبع اصلی برای مصرف است.
- درحال پردازش: گزارش‌های تماس RPC خام به رویدادهای تغییر وضعیت تبدیل می‌شوند
در این بلوک که روی جریانی از رویدادهای گزارش محاسبه می‌شود. برای شناسایی چنین
تغییری، این مؤلفه به یک فروشگاه حالت نیاز دارد تا رویدادهای ورودی جدید
بتوانند با رویدادهای قبلی مقایسه شوند و تغییر شناسایی شود. رویدادها ممکن است همیشه
شامل همه اطلاعات موردنظر نباشند. در این موارد، این بلوک ممکن است
درصورت نیاز، تماس‌های جستجو را به زیرینه‌ها برقرار کند.
- ذخیره وضعیت: برخی چارچوب‌های پردازش، داده‌های واسطه‌ای را ارائه می‌دهند که به‌خودی‌خود پایدار هستند. اما اگر این‌طور نیست، برای ذخیره کردن وضعیت به‌تنهایی، چون این‌ها باید برای هر خودرو و نوع رویداد منحصربه‌فرد باشند، سرویس پایداری داده از نوع K-V گزینه مناسبی است.
- سینک (رویدادهای سفارشی): تغییر وضعیت شناسایی‌شده باید برای هر برنامه یا سرویسی که می‌تواند از آن بهره‌مند شود دردسترس قرار گیرد. بنابراین، انتشار این رویداد سفارشی در سیستم تحویل رویداد برای مصرف پایین‌دستی یک انتخاب طبیعی است.
- سرویس پایین‌دست: کدی که رویدادهای تولیدشده را مصرف می‌کند و اقداماتی را انجام می‌دهد که مختص مورد استفاده شما است.
انتخاب سرویس
وقتی نوبت به پیاده‌سازی راهکار مرجع برای «راهکار ناوگان مایل آخر» یا «راهکار سواری و تحویل درخواستی» (اواخر سه‌ماهه سوم ۲۰۲۳) می‌رسد، انتخاب فناوری برای «منبع» و «سینک» ساده است. ازسوی دیگر، «پردازش» طیف گسترده‌ای از گزینه‌ها را دارد. راه‌حل مرجع سرویس‌های Google زیر را انتخاب کرده است.
نمودار : نمودار زیر سرویس Google Cloud را برای پیاده‌سازی راهکار مرجع نشان می‌دهد
چیدمان پروژه ابری
توصیه می‌کنیم به‌طور پیش‌فرض از استقرار چندپروژه‌ای استفاده کنید. این کار برای این است که مصرف Google Cloud و «پلاتفرم Google Maps» به‌طور واضح از هم جدا شوند و به ترتیب صورت‌حساب انتخابی شما مرتبط شوند.
منبع رویداد
«Last Mile Fleet Solution» و «On-demand Rides and Deliveries Solution» بارداده‌های درخواست و پاسخ میانای برنامه‌سازی کاربردی را در Cloud Logging می‌نویسند. Cloud Logging گزارش‌ها را به یک یا چند سرویس انتخابی ارسال می‌کند. مسیریابی به Cloud Pub/Sub انتخاب عالی‌ای در اینجا است و امکان تبدیل گزارش‌ها به جریان رویداد را بدون کدنویسی فراهم می‌کند.
- ثبت گزارش | عملکرد ناوگان (برای کاربران LMFS)
- ثبت کردن | پیشرفت سفر و سفارش (برای کاربران ODRD)
- مشاهده گزارش‌های هدایت‌شده به Pub/Sub : Logging → نمای کلی ادغام Pub/Sub
روشویی
در Google Cloud، Cloud Pub/Sub سیستم ارسال پیام تقریباً هم‌زمان است. درست مانند نحوه ارسال رویدادها از منبع به Pub/Sub، رویدادهای سفارشی نیز برای مصرف پایین‌دستی در Pub/Sub منتشر می‌شوند.
درحال پردازش
مؤلفه‌های زیر در پردازش رویداد نقش دارند. مانند سایر واحدهای سازنده، اجزای پردازش کاملاً بدون سرور هستند و به‌خوبی مقیاس‌پذیرند.
- توابع ابری به‌عنوان پلاتفرم محاسباتی برای انتشار اولیه (*)
- بدون سرور، با کنترل‌های مقیاس‌بندی برای مدیریت هزینه‌ها مقیاس‌بندی می‌شود
- جاوا به‌عنوان زبان برنامه‌نویسی با توجه به دردسترس بودن کتابخانه‌های مشتری برای میاناهای برنامه‌سازی کاربردی مرتبط با Fleet Engine که به سهولت پیاده‌سازی کمک می‌کند
- Cloud Firestore به‌عنوان فروشگاه ایالتی
- ذخیره‌سازی کلید-مقدار بدون سرور
- Cloud Pub/Sub به‌عنوان نقطه ادغام
با مؤلفه‌های بالادستی و پایین‌دستی
- ادغام تقریباً هم‌زمان با اتصال ضعیف
این توابع را می‌توان با تنظیمات پیش‌فرض به‌همان صورت که هستند استفاده کرد، اما می‌توان آن‌ها را دوباره پیکربندی کرد. پارامترهای پیکربندی ازطریق اسکریپت‌های استقرار تنظیم می‌شوند و به‌طور مفصل در READMEهای ماژول terraform مربوطه مستند شده‌اند.
*توجه: این راهکار مرجع قصد دارد پیاده‌سازی‌های جایگزینی را منتشر کند که می‌تواند به برآورده کردن الزامات مختلف کمک کند.
استقرار
برای اینکه فرایند استقرار راه‌حل مرجع تکرارپذیر، قابل‌سفارشی‌سازی، قابل‌کنترل ازطریق کد منبع، و ایمن باشد، Terraform به‌عنوان ابزار خودکارسازی انتخاب شده است. Terraform ابزار IaC (زیرساخت به‌عنوان کد) است که به‌طور گسترده پذیرفته شده است و پشتیبانی غنی‌ای از Google Cloud دارد.
- Google Cloud Platform Provider: Documentation of resource supported by the "Google Cloud Platform Provider"
- روال‌های مطلوب برای استفاده از Terraform: راهنمایی غنی درباره بهترین روش استفاده در Google Cloud
- Terraform Registry: پیمانه‌های اضافی که Google و انجمن پشتیبانی می‌کنند
پیمانه‌های Terraform
به‌جای ساختن یک واحد استقرار راه‌حل مرجع یکپارچه بزرگ، بلوک‌های قابل‌استفاده مجدد خودکارسازی به‌عنوان واحدهای Terraform پیاده‌سازی می‌شوند که می‌توانند به‌طور مستقل استفاده شوند. ماژول‌ها طیف گسترده‌ای از متغیرهای قابل‌پیکربندی را ارائه می‌دهند که اکثر آن‌ها دارای مقادیر پیش‌فرض هستند تا بتوانید به‌سرعت شروع کنید، اما همچنین انعطاف‌پذیری لازم برای سفارشی‌سازی براساس نیازها و اولویت‌هایتان را داشته باشید.
پیمانه‌های موجود در راه‌حل مرجع:
- پیکربندی ثبت گزارش Fleet Engine: پیکربندی‌های مربوط به Cloud Logging را برای استفاده با Fleet Engine خودکارسازی کنید. در راه‌حل مرجع، از آن برای هدایت گزارش‌های مربوط به Fleet Engine به موضوع Pub/Sub مشخص‌شده استفاده می‌شود.
- استقرار تابع ابری Fleet Events: حاوی استقرار کد تابع نمونه است و همچنین خودکارسازی تنظیمات اجازه موردنیاز برای ادغام امن بین پروژه‌ها را مدیریت می‌کند.
- استقرار کل راه‌حل مرجع: دو واحد قبلی را فراخوانی می‌کند و کل راه‌حل را دربرمی‌گیرد.
امنیت
IAM برای اعمال اصول حداقل امتیاز همراه با روال‌های مطلوب امنیتی Google Cloud، مثل جعل هویت «حساب سرویس»، اتخاذ شده است. برای درک بهتر آنچه Google Cloud برای کنترل بیشتر بر امنیت به شما ارائه می‌دهد، به مقاله‌های زیر مراجعه کنید.
کنش‌های بعدی
اکنون آماده‌اید تا به راهکار مرجع رویدادهای ناوگان دسترسی پیدا کنید و آن را بیشتر کاوش کنید. برای شروع، به GitHub بروید.
ضمیمه
گردآوری کردن موارد ضروری
توصیه می‌کنیم الزاماتتان را در مراحل اولیه فرایند جمع‌آوری کنید.
ابتدا جزئیات مربوط به اینکه چرا به استفاده از رویدادهای تقریباً هم‌زمان علاقه‌مندید یا به آن نیاز دارید را ثبت کنید. در اینجا چند سؤال وجود دارد که به شما کمک می‌کند نیازهایتان را شفاف کنید.
- چه اطلاعاتی برای مفید بودن جاری‌سازی رویداد لازم است؟
- آیا نتیجه را می‌توان صرفاً از داده‌های ضبط‌شده یا تولیدشده در سرویس‌های Google به‌دست آورد؟ یا غنی‌سازی داده‌ها با سیستم‌های خارجی یکپارچه لازم است؟ اگر پاسخ مثبت است، آن سیستم‌ها کدامند و چه میاناهای ادغامی ارائه می‌دهند؟
- به‌عنوان کسب‌وکار، چه سنجه‌هایی را می‌خواهید اندازه‌گیری کنید؟ چگونه تعریف می‌شوند؟
- اگر لازم است سنجه‌ها را در رویدادها محاسبه کنید، این کار به چه نوع تجمیعی نیاز دارد؟ سعی کنید مراحل منطقی را طرح‌بندی کنید. (مثلاً Compare ETA/ATA against SLOs across a subset of the fleet during peak hours to compute performance under resource constraints.)
- چرا به مدل مبتنی بر رویداد علاقه دارید و نه دسته‌ای؟ آیا این
برای تأخیر کمتر (زمان اقدام) است یا برای ادغام با اتصال ضعیف
(چابکی)؟
- اگر برای تأخیر کم است، «کم» را تعریف کنید. دقیقه؟ ثانیه؟ زیرثانیه؟ و چه تأخیری؟
- آیا قبلاً به‌عنوان یک تیم در پشته فناوری و مهارت‌های مرتبط سرمایه‌گذاری کرده‌اید؟ اگر پاسخ مثبت است، این سیستم چیست و چه نقاط ادغامی ارائه می‌دهد؟
- آیا الزامی وجود دارد که سیستم‌های فعلی شما نتوانند آن را برآورده کنند یا ممکن است هنگام پردازش رویدادهای دریافتی از ناوگان شما با آن مشکل داشته باشند؟
اصول طراحی
همیشه مفید است که فرایند فکری‌ای برای دنبال کردن وجود داشته باشد. این کار به اتخاذ تصمیمات طراحی منسجم کمک می‌کند، به‌ویژه زمانی که گزینه‌های متنوعی برای انتخاب دارید.
- به‌طور پیش‌فرض گزینه‌های ساده‌تر را انتخاب کنید.
- به‌طور پیش‌فرض به زمان کوتاه‌تر برای ارزش‌گذاری. کد کمتر، منحنی یادگیری پایین‌تر.
- برای تأخیر و عملکرد، هدف را برآورده کردن معیاری که تعیین کرده‌اید قرار دهید، نه حداکثر بهینه‌سازی. همچنین از بهینه‌سازی بیش‌ازحد اجتناب کنید زیرا اغلب منجر به افزودن پیچیدگی می‌شود.
- همین امر برای هزینه نیز صادق است. هزینه را معقول نگه دارید. ممکن است هنوز در وضعیتی نباشید که بتوانید متعهد به استفاده از خدمات باارزش اما نسبتاً گران‌تر شوید.
- در مرحله آزمایشی، کاهش مقیاس می‌تواند به‌اندازه افزایش مقیاس مهم باشد. پلاتفرمی را درنظر بگیرید که انعطاف‌پذیری لازم را برای افزایش مقیاس با سقف و همچنین کاهش مقیاس (در حالت ایده‌آل به صفر) فراهم کند تا وقتی کاری انجام نمی‌دهید، هزینه‌ای پرداخت نکنید. عملکرد بالا با زیرساخت همیشه روشن را می‌توان بعداً در این مسیر درنظر گرفت، یعنی زمانی که از نیازهای آن مطمئن شدید.
- مشاهده و اندازه‌گیری کنید تا بتوانید بعداً تشخیص دهید که کجا باید بیشتر کار کنید.
- سرویس‌ها را به‌صورت جفت‌های آزاد نگه دارید. این کار باعث می‌شود بعداً راحت‌تر بتوانید قطعات را یکی‌یکی عوض کنید.
- و در آخر، امنیت نباید ضعیف باشد. به‌عنوان سرویسی که در محیط ابری عمومی اجرا می‌شود، هیچ درِ ناامنی به سیستم وجود ندارد.
مفاهیم جاری‌سازی
اگر نسبتاً تازه‌کار هستید و با پردازش دسته‌ای یا جاری‌سازی آشنایی ندارید، مفاهیم کلیدی‌ای وجود دارد که بهتر است از آن‌ها آگاه باشید، برخی‌از این مفاهیم ممکن است با پردازش دسته‌ای بسیار متفاوت باشند.
- مقیاس : برخلاف پردازش دسته‌ای که معمولاً ایده خوبی از مقدار داده‌ای که باید پردازش شود دارید، در جاری‌سازی نمی‌توانید این کار را انجام دهید. ترافیک در یک شهر می‌تواند به‌طور ناگهانی رویدادهای زیادی را از منطقه خاصی ایجاد کند، و شما همچنان باید بتوانید آن را پردازش کنید.
- پنجره‌بندی : به‌جای پردازش رویدادها به‌صورت تک‌تک، اغلب پیش می‌آید که بخواهید رویدادها را در یک خط زمان به «پنجره‌های» کوچک‌تر به‌عنوان واحدی برای محاسبه گروه‌بندی کنید. راهبردهای پنجره‌بندی مختلفی وجود دارد، ازجمله «پنجره‌های ثابت (مثلاً هر روز تقویمی)»، «پنجره‌های لغزان (۵ دقیقه آخر)»، «پنجره‌های جلسه (درطول این سفر)» که باید از بین آن‌ها انتخاب کنید. هرچه پنجره طولانی‌تر باشد، تأخیر در تولید نتایج بیشتر خواهد بود. مدل و پیکربندی مناسبی را که الزامات شما را برآورده می‌کند انتخاب کنید.
- راه‌اندازی : مواردی وجود دارد که شما چاره دیگری ندارید جز اینکه پنجره‌های نسبتاً طولانی‌تری داشته باشید. بااین‌حال، نمی‌خواهید برای تولید رویدادها تا پایان پنجره صبر کنید، بلکه می‌خواهید نتایج میانی را در این بین منتشر کنید. این مفهوم را می‌توان برای موارد استفاده‌ای اجرا کرد که در آن‌ها ارائه سریع نتایج در ابتدا و سپس اصلاح آن‌ها در مراحل بعدی ارزشمند است. تصور کنید که وضعیت میانی را در ۲۵٪، ۵۰٪، و ۷۵٪ تکمیل ارسال صادر می‌کنید.
- ترتیب : رویدادها لزوماً به ترتیبی که تولید شده‌اند به سیستم نمی‌رسند. به‌ویژه برای موارد استفاده‌ای که شامل ارتباط ازطریق شبکه‌های تلفن همراه است، که باعث تأخیر و پیچیدگی مسیرهای مسیریابی می‌شود. باید از تفاوت بین «زمان رویداد» (زمانی که رویداد واقعاً اتفاق افتاده است) و «زمان پردازش» (زمانی که رویداد به سیستم رسیده است) آگاه باشید و رویدادها را براساس آن مدیریت کنید. به‌طور کلی، می‌خواهید رویدادها را براساس «زمان رویداد» پردازش کنید.
- تحویل پیام - حداقل یک‌بار درمقابل دقیقاً یک‌بار: پلتفرم‌های رویداد مختلف پشتیبانی متفاوتی از این موارد دارند. بسته به مورد استفاده‌تان، باید راهبردهای تکرار یا حذف موارد تکراری را درنظر بگیرید.
- کامل بودن : درست مانند تغییر ترتیب، احتمال ازدست رفتن پیام‌ها وجود دارد. این امر می‌تواند به‌دلیل خاموش شدن برنامه و دستگاه به‌دلیل عمر باتری دستگاه، آسیب ناخواسته به تلفن، قطع شدن اتصال در تونل، یا پیامی باشد که دریافت شده اما فقط خارج از پنجره قابل‌قبول بوده است. ناقص بودن چگونه بر نتایج شما تأثیر می‌گذارد؟
این فهرست کامل نیست بلکه مقدمه‌ای است. در اینجا چند مطلب بسیار توصیه‌شده آورده شده است که می‌تواند به شما کمک کند درک خود را از هرکدام عمیق‌تر کنید.
همیاران
Google این سند را نگهداری می‌کند. همیاران زیر در ابتدا آن را نوشته‌اند.
نویسندگان اصلی:
- مری پیشنی | مدیر محصول، پلاتفرم Google Maps
- اتل بائو| مهندس نرم‌افزار، پلاتفرم Google Maps
- مهند المسکی | مهندس نرم‌افزار، پلاتفرم Google Maps
- نائویا موریتانی | مهندس راه‌حل‌ها، پلاتفرم Google Maps