Membuat peristiwa yang mendekati real-time dengan Fleet Engine dan Solusi Referensi Peristiwa Fleet

Sinyal mendekati real-time dari fleet yang beroperasi di lapangan berguna untuk bisnis dalam sejumlah hal. Misalnya, bisnis dapat menggunakan URL ini untuk:

  • Memantau performa fleet-nya dan mengidentifikasi potensi masalah sejak awal
  • Meningkatkan layanan pelanggan dengan memberikan PWT dan informasi pelacakan yang akurat
  • Mengurangi biaya dengan mengidentifikasi dan mengatasi inefisiensi
  • Meningkatkan keselamatan dengan memantau perilaku pengemudi dan mengidentifikasi potensi bahaya
  • Optimalkan rute dan jadwal pengemudi untuk meningkatkan efisiensi
  • Patuhi peraturan dengan melacak lokasi kendaraan dan jam layanan

Dokumen ini menggambarkan cara developer mengubah sinyal dari "Layanan Mobility" Google Maps Platform ("Last Mile Fleet Solution" (LMFS) atau "Solusi Perjalanan dan Pengiriman On-demand" (ODRD) menjadi peristiwa kustom yang dapat ditindaklanjuti. Konsep utama dan keputusan desain Solusi Referensi Peristiwa Perangkat yang tersedia di GitHub juga dibahas.

Dokumen ini relevan dengan:

  • Arsitek yang memahami "Layanan mobilitas" Google Maps Platform dan salah satu komponen intinya "Fleet Engine". Bagi mereka yang baru mengenal "Layanan mobilitas", sebaiknya pahami Solusi Armada Kilometer Terakhir dan/atau Solusi Perjalanan dan Pengiriman On-demand, bergantung pada kebutuhan Anda.
  • Arsitek yang familier dengan Google Cloud. Bagi pengguna yang baru menggunakan Google Cloud, Membangun pipeline data streaming di Google Cloud adalah bacaan yang direkomendasikan.
  • Jika Anda menargetkan lingkungan atau stack software lain, berfokuslah untuk memahami poin integrasi dan pertimbangan utama Fleet Engine, yang seharusnya tetap berlaku.
  • Orang yang memiliki kepentingan umum untuk mempelajari cara membuat dan memanfaatkan peristiwa dari fleet.

Pada akhir dokumen ini, Anda akan memiliki pemahaman dasar tentang elemen utama dan pertimbangan sistem streaming, serta elemen penyusun dari Google Maps Platform dan Google Cloud yang membentuk Solusi Referensi Peristiwa Armada.

Ringkasan Solusi Referensi Peristiwa Fleet

Solusi Referensi Peristiwa Fleet adalah solusi open source yang memungkinkan pelanggan dan partner Mobilitas menghasilkan peristiwa utama selain komponen Fleet Engine dan Google Cloud. Saat ini, solusi referensi tersebut mendukung pelanggan yang menggunakan Solusi Armada Kilometer Terakhir dengan dukungan untuk Perjalanan dan Pengiriman On-demand yang akan datang.

Solusi ini otomatis menghasilkan peristiwa berdasarkan perubahan pada data tertentu yang terkait dengan tugas atau perjalanan. Anda dapat menggunakan peristiwa tersebut untuk mengirim notifikasi seperti berikut kepada pemangku kepentingan atau memicu tindakan lain untuk fleet Anda.

  • Perubahan PWT untuk kedatangan tugas
  • Perubahan PWT relatif untuk kedatangan tugas
  • Waktu yang tersisa hingga tugas tiba
  • Jarak yang tersisa hingga kedatangan tugas
  • Perubahan status TaskOutcome

Setiap komponen solusi referensi dapat disesuaikan dengan kebutuhan bisnis Anda.

Unsur-unsur Logika

Diagram : Diagram berikut menunjukkan elemen penyusun tingkat tinggi yang membentuk solusi referensi Peristiwa Fleet

Ringkasan Peristiwa Fleet dan elemen penyusun yang logis

Solusi referensi berisi komponen berikut:

  • Sumber Peristiwa: Tempat asal aliran peristiwa asli. "Last Mile Fleet Solutions" atau "On-demand Rides and Deliveries Solutions" memiliki integrasi dengan Cloud Logging yang membantu mengubah log panggilan RPC Fleet Engine menjadi aliran peristiwa yang tersedia bagi developer. Ini adalah sumber inti yang akan digunakan.
  • Pemrosesan: Log panggilan RPC mentah dikonversi menjadi peristiwa perubahan status dalam blok ini yang dihitung melalui aliran peristiwa log. Untuk mendeteksi perubahan tersebut, komponen ini memerlukan penyimpanan status sehingga peristiwa masuk baru dapat dibandingkan dengan peristiwa sebelumnya untuk mendeteksi perubahan. Peristiwa mungkin tidak selalu menyertakan semua informasi yang diinginkan. Dalam kasus seperti itu, blok ini mungkin membuat panggilan ke backend sesuai kebutuhan.
    • Penyimpanan status: Beberapa framework pemrosesan menyediakan persistensi data perantara sendiri. Namun, jika tidak, untuk menyimpan status secara mandiri, karena harus unik untuk jenis kendaraan dan peristiwa, layanan persistensi data jenis K-V cocok.
  • Sink (Peristiwa Kustom): Perubahan status yang terdeteksi harus tersedia untuk aplikasi atau layanan apa pun yang dapat memanfaatkan perubahan status tersebut. Oleh karena itu, memublikasikan peristiwa kustom ini ke sistem penayangan peristiwa untuk penggunaan downstream adalah pilihan yang wajar.
  • Layanan downstream: Kode yang menggunakan peristiwa yang dihasilkan dan mengambil tindakan yang unik untuk kasus penggunaan Anda.

Pilihan layanan

Sehubungan dengan penerapan solusi referensi untuk "Last Milet Fleet Solution" atau "On-demand Rides and Deliveries Solution" (akan hadir pada akhir Kuartal 3 2023), pemilihan teknologi untuk "Sumber" dan "Sink '' sangatlah mudah. Di sisi lain, "Pemrosesan" memiliki berbagai opsi. Solusi referensi telah memilih layanan Google berikut.

Diagram : Diagram berikut menunjukkan layanan Google Cloud untuk mengimplementasikan solusi referensi

Elemen penyusun solusi referensi Peristiwa Fleet

Tata letak Project Cloud

Sebaiknya Anda menggunakan deployment multi-project secara default. Hal ini dilakukan agar konsumsi Google Maps Platform dan Google Cloud dapat dipisahkan dengan rapi dan terikat dengan konfigurasi penagihan pilihan Anda.

Sumber Peristiwa

"Last Milet Fleet Solutions" dan "On-demand Rides and Deliveries Solution" menulis payload respons dan permintaan API ke Cloud Logging. Cloud Logging mengirimkan log ke satu atau beberapa layanan pilihan. Memilih rute ke Cloud Pub/Sub di sini adalah pilihan yang tepat dan memungkinkan konversi log menjadi aliran data peristiwa tanpa coding.

Sink

Di Google Cloud, Cloud Pub/Sub adalah sistem pengiriman pesan pilihan yang mendekati real-time. Sama seperti cara peristiwa dari sumber dikirim ke Pub/Sub, peristiwa kustom juga dipublikasikan ke Pub/Sub untuk konsumsi downstream.

Memproses

Komponen berikut berperan dalam pemrosesan peristiwa. Seperti elemen penyusun lainnya, komponen pemrosesan sepenuhnya berfungsi tanpa server dan dapat diskalakan dengan baik naik maupun turun.

  • Cloud Functions sebagai platform komputasi untuk rilis awal (*)
    • Serverless, tingkatkan dan turunkan skala dengan kontrol penskalaan untuk mengelola biaya
    • Java sebagai bahasa pemrograman mengingat ketersediaan library klien untuk API terkait Fleet Engine yang berkontribusi terhadap kemudahan implementasi
  • Cloud Firestore sebagai penyimpanan status
    • Penyimpanan Key-Value Serverless
  • Cloud Pub/Sub sebagai titik integrasi dengan komponen upstream dan downstream
    • Integrasi hampir secara real-time yang dikaitkan secara longgar

Fungsi ini dapat digunakan apa adanya dengan setelan default, tetapi juga dapat dikonfigurasi ulang. Parameter konfigurasi ditetapkan melalui skrip deployment dan didokumentasikan secara mendetail dalam README modul terraform yang sesuai.

*Catatan: Solusi referensi ini berencana untuk merilis implementasi alternatif yang dapat membantu memenuhi berbagai persyaratan.

Deployment

Agar proses deployment solusi referensi dapat diulang, dapat disesuaikan, kode sumber dapat dikontrol, dan aman, Terraform dipilih sebagai alat otomatisasi. Terraform adalah alat IaC (Infrastructure as Code) yang diadopsi secara luas dengan dukungan yang beragam untuk Google Cloud.

Modul Terraform

Alih-alih membuat satu modul deployment solusi referensi monolitik yang besar, blok otomatisasi yang dapat digunakan kembali diimplementasikan sebagai modul Terraform yang dapat digunakan secara independen. Modul menyediakan berbagai variabel yang dapat dikonfigurasi, yang sebagian besar memiliki nilai default sehingga Anda dapat memulai dengan cepat tetapi juga memiliki fleksibilitas untuk melakukan penyesuaian berdasarkan kebutuhan dan preferensi.

Modul yang disertakan dalam solusi referensi:

  • Konfigurasi logging Fleet Engine: Mengotomatiskan konfigurasi terkait Cloud Logging untuk digunakan dengan Fleet Engine. Dalam solusi referensi, solusi ini digunakan untuk merutekan log terkait Fleet Engine ke topik Pub/Sub yang ditentukan.
  • Deployment fungsi cloud Fleet Events: Berisi deployment kode fungsi contoh dan juga menangani otomatisasi setelan izin yang diperlukan untuk integrasi lintas project yang aman.
  • Deployment solusi referensi menyeluruh: Memanggil dua modul sebelumnya dan menggabungkan seluruh solusi.

Keamanan

IAM diadopsi untuk menerapkan prinsip hak istimewa terendah bersama dengan praktik terbaik keamanan Google Cloud seperti peniruan Akun Layanan. Baca artikel berikut untuk lebih memahami apa saja yang ditawarkan Google Cloud untuk memberi Anda kontrol lebih besar atas keamanan.

Tindakan berikutnya

Anda kini siap untuk mengakses dan mempelajari lebih lanjut Solusi Referensi Peristiwa Perangkat. Buka GitHub untuk memulai.

Lampiran

Penuhi persyaratan Anda

Sebaiknya Anda memenuhi persyaratan di awal proses.

Pertama, catat detail mengapa Anda tertarik atau perlu menggunakan peristiwa yang mendekati realtime. Berikut beberapa pertanyaan untuk membantu mengkristalkan kebutuhan Anda.

  • Informasi apa yang diperlukan agar aliran acara bermanfaat?
    • Dapatkah hasilnya diambil sepenuhnya dari data yang diambil atau dihasilkan di layanan Google? Atau, apakah diperlukan pengayaan data dengan sistem eksternal terintegrasi? Jika ya, sistem apa yang dimaksud dan antarmuka integrasi apa yang ditawarkannya?
    • Apa saja metrik yang ingin Anda ukur sebagai sebuah bisnis? Bagaimana mereka didefinisikan?
    • Jika Anda perlu menghitung metrik di seluruh peristiwa, agregasi seperti apa yang diperlukan? Cobalah untuk menyusun langkah-langkah yang logis. (misalnya, Bandingkan ETA/ATA dengan SLO di seluruh subsek fleet selama jam sibuk untuk menghitung performa berdasarkan batasan resource.)
  • Mengapa Anda tertarik dengan model berbasis peristiwa atau bukan batch? Apakah ini untuk latensi rendah (waktu tindakan) atau untuk integrasi yang dikaitkan secara longgar (kegesitan)?
    • Jika untuk latensi rendah, tentukan "rendah". Menit? Detik? Sub-detik? Dan latensi apa?
  • Apakah Anda sudah berinvestasi dalam technology stack dan keterampilan terkait sebagai sebuah tim? Jika ya, apa itu dan poin integrasi apa yang diberikannya?
    • Apakah ada persyaratan yang tidak dapat dipenuhi atau mungkin sulit dipenuhi oleh sistem Anda saat memproses peristiwa yang berasal dari fleet Anda?

Prinsip-prinsip desain

Akan sangat berguna untuk memiliki beberapa proses pemikiran yang harus diikuti. Hal ini membantu membuat keputusan desain yang konsisten, terutama jika Anda memiliki beragam opsi untuk dipilih.

  • Tetapkan penyimpanan default ke opsi yang lebih sederhana.
  • Setel default ke waktu pemerolehan manfaat yang lebih singkat. Lebih sedikit kode, kurva belajar lebih rendah.
  • Untuk latensi dan performa, upayakan untuk memenuhi standar yang telah Anda tetapkan, bukan pengoptimalan maksimum. Selain itu, hindari pengoptimalan ekstrem karena sering menyebabkan penambahan kompleksitas.
  • Hal yang sama berlaku untuk biaya. Jaga agar biaya tetap wajar. Anda mungkin belum berada di negara bagian bahwa Anda dapat berkomitmen untuk menggunakan layanan bernilai tinggi tetapi relatif lebih mahal.
  • Pada fase eksperimental, penurunan skala bisa sama pentingnya dengan peningkatan skala. Pertimbangkan platform yang memberikan fleksibilitas untuk meningkatkan skala dengan batas dan juga menurunkan skala (idealnya ke nol) sehingga Anda tidak mengeluarkan biaya saat tidak melakukan apa pun. Performa tinggi dengan infrastruktur yang selalu aktif dapat dipertimbangkan di kemudian hari dalam perjalanan, ketika Anda yakin akan kebutuhannya.
  • Amati dan ukur sehingga Anda nanti dapat mengidentifikasi di mana Anda harus mengerjakan lebih lanjut.
  • Buat layanan tetap dikaitkan secara longgar. Hal ini mempermudah pengguna untuk menukar sepotong demi sepotong.
  • Yang tidak kalah pentingnya, keamanan tidak boleh longgar. Sebagai layanan yang berjalan di lingkungan cloud publik, tidak boleh ada pintu yang tidak aman ke sistem.

Konsep streaming

Jika Anda relatif baru mengenal peristiwa berbasis peristiwa atau streaming, ada beberapa konsep utama yang perlu diketahui, yang beberapa di antaranya mungkin sangat berbeda dengan batch processing.

  • Skala : Berbeda dengan batch processing, di mana Anda biasanya memiliki gambaran yang bagus mengenai jumlah data yang akan diproses, di streaming Anda tidak bisa melakukannya. Kemacetan lalu lintas di kota secara tiba-tiba dapat menimbulkan banyak peristiwa dari area tertentu, dan Anda masih harus dapat memprosesnya.
  • Windowing : Daripada memproses peristiwa satu per satu, sering kali Anda ingin mengelompokkan peristiwa pada linimasa ke dalam "jendela" yang lebih kecil sebagai unit untuk komputasi. Ada berbagai strategi windowing seperti "jendela tetap (mis. setiap hari kalender)", "jendela geser (5 menit terakhir)", "jendela sesi (selama perjalanan ini)", yang harus Anda pilih. Semakin lama periodenya, semakin lama penundaan dalam memberikan hasil. Pilih model dan konfigurasi yang tepat dan sesuai dengan kebutuhan Anda.
  • Pemicuan : Ada kasus yang Anda tidak punya pilihan lain selain memiliki periode yang relatif lebih lama. Namun, Anda tidak ingin menunggu akhir jendela untuk menghasilkan peristiwa, melainkan menampilkan hasil menengah di antaranya. Konsep ini dapat diterapkan untuk kasus penggunaan ketika menampilkan hasil cepat terlebih dahulu, lalu memperbaikinya nanti. Bayangkan memunculkan status menengah pada penyelesaian pengiriman 25%, 50%, dan 75%.
  • Pengurutan : Peristiwa belum tentu mencapai sistem sesuai urutan pembuatannya. Khususnya untuk kasus penggunaan dengan keterlibatan komunikasi melalui jaringan seluler yang menambahkan penundaan dan jalur perutean yang kompleks. Anda harus mengetahui perbedaan antara "waktu peristiwa" (ketika peristiwa itu benar-benar terjadi) dan "waktu proses" (saat peristiwa mencapai sistem) dan menangani peristiwa sebagaimana mestinya. Secara umum, sebaiknya Anda memproses peristiwa berdasarkan "waktu peristiwa".
  • Pengiriman pesan - Minimal satu kali versus Tepat satu kali: Platform peristiwa yang berbeda memiliki dukungan yang berbeda pula. Bergantung pada kasus penggunaan, Anda perlu mempertimbangkan strategi percobaan ulang atau penghapusan duplikat.
  • Kelengkapan : Sama seperti perubahan urutan, ada kemungkinan pesan hilang. Hal ini dapat disebabkan oleh penonaktifan aplikasi dan perangkat karena masa pakai baterai perangkat, kerusakan yang tidak disengaja pada ponsel, kehilangan konektivitas saat berada dalam tunnel, atau pesan yang diterima tetapi hanya di luar jendela yang dapat diterima. Bagaimana ketidaklengkapan memengaruhi hasil Anda?

Ini bukanlah daftar lengkap, melainkan pendahuluan. Berikut adalah beberapa bacaan yang sangat direkomendasikan untuk membantu Anda lebih memahami masing-masing topik.

Kontributor

Google menyimpan dokumen ini. Awalnya, kontributor berikut ini ditulis.

Penulis utama: