Peristiwa real-time Fleet Engine

Sinyal hampir real-time dari armada yang beroperasi di lapangan berguna bagi bisnis dalam beberapa cara. Misalnya, bisnis dapat menggunakan fitur ini untuk:

  • Memantau performa armada dan mengidentifikasi potensi masalah sejak dini
  • Meningkatkan layanan pelanggan dengan memberikan informasi pelacakan dan perkiraan waktu kedatangan (ETA) 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 "Solusi Perjalanan dan Pengiriman On-Demand" (ODRD) menjadi peristiwa kustom yang dapat ditindaklanjuti. Konsep utama dan keputusan desain Solusi Referensi Peristiwa Armada yang tersedia di GitHub juga dibahas.

Dokumen ini relevan untuk:

  • Arsitek yang memahami "Layanan mobilitas" Google Maps Platform dan salah satu komponen utamanya, "Fleet Engine". Bagi yang baru mengenal "Layanan mobilitas", sebaiknya pelajari Solusi Fleet Kilometer Terakhir dan/atau Solusi Pengantaran dan Perjalanan On-Demand, bergantung pada kebutuhan Anda.
  • Arsitek yang memahami Google Cloud. Bagi yang baru mengenal 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.

Setelah membaca dokumen ini, Anda akan memiliki pemahaman dasar tentang elemen dan pertimbangan utama 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 penting di atas komponen Fleet Engine dan Google Cloud. Saat ini, solusi referensi mendukung pelanggan yang menggunakan Solusi Fleet Kilometer Terakhir dengan dukungan untuk Perjalanan dan Pengiriman On-Demand yang akan menyusul.

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 fleet Anda.

  • Perubahan PWT untuk kedatangan tugas
  • Perubahan PWT relatif untuk kedatangan tugas
  • Waktu yang tersisa hingga kedatangan tugas
  • Jarak yang tersisa hingga kedatangan 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 Armada

Ringkasan dan elemen penyusun logis Peristiwa Fleet

Solusi referensi berisi komponen berikut:

  • Sumber Peristiwa: Tempat asal aliran peristiwa asli. "Solusi Fleet Kilometer Terakhir" atau "Solusi Perjalanan dan Pengiriman On-Demand" 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 menghitung aliran peristiwa log. Untuk mendeteksi perubahan tersebut, komponen ini memerlukan penyimpanan status sehingga peristiwa baru yang masuk dapat dibandingkan dengan peristiwa sebelumnya untuk mendeteksi perubahan. Peristiwa mungkin tidak selalu menyertakan semua informasi yang diinginkan. Dalam kasus tersebut, blok ini mungkin melakukan panggilan pencarian 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 kendaraan dan peristiwa, layanan persistensi data jenis K-V adalah pilihan yang tepat.
  • Sink (Peristiwa Kustom): Perubahan status yang terdeteksi harus tersedia untuk aplikasi atau layanan apa pun yang dapat memanfaatkannya. Oleh karena itu, ini adalah pilihan yang tepat untuk memublikasikan peristiwa kustom ini ke sistem pengiriman peristiwa untuk konsumsi downstream.
  • Layanan downstream: Kode yang menggunakan peristiwa yang dihasilkan dan mengambil tindakan unik untuk kasus penggunaan Anda.

Pilihan layanan

Saat menerapkan solusi referensi untuk "Solusi Fleet Kilometer Terakhir" atau "Solusi Perjalanan dan Pengiriman On-Demand" (akan hadir pada akhir Q3 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 gunakan deployment multi-project secara default. Hal ini dilakukan agar konsumsi Google Maps Platform dan Google Cloud dapat dipisahkan dengan jelas dan dikaitkan dengan pengaturan penagihan pilihan Anda.

Sumber Peristiwa

"Solusi Fleet Kilometer Terakhir" dan "Solusi Perjalanan dan Pengiriman On-Demand" menulis payload permintaan dan respons API ke Cloud Logging. Cloud Logging mengirimkan log ke satu atau beberapa layanan pilihan. Perutean ke Cloud Pub/Sub adalah pilihan yang tepat di sini dan memungkinkan konversi log menjadi aliran peristiwa tanpa coding.

Wastafel

Di Google Cloud, Cloud Pub/Sub adalah sistem pengiriman pesan hampir real-time yang menjadi pilihan. 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 serverless dan dapat diskalakan dengan baik, baik naik maupun turun.

  • Cloud Functions sebagai platform komputasi untuk rilis awal (*)
    • Serverless, meningkatkan dan menurunkan skala dengan kontrol penskalaan untuk mengelola biaya
    • Java sebagai bahasa pemrograman mengingat ketersediaan library klien untuk API terkait Fleet Engine yang berkontribusi pada kemudahan implementasi
  • 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 digabungkan 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 merilis implementasi alternatif yang dapat membantu memenuhi berbagai persyaratan.

Deployment

Untuk membuat proses deployment solusi referensi dapat diulang, disesuaikan, 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

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 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, solusi ini digunakan untuk merutekan log terkait Fleet Engine ke topik Pub/Sub yang ditentukan.
  • Deployment cloud function Fleet Events: Berisi deployment kode fungsi contoh dan juga menangani otomatisasi setelan izin yang diperlukan untuk integrasi lintas project yang aman.
  • Deployment solusi referensi keseluruhan: 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 penawaran Google Cloud yang memberi Anda kontrol lebih besar atas keamanan.

Tindakan berikutnya

Sekarang Anda siap mengakses dan mempelajari lebih lanjut Solusi Referensi Peristiwa Fleet. Buka GitHub untuk memulai.

Lampiran

Mengumpulkan persyaratan Anda

Sebaiknya kumpulkan persyaratan Anda di awal proses.

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

  • Informasi apa yang diperlukan agar aliran peristiwa berguna?
    • Dapatkah hasilnya diperoleh murni dari data yang diambil atau dihasilkan di layanan Google? Atau, apakah pengayaan data dengan sistem eksternal terintegrasi diperlukan? Jika ya, apa sistem tersebut dan antarmuka integrasi apa yang ditawarkan?
    • Apa metrik yang ingin Anda ukur sebagai bisnis? Bagaimana cara mendefinisikannya?
    • Jika Anda perlu menghitung metrik di seluruh peristiwa, jenis agregasi apa yang diperlukan? Coba susun langkah-langkah logisnya. (misalnya, Bandingkan ETA/ATA dengan SLO di seluruh subset armada selama jam puncak untuk menghitung performa dalam batasan resource.)
  • Mengapa Anda tertarik dengan model berbasis peristiwa, bukan batch? Apakah ini untuk latensi yang lebih rendah (waktu untuk bertindak) atau untuk integrasi yang digabungkan secara longgar (kelincahan)?
    • Jika untuk latensi rendah, tentukan "low". Menit? Detik? Sub-detik? Dan berapa latensinya?
  • Apakah Anda sudah berinvestasi dalam stack teknologi dan keterampilan terkait sebagai tim? Jika ya, apa itu dan titik integrasi apa yang disediakan?
    • Apakah ada persyaratan yang tidak dapat dipenuhi atau mungkin sulit dipenuhi oleh sistem Anda saat ini saat memproses peristiwa yang berasal dari armada Anda?

Prinsip-prinsip desain

Akan 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.
  • Default-nya adalah 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 menambah kompleksitas.
  • Hal yang sama berlaku untuk biaya. Menjaga biaya tetap wajar. Anda mungkin belum berada dalam kondisi yang dapat berkomitmen untuk menggunakan layanan bernilai tinggi, tetapi relatif lebih mahal.
  • Pada fase eksperimental, memperkecil skala dapat sama pentingnya dengan memperbesar skala. Pertimbangkan platform yang memberikan fleksibilitas untuk meningkatkan skala dengan batas dan juga memperkecil skala (idealnya menjadi nol) sehingga Anda tidak perlu mengeluarkan biaya saat tidak melakukan apa pun. Performa tinggi dengan infrastruktur yang selalu aktif dapat dipertimbangkan nanti dalam prosesnya, saat Anda yakin akan kebutuhannya.
  • Amati dan ukur agar Anda dapat mengidentifikasi bagian mana yang perlu dikerjakan lebih lanjut.
  • Pastikan layanan dikaitkan secara longgar. Hal ini memudahkan untuk menukar 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 streaming atau berbasis peristiwa, ada konsep-konsep penting yang perlu diketahui, beberapa di antaranya bisa sangat berbeda dengan batch processing.

  • Skala : Berbeda dengan pemrosesan batch, yang biasanya memberi Anda 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 masih harus dapat memprosesnya.
  • Windowing : Alih-alih 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 windowing seperti "jendela tetap (misalnya, 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 sesuai dengan kebutuhan Anda.
  • Pemicu : Ada kasus saat Anda tidak memiliki pilihan lain selain memiliki periode yang relatif lebih lama. Namun, Anda tidak ingin menunggu hingga akhir periode untuk menghasilkan peristiwa, melainkan memunculkan hasil perantara di antaranya. Konsep ini dapat diterapkan untuk kasus penggunaan yang mengutamakan hasil cepat terlebih dahulu, lalu mengoreksinya nanti. Bayangkan memunculkan status perantara pada penyelesaian pengiriman 25%, 50%, 75%.
  • Pengurutan : Peristiwa tidak selalu mencapai sistem dalam urutan pembuatannya. Terutama untuk kasus penggunaan yang melibatkan komunikasi melalui jaringan seluler yang menambah penundaan dan jalur perutean yang kompleks. Anda harus menyadari perbedaan antara "waktu peristiwa" (saat peristiwa benar-benar terjadi) dan "waktu proses" (saat peristiwa mencapai sistem) dan menangani peristiwa sebagaimana mestinya. 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 pengurutan, ada kemungkinan pesan akan hilang. Hal ini dapat disebabkan oleh penonaktifan aplikasi dan perangkat karena masa pakai baterai perangkat, kerusakan yang tidak disengaja pada ponsel, konektivitas yang terputus saat berada di terowongan, atau pesan yang diterima, tetapi hanya di luar periode yang dapat diterima. Bagaimana ketidaklengkapan akan memengaruhi hasil Anda?

Daftar ini bukanlah daftar lengkap, melainkan pengantar. Berikut beberapa bacaan yang sangat direkomendasikan untuk membantu Anda memperdalam pemahaman tentang masing-masing topik.

Kontributor

Google mengelola dokumen ini. Kontributor berikut awalnya menulisnya.

Penulis utama: