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