چگونه هزینه API Google Maps خود را 94٪ کاهش دادیم .

چگونه هزینه API Google Maps خود را 94٪ کاهش دادیم .

ما به عنوان یک شریک رفت و آمد بسیار قابل اعتماد برای مشتریان خود ، در Cityflo از دقت بالا و پیش بینی پذیری سیستم ردیابی خودرو استفاده می کنیم. نمایش زمان ورود دقیق به کاربران ما ، سهم بزرگی در تجربه ای است که کاربران ما از ما انتظار دارند.

مشکل

ما برای محاسبه زمان سفر بین دو مکان از API مسیرهای پیشرفته Google استفاده می کنیم. Google با توجه به دقت داده های ترافیک در زمان واقعی ، از API برای محاسبه ETA (زمان پیش بینی شده برای رسیدن) به طور جداگانه برای هر وسیله نقلیه در هر یک از ایستگاه های انتخابی خود با مکالمه جداگانه API در هر زمان ثبت نام محل توقف استفاده می کنیم . تا چند ماه پیش ، این API رایگان برای استفاده بود.

پس از تغییر در ساختار قیمت گذاری آنها ، صرفاً برای نشان دادن ETA به کاربران ، هزینه ای در حدود 960 دلار در روز برای ما داشت. ( فرض بر این است که 150 اتوبوس با میانگین 8 وانت متوقف می شود که بیش از 20 دقیقه برای هر اتوبوس مسدود می شود. این تقریباً 96000 تماس API است. Google Directions API برای هر 1000 تماس API 10 دلار هزینه دارد )

این بدیهی بود که یک شروع جدید برای ما گزینه مقتضی نبود. ما می توانستیم با کاهش نرخ تجدید اطلاعات ترافیک ، آن را به حاشیه پایین بیاوریم ، اما این امر به قیمت دقت زمان رسیدن به دست می آمد و ترافیک دیر هنگام در سیستم ما منعکس می شد که تجربه قابل قبولی نبود.

ما برخی از گزینه های منبع باز مانند نقشه Open Street را اکتشاف کردیم اما این کار نتوانست آنچه را Google انجام می دهد باشد. ما تصمیم گرفتیم که در عوض با پلتفرم Google Maps سازگار شویم و روش خود را دوباره مهندسی کنیم.

راه حل ما

برخلاف کابین ها ، اتوبوس های ما از مسیرهای ثابت پیروی می کنند و توقف در یک منطقه توسط چندین اتوبوس در ناوگان پوشانده می شود. ما الگوی حرکت وسایل نقلیه خود را مشخص کردیم. . این الگوی به ما این امکان را می دهد تا زمان سفر را بین ایستگاه های مجاور محاسبه کنیم ، صرف نظر از اینکه کدام اتوبوس در سفر بود. این طراحی مسیر در اصل به ما کمک کرد تا به روزرسانی های محل اتوبوس و محاسبه زمان سفر را برای هر اتوبوس از هم جدا کنیم ، در نتیجه محاسبات زائد را کاهش می دهیم .

به عنوان مثال ، شبکه متوقف شده را مانند تصویر بالا تصور کنید.

در اینجا ، جفت توقفهای مجاور می توانند (A, B), (B, C), (D, C), (C, F) , (E, F) باشند. با محاسبه زمان سفر بین توقفهای مجاور ، ما می توانیم داده های یکسانی را برای کلیه وسایل نقلیه اعمال کنیم. اگر اتوبوس در ایستگاه A باشد که به توقف F نیز می رود ، می توانید با جمع شدن زمان سفر  (A, B), (B, C) , (C, F)زمان رسیدن در Stop F محاسبه شود.

t(A,F)=t(A,B)+t(B,C)+t(C,F)

ناگفته نماند که هیچ گلوله نقره ای وجود ندارد.

در اینجا چیزی اتفاق می افتد که اتوبوس در جایی بین Stop A و Stop B قرار دارد ، چگونه ETA آن را در Stop F محاسبه کنیم؟

ما تصمیم گرفتیم این مسئله را با استفاده از درون یابی خطی حل کنیم.

اگر بتوانیم موقعیت نسبی یک اتوبوس بین دو توقف را مشخص کنیم ، می توانیم زمان رسیدن را تخمین بزنیم. به عنوان مثال ، اگر اتوبوس از نیمه راه بین دو توقف عبور کرده باشد ، می توان فرض کرد که برای رسیدن به انتهای دیگر ، نیمی دیگر از زمان سفر را بین آن دو ایستگاه طول می کشد.

Directions API یک polyline – مجموعه ای از مختصات مکان به ترتیب خاص – بین ایستگاه های مجاور فراهم می کند ، که به ما کمک می کند تا محل اتوبوس را مشخص کنیم. برای بهبود دقت در حین مداخله ، این پلی اتیلن ها تنظیم می شوند تا همگن تر شوند. به عنوان مثال ، پلی اتیلن در جاده های مستقیم پراکنده تر و برعکس است. بنابراین ، ما برای بهبود صحت اطلاعات حداکثر 20 متر بین دو مختصات مکان اطمینان می دهیم.

اگر محل توقف و حرکت اتوبوس حتی کمی پیچیده باشد ، مشخص شدن محل اتوبوس در پلی لاین می تواند یک مشکل پیچیده باشد. به عنوان مثال ، اگر اتوبوس هنگام مسافرت در طرف مقابل جاده ، مکانی را در یک ایستگاه ثبت کند ، سیستم خراب می شود. با این حال ، این داستان برای یک پست وبلاگ جداگانه است.

نتیجه

این رویکرد باعث شد تا API از تعداد وسایل نقلیه مستقل باشد و فقط به ایستگاه ما بستگی داشته باشد ، که به ما کمک کرد بدون هیچ هزینه اضافی ناوگان خود را افزایش دهیم. با این وجود ، هزینه در اینجا به تعداد توقف در شبکه بستگی دارد. پس از تکرارهای متعدد و تنظیم متناسب با مورد استفاده ما ، حداقل 94٪ کاهش در هزینه ما را برای Google Directions API مشاهده کردیم.

قدم بعدی چیست؟

ما توانستیم به یک سیستم توانمند و قابل استفاده برسیم ، اما هنوز کارهای بیشتری باید انجام شود. ما می توانیم با تغییر روند تازه سازی جفت های توقف متفاوتی ، با مشاهده روند در زمان سفر بین آنها ، آن را بهینه کنیم. اگر تغییر زمان سفر بین دو توقف کم باشد ، می توانیم نرخ تجدید را کاهش دهیم و برعکس.

این یک مشکل بسیار جالب برای کار گروه محصولات و مهندسی ما بود. این به ما کمک می کند ضمن اینکه امکان نوآوری مداوم را فراهم می کنیم ، یک تجربه با کیفیت بالا Cityflo را حفظ کنیم.