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

Sinyal hampir real-time dari armada yang beroperasi di lapangan berguna bagi bisnis dalam sejumlah cara. Misalnya, bisnis dapat menggunakannya untuk:

  • Memantau performa armada mereka dan mengidentifikasi potensi masalah sejak dini
  • Meningkatkan kualitas layanan pelanggan dengan memberikan info perkiraan waktu kedatangan dan informasi pelacakan yang akurat
  • Mengurangi biaya dengan mengidentifikasi dan mengatasi inefisiensi
  • Meningkatkan keselamatan dengan memantau perilaku pengemudi dan mengidentifikasi potensi bahaya
  • Mengoptimalkan rute dan jadwal pengemudi untuk meningkatkan efisiensi
  • Mematuhi peraturan dengan melacak lokasi kendaraan dan jam layanan

Dokumen ini mengilustrasikan cara developer mengubah sinyal dari "Layanan mobilitas" Google Maps Platform ("Last Mile Fleet Solution" (LMFS) atau "On-demand Rides and Deliveries Solution" (ODRD) menjadi peristiwa kustom yang dapat ditindaklanjuti. Konsep utama dan keputusan desain Solusi Referensi Peristiwa Fleet 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 Anda yang baru menggunakan "Layanan mobilitas", sebaiknya pelajari Solusi Fleet Kilometer Terakhir dan/atau Solusi Perjalanan dan Pengiriman Sesuai Permintaan, bergantung pada kebutuhan Anda.
  • Arsitek yang memahami Google Cloud. Bagi pengguna baru Google Cloud, Membangun pipeline data streaming di Google Cloud adalah bacaan awal yang direkomendasikan.
  • Jika Anda menargetkan lingkungan atau stack software lain, fokuslah untuk memahami titik integrasi dan pertimbangan utama Fleet Engine, yang seharusnya masih berlaku.
  • Mereka yang memiliki minat umum dalam mempelajari cara peristiwa dari armada dapat dibuat dan dimanfaatkan.

Di akhir dokumen ini, Anda akan memiliki pemahaman dasar tentang elemen dan pertimbangan utama sistem streaming, beserta blok 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 membuat peristiwa utama di atas komponen Fleet Engine dan Google Cloud. Saat ini, solusi referensi mendukung pelanggan yang menggunakan Solusi Fleet Kilometer Terakhir dengan dukungan untuk Layanan Perjalanan dan Pengiriman Sesuai Permintaan yang akan segera hadir.

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

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

Setiap komponen solusi referensi dapat disesuaikan agar sesuai dengan kebutuhan bisnis Anda.

Elemen penyusun logis

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

Ringkasan dan blok penyusun logis Peristiwa Fleet

Solusi referensi berisi komponen berikut:

  • Sumber Peristiwa: Tempat asal aliran peristiwa asli. Baik "Solusi Fleet Kilometer Terakhir" atau "Solusi Perjalanan dan Pengiriman Sesuai Permintaan" memiliki integrasi dengan Cloud Logging yang membantu mengubah log panggilan RPC Fleet Engine menjadi aliran peristiwa yang tersedia bagi developer. Ini adalah sumber utama yang harus digunakan.
  • Pemrosesan: Log panggilan RPC mentah akan dikonversi menjadi peristiwa perubahan status dalam blok ini yang menghitung 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. Acara mungkin tidak selalu mencakup semua informasi yang diinginkan. Dalam kasus tersebut, blok ini dapat melakukan panggilan penelusuran ke backend sesuai kebutuhan.
    • Penyimpanan status: Beberapa framework pemrosesan menyediakan data perantara yang persisten dengan sendirinya. Namun, jika tidak, untuk menyimpan status sendiri, karena status ini harus unik untuk jenis peristiwa dan kendaraan, layanan persistensi data jenis K-V akan cocok.
  • Sink (Peristiwa Kustom): Perubahan status yang terdeteksi harus tersedia untuk aplikasi atau layanan apa pun yang dapat memanfaatkannya. Oleh karena itu, peristiwa kustom ini adalah pilihan alami untuk dipublikasikan ke sistem pengiriman peristiwa untuk penggunaan di hilir.
  • Layanan hilir: Kode yang menggunakan peristiwa yang dihasilkan dan melakukan tindakan unik untuk kasus penggunaan Anda.

Pilihan layanan

Dalam hal penerapan solusi referensi untuk "Last Mile Fleet Solution" atau "On-demand Rides and Deliveries Solution" (tersedia pada akhir Kuartal 3 2023), pemilihan teknologi untuk "Sumber" dan "Tujuan" cukup mudah. Di sisi lain, "Pemrosesan" memiliki berbagai opsi. Solusi referensi telah memilih layanan Google berikut.

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

Blok penyusun solusi referensi Peristiwa Fleet

Tata letak Project Cloud

Sebaiknya Anda menggunakan deployment multi-project secara default. Hal ini dilakukan agar penggunaan Google Maps Platform dan Google Cloud dapat dipisahkan dengan jelas dan dikaitkan dengan pengaturan penagihan pilihan Anda.

Sumber Peristiwa

"Last Mile Fleet Solution" dan "On-demand Rides and Deliveries Solution" menulis payload permintaan dan respons API ke Cloud Logging. Cloud Logging mengirimkan log ke satu atau beberapa layanan pilihan. Merutekan ke Cloud Pub/Sub adalah pilihan yang tepat di sini dan memungkinkan untuk mengonversi log menjadi aliran peristiwa tanpa pengodean.

Wastafel

Di Google Cloud, Cloud Pub/Sub adalah sistem pengiriman pesan hampir real-time yang dipilih. Sama seperti cara peristiwa dari sumber dikirim ke Pub/Sub, peristiwa kustom juga dipublikasikan ke Pub/Sub untuk penggunaan di hilir.

Memproses

Komponen berikut berperan dalam pemrosesan peristiwa. Seperti blok penyusun lainnya, komponen pemrosesan sepenuhnya tanpa server dan dapat menskalakan dengan baik ke atas dan ke bawah.

  • Cloud Functions sebagai platform komputasi untuk rilis awal (*)
    • Serverless, dapat diskalakan naik dan turun dengan kontrol penskalaan untuk mengelola biaya
    • Java sebagai bahasa pemrograman mengingat ketersediaan library klien untuk API terkait Fleet Engine yang mempermudah penerapan
  • Cloud Firestore sebagai penyimpanan status
    • Penyimpanan Nilai Kunci Serverless
  • Cloud Pub/Sub sebagai titik integrasi dengan komponen upstream dan downstream
    • Integrasi hampir real-time yang terhubung secara longgar

Fungsi 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 merilis implementasi alternatif yang dapat membantu memenuhi berbagai persyaratan.

Deployment

Untuk membuat proses deployment solusi referensi dapat diulang, dapat disesuaikan, dapat dikontrol kode sumbernya, dan aman, Terraform dipilih sebagai alat otomatisasi. Terraform adalah alat IaC (Infrastructure as Code) yang banyak digunakan dengan dukungan yang kaya untuk Google Cloud.

Modul Terraform

Daripada 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 menyesuaikan berdasarkan kebutuhan dan preferensi Anda.

Modul yang disertakan dalam solusi referensi:

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

Keamanan

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

Tindakan berikutnya

Sekarang Anda siap mengakses dan menjelajahi lebih lanjut Solusi Referensi Peristiwa Armada. Buka GitHub untuk memulai.

Lampiran

Kumpulkan persyaratan Anda

Sebaiknya kumpulkan persyaratan Anda lebih awal dalam prosesnya.

Pertama, catat detail alasan Anda tertarik atau perlu menggunakan peristiwa hampir real-time. Berikut beberapa pertanyaan untuk membantu Anda memantapkan kebutuhan Anda.

  • Informasi apa yang diperlukan agar aliran peristiwa dapat berguna?
    • Dapatkah hasilnya diperoleh hanya dari data yang diambil atau dihasilkan di layanan Google? Atau, apakah pengayaan data dengan sistem eksternal terintegrasi diperlukan? Jika ya, apa saja sistem tersebut dan antarmuka integrasi apa yang ditawarkannya?
    • Metrik apa yang ingin Anda ukur sebagai bisnis? Bagaimana definisi mereka?
    • Jika Anda perlu menghitung metrik di seluruh peristiwa, jenis agregasi apa yang diperlukan? Coba susun langkah-langkah logis. (misalnya, Bandingkan ETA/ATA dengan SLO di seluruh subbagian armada selama jam sibuk untuk menghitung performa dalam batasan resource.)
  • Mengapa Anda tertarik dengan model berbasis peristiwa atau daripada batch? Apakah ini untuk latensi yang lebih rendah (waktu untuk melakukan tindakan) atau untuk integrasi yang tidak terikat secara erat (kelincahan)?
    • Jika untuk latensi rendah, tentukan "low". Menit? Detik? Kurang dari satu detik? Dan berapa latensinya?
  • Apakah Anda sudah berinvestasi dalam teknologi dan keterampilan terkait sebagai tim? Jika ya, apa itu dan titik integrasi apa yang disediakan?
    • Apakah ada persyaratan yang tidak dapat dipenuhi oleh sistem Anda saat ini atau mungkin mengalami kesulitan saat memproses peristiwa yang berasal dari armada Anda?

Prinsip-prinsip desain

Selalu berguna untuk memiliki beberapa proses pemikiran yang harus diikuti. Hal ini membantu membuat keputusan desain yang konsisten, terutama saat Anda memiliki berbagai opsi untuk dipilih.

  • Gunakan opsi yang lebih sederhana secara default.
  • Setelan default untuk waktu pemerolehan manfaat yang lebih singkat. Lebih sedikit kode, kurva pembelajaran lebih rendah.
  • Untuk latensi dan performa, usahakan untuk memenuhi standar yang telah Anda tetapkan, bukan pengoptimalan maksimum. Hindari juga pengoptimalan ekstrem karena sering kali menyebabkan penambahan kompleksitas.
  • Hal yang sama berlaku untuk biaya. Jaga agar biaya tetap wajar. Anda mungkin belum berada dalam kondisi yang memungkinkan Anda berkomitmen untuk menggunakan layanan bernilai tinggi, tetapi relatif lebih mahal.
  • Pada fase eksperimental, penurunan skala dapat sama pentingnya dengan peningkatan skala. Pertimbangkan platform yang memberikan fleksibilitas untuk melakukan penskalaan dengan batas atas dan juga penskalaan ke bawah (idealnya hingga nol) sehingga Anda tidak mengeluarkan biaya saat tidak melakukan apa pun. Performa tinggi dengan infrastruktur yang selalu aktif dapat dipertimbangkan nanti dalam perjalanan, saat Anda yakin dengan kebutuhannya.
  • Amati dan ukur sehingga Anda dapat mengidentifikasi bagian yang perlu ditingkatkan.
  • Memastikan layanan dikaitkan secara longgar. Hal ini mempermudah penukaran bagian demi bagian di kemudian hari.
  • Terakhir, 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 dalam pemrosesan berbasis peristiwa atau streaming, ada konsep utama yang perlu Anda ketahui, beberapa di antaranya bisa sangat berbeda dari pemrosesan batch.

  • Skala : Berbeda dengan pemrosesan batch, di mana Anda biasanya memiliki gambaran yang baik tentang jumlah data yang akan diproses, dalam streaming Anda tidak dapat melakukannya. Kemacetan lalu lintas di kota dapat menghasilkan banyak peristiwa secara tiba-tiba dari area tertentu, dan Anda tetap harus dapat memprosesnya.
  • Pengelompokan : Daripada memproses peristiwa satu per satu, sering kali Anda ingin mengelompokkan peristiwa dalam linimasa ke dalam "jendela" yang lebih kecil sebagai unit untuk komputasi. Ada berbagai strategi penentuan jendela seperti "jendela tetap (mis. setiap hari kalender)", "jendela geser (5 menit terakhir)", "jendela sesi (selama perjalanan ini)", yang harus Anda pilih. Semakin panjang periode, semakin lama penundaan dalam menghasilkan hasil. Pilih model dan konfigurasi yang tepat yang memenuhi persyaratan Anda.
  • Pemicuan : Ada kasus di mana Anda tidak punya pilihan lain selain memiliki jangka waktu yang relatif lebih lama. Namun, Anda tidak ingin menunggu hingga akhir jendela untuk menghasilkan peristiwa, tetapi lebih baik memancarkan hasil menengah di antaranya. Konsep ini dapat diterapkan untuk kasus penggunaan yang menghargai pengembalian hasil cepat terlebih dahulu, lalu mengoreksinya nanti. Bayangkan memancarkan status perantara pada penyelesaian pengiriman 25%, 50%, 75%.
  • Pengurutan : Peristiwa tidak selalu mencapai sistem dalam urutan yang sama dengan urutan pembuatannya. Terutama untuk kasus penggunaan yang melibatkan komunikasi melalui jaringan seluler yang menambah penundaan dan jalur pemilihan rute yang kompleks. Anda harus mengetahui perbedaan antara "waktu acara" (saat acara benar-benar berlangsung) dan "waktu pemrosesan" (saat acara mencapai sistem) dan menangani acara dengan tepat. Secara umum, Anda ingin memproses peristiwa berdasarkan "waktu peristiwa".
  • Pengiriman pesan - Minimal satu kali versus Tepat satu kali: Platform peristiwa yang berbeda memiliki dukungan yang berbeda untuk hal ini. Bergantung pada kasus penggunaan, Anda perlu mempertimbangkan strategi percobaan ulang atau penghapusan duplikat.
  • Kelengkapan : Sama seperti perubahan pemesanan, ada kemungkinan pesan akan hilang. Hal ini dapat terjadi karena aplikasi dan perangkat dimatikan karena daya tahan baterai perangkat, kerusakan yang tidak disengaja pada ponsel, hilangnya konektivitas saat berada di dalam terowongan, atau pesan yang diterima tetapi hanya di luar jangka waktu yang dapat diterima. Bagaimana ketidaklengkapan akan memengaruhi hasil Anda?

Ini bukan daftar lengkap, melainkan pengantar. Berikut beberapa bacaan yang sangat direkomendasikan yang dapat membantu Anda memperdalam pemahaman tentang masing-masing fitur.

Kontributor

Google mengelola dokumen ini. Kontributor berikut awalnya menulisnya.

Penulis utama: