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

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

  • Memantau performa fleet dan mengidentifikasi potensi masalah sejak dini
  • Meningkatkan layanan pelanggan dengan memberikan perkiraan waktu tiba (ETA) 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 menggambarkan cara developer mengubah sinyal dari "Layanan Mobilitas" Google Maps Platform ("Solusi Armada Last Mile" (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 dengan:

  • Arsitek yang memahami "layanan Mobilitas" Google Maps Platform dan salah satu komponen intinya, "Fleet Engine". Bagi yang baru mengenal "Layanan Mobilitas", sebaiknya pelajari Solusi Fleet Kilometer Terakhir dan/atau Solusi Perjalanan dan Pengiriman On-demand, bergantung pada kebutuhan Anda.
  • Arsitek yang memahami Google Cloud. Bagi mereka 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 pada pemahaman poin integrasi dan pertimbangan utama Fleet Engine, yang seharusnya masih berlaku.
  • Mereka yang memiliki minat umum dalam mempelajari cara membuat dan memanfaatkan peristiwa dari fleet.

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

Ringkasan Solusi Referensi Peristiwa Fleet

Solusi Referensi Peristiwa Flotte adalah solusi open source yang memungkinkan pelanggan dan partner Mobilitas membuat peristiwa utama di atas komponen Flotte 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 secara 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 yang tersisa hingga tugas tiba
  • Jarak yang tersisa ke kedatangan tugas
  • Perubahan status TaskOutcome

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

Elemen Penyusun Logika

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

Ringkasan Peristiwa Fleet dan elemen penyusun yang logis

Solusi referensi berisi komponen berikut:

  • Sumber Peristiwa: Tempat asal aliran peristiwa asli. "Solusi Armada 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 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 tersebut, blok ini mungkin akan 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 sangat cocok.
  • Sink (Peristiwa Kustom): Perubahan status yang terdeteksi harus tersedia untuk aplikasi atau layanan apa pun yang dapat memanfaatkannya. Oleh karena itu, memublikasikan peristiwa kustom ini ke sistem pengiriman peristiwa untuk konsumsi downstream adalah pilihan yang wajar.
  • Layanan downstream: Kode yang menggunakan peristiwa yang dihasilkan dan mengambil tindakan yang unik untuk kasus penggunaan Anda.

Pilihan layanan

Dalam hal menerapkan solusi referensi untuk "Solusi Armada Kilometer Terakhir" atau "Solusi Perjalanan dan Pengiriman On-demand" (akan hadir pada akhir Kuartal 3 2023), pemilihan teknologi untuk "Sumber" dan "Sink '' sangat 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

Blok pembentuk solusi referensi Peristiwa Armada

Tata letak Project Cloud

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

Sumber Peristiwa

"Last Mile Fleet Solutions" 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. Pemuatan 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 pilihan yang hampir real time. Sama seperti cara peristiwa dari sumber dikirim ke Pub/Sub, peristiwa kustom juga dipublikasikan ke Pub/Sub untuk penggunaan downstream.

Memproses

Komponen berikut berperan dalam pemrosesan peristiwa. Seperti elemen penyusun lainnya, komponen pemrosesan sepenuhnya serverless, serta dapat diskalakan dengan baik ke atas maupun ke bawah.

  • Cloud Functions sebagai platform komputasi untuk rilis awal (*)
    • Serverless, diskalakan ke atas dan ke bawah 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 terikat 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

Agar proses deployment solusi referensi dapat diulang, 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 kaya untuk Google Cloud.

Modul Terraform

Daripada membuat satu modul deployment solusi referensi monolitik berukuran 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, fungsi ini digunakan untuk merutekan log terkait Fleet Engine ke topik Pub/Sub tertentu.
  • Deployment fungsi cloud Peristiwa Kendaraan: Berisi deployment kode fungsi contoh dan juga menangani otomatisasi setelan izin yang diperlukan untuk integrasi lintas project yang aman.
  • Deployment solusi referensi lengkap: 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 guna memberi Anda kontrol yang lebih besar atas keamanan.

Tindakan berikutnya

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

Lampiran

Mengumpulkan persyaratan

Sebaiknya kumpulkan persyaratan Anda di awal proses.

Pertama, catat detail tentang alasan Anda tertarik atau perlu menggunakan peristiwa mendekati real-time. Berikut ini beberapa pertanyaan untuk membantu menjelaskan kebutuhan Anda.

  • Informasi apa yang diperlukan agar aliran peristiwa berguna?
    • Dapatkah hasilnya berasal murni 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?
    • Apa metrik yang ingin Anda ukur sebagai bisnis? Bagaimana mereka didefinisikan?
    • Jika Anda perlu menghitung metrik di seluruh peristiwa, jenis agregasi apa yang diperlukan? Coba buat tata letak langkah-langkah yang logis. (misalnya, Bandingkan ETA/ATA dengan SLO di seluruh subkumpulan armada selama jam sibuk untuk menghitung performa dalam keterbatasan resource.)
  • Mengapa Anda tertarik dengan model berbasis peristiwa, bukan batch? Apakah ini untuk latensi yang lebih rendah (waktu untuk bertindak) atau untuk integrasi yang terikat longgar (kelincahan)?
    • Jika untuk latensi rendah, tentukan "low". Menit? Detik? Subdetik? Dan latensi apa?
  • Sebagai tim, apakah Anda sudah berinvestasi dalam stack teknologi dan keterampilan terkait? Jika ya, apa itu dan apa titik integrasi yang disediakannya?
    • 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

Akan selalu berguna jika Anda memiliki beberapa proses pemikiran yang dapat diikuti. Hal ini membantu membuat keputusan desain yang konsisten, terutama jika Anda memiliki berbagai opsi untuk memilih.

  • Default ke opsi yang lebih sederhana.
  • Setelan defaultnya adalah waktu pencapaian nilai yang lebih singkat. Lebih sedikit kode, kurva belajar lebih rendah.
  • Untuk latensi dan performa, usahakan untuk memenuhi standar yang telah Anda tetapkan, bukan pengoptimalan maksimum. Selain itu, hindari pengoptimalan ekstrem karena sering kali menyebabkan kompleksitas tambahan.
  • Hal yang sama berlaku untuk biaya. Pastikan biaya tetap masuk akal. Anda mungkin belum berada dalam kondisi yang dapat berkomitmen untuk menggunakan layanan bernilai tinggi, tetapi relatif lebih mahal.
  • Pada fase eksperimental, penskalaan ke bawah dapat sama pentingnya dengan penskalaan ke atas. Pertimbangkan platform yang memberikan fleksibilitas untuk menskalakan ke atas dengan batas dan juga menskalakan ke bawah (idealnya ke 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 agar Anda dapat mengidentifikasi bagian mana yang perlu ditingkatkan nanti.
  • Pastikan layanan tetap dikaitkan secara longgar. Hal ini mempermudah untuk menukarnya satu per satu nanti.
  • Yang terakhir namun 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 dalam hal streaming atau berbasis peristiwa, ada konsep utama yang perlu diketahui, beberapa di antaranya bisa sangat berbeda dari batch processing.

  • Skala : Berbeda dengan pemrosesan batch, yang biasanya Anda memiliki gambaran yang baik tentang jumlah data yang akan diproses, dalam streaming Anda tidak dapat melakukannya. Kemacetan lalu lintas di kota dapat menyebabkan banyak peristiwa secara tiba-tiba dari area tertentu, dan Anda tetap harus dapat memprosesnya.
  • Windowing : Daripada memproses peristiwa satu per satu, sering kali Anda ingin mengelompokkan peristiwa selama linimasa menjadi "jendela" yang lebih kecil sebagai unit untuk komputasi. Ada berbagai strategi periode seperti "periode tetap (misalnya, setiap hari kalender)", "periode geser (5 menit terakhir)", "periode sesi (selama perjalanan ini)", yang harus Anda pilih. Semakin panjang periodenya, semakin lama penundaan dalam memberikan hasil. Pilih model dan konfigurasi yang tepat dan memenuhi persyaratan Anda.
  • Pemicuan : Terkadang Anda tidak memiliki pilihan lain selain memiliki jendela yang relatif lebih panjang. Namun, Anda tidak ingin menunggu hingga akhir jendela untuk menghasilkan peristiwa, tetapi sebaiknya tampilkan hasil sementara di antaranya. Konsep ini dapat diterapkan untuk kasus penggunaan yang bernilai dalam menampilkan hasil cepat terlebih dahulu, lalu memperbaikinya nanti. Bayangkan memunculkan status perantara pada 25%, 50%, 75% penyelesaian pengiriman.
  • Pengurutan : Peristiwa tidak selalu mencapai sistem dalam urutan yang dibuat. Terutama untuk kasus penggunaan yang melibatkan komunikasi melalui jaringan seluler yang menambahkan penundaan dan jalur pemilihan rute yang kompleks. Anda harus mengetahui perbedaan antara "waktu peristiwa" (saat peristiwa benar-benar terjadi) dan "waktu proses" (saat peristiwa mencapai sistem) dan menangani peristiwa dengan semestinya. 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 urutan, ada kemungkinan pesan hilang. Hal ini dapat disebabkan oleh penghentian aplikasi dan perangkat karena masa pakai baterai perangkat, kerusakan yang tidak disengaja pada ponsel, hilangnya konektivitas saat berada di tunnel, atau pesan yang diterima, tetapi hanya di luar periode yang dapat diterima. Bagaimana ketidaklengkapan akan memengaruhi hasil Anda?

Ini bukan daftar lengkap, tetapi merupakan pengantar. Berikut beberapa artikel yang sangat direkomendasikan yang dapat membantu Anda lebih memahami setiap fitur.

Kontributor

Google mengelola dokumen ini. Kontributor berikut awalnya menulisnya.

Penulis utama: