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 layanan pelanggan dengan memberikan info perkiraan waktu tiba 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 dapat 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 mengenal "Layanan mobilitas", sebaiknya pelajari Solusi Fleet Kilometer Terakhir dan/atau Solusi Perjalanan dan Pengiriman Sesuai Permintaan, bergantung pada kebutuhan Anda.
  • Arsitek yang familier dengan Google Cloud. Bagi mereka yang baru mengenal Google Cloud, Membangun jalur 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 mendasar tentang elemen dan pertimbangan utama sistem streaming, beserta komponen dasar dari Google Maps Platform dan Google Cloud yang menyusun 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 Fleet Events

Ringkasan dan blok penyusun logis Peristiwa Fleet

Solusi referensi berisi komponen berikut:

  • Sumber Peristiwa: Tempat asal aliran peristiwa asli. "Solusi Fleet Kilometer Terakhir" dan "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 mungkin 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 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, peristiwa kustom ini secara alami dipilih 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 mengimplementasikan solusi referensi

Blok penyusun solusi referensi Acara Armada

Tata letak Proyek Cloud

Kami sarankan Anda menggunakan penerapan multiproyek sebagai default. Hal ini dilakukan agar penggunaan Google Maps Platform dan Google Cloud dapat dipisahkan dengan jelas dan dikaitkan dengan pengaturan penagihan pilihan Anda.

Sumber Acara

"Solusi Armada Jarak Jauh" dan "Solusi Perjalanan dan Pengiriman Sesuai Permintaan" menulis muatan permintaan dan respons API ke Cloud Logging. Cloud Logging mengirimkan log ke satu atau beberapa layanan pilihan. Perutean ke Cloud Pub/Sub merupakan pilihan sempurna di sini dan memungkinkan untuk mengubah log menjadi aliran peristiwa tanpa pengkodean.

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 elemen penyusun lainnya, komponen pemrosesan sepenuhnya tanpa server dan dapat diskalakan 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 tersedianya pustaka klien untuk API terkait Fleet Engine yang berkontribusi pada kemudahan implementasi
  • Cloud Firestore sebagai toko negara
    • Penyimpanan Kunci-Nilai Tanpa Server
  • 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, parameter 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 mendekati 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 terlalu terikat (kelincahan)?
    • Jika untuk latensi rendah, tentukan "low". Menit? Detik? Kurang dari satu 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 oleh sistem Anda saat ini atau mungkin mengalami kesulitan saat memproses peristiwa yang berasal dari perangkat Anda?

Prinsip-prinsip desain

Selalu berguna untuk memiliki beberapa proses berpikir untuk 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 kinerja, usahakan untuk memenuhi standar yang telah Anda tetapkan, bukan pengoptimalan maksimal. Hindari juga pengoptimalan ekstrem karena sering kali menyebabkan penambahan kompleksitas.
  • Hal yang sama berlaku untuk biaya. Menjaga biaya tetap wajar. Anda mungkin belum berada dalam kondisi yang memungkinkan Anda berkomitmen untuk menggunakan layanan yang bernilai tinggi, tetapi relatif lebih mahal.
  • Pada tahap eksperimental, penurunan skala dapat sama pentingnya dengan peningkatan skala. Pertimbangkan platform yang memberikan fleksibilitas untuk menskalakan dengan batas atas dan juga menskalakan ke bawah (idealnya hingga nol) sehingga Anda tidak mengeluarkan biaya saat tidak melakukan apa pun. Performa tinggi dengan infrastruktur yang selalu aktif dapat dipertimbangkan di tahap selanjutnya dalam perjalanan, saat Anda yakin dengan kebutuhannya.
  • Amati dan ukur sehingga Anda dapat mengidentifikasi bagian mana yang perlu ditingkatkan.
  • Jaga agar layanan tetap terhubung secara longgar. Hal ini mempermudah penukaran bagian demi bagian di kemudian hari.
  • Yang terakhir namun tidak kalah pentingnya, keamanan tidak boleh longgar. Sebagai layanan yang berjalan pada lingkungan cloud publik, tidak akan ada pintu yang tidak aman ke sistem.

Konsep streaming

Jika Anda relatif baru dalam hal berbasis acara atau streaming, ada beberapa konsep penting yang perlu dipahami, 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 bisa melakukannya. Kemacetan lalu lintas di kota dapat menimbulkan banyak kejadian secara tiba-tiba dari area tertentu, dan Anda masih harus bisa mengatasinya.
  • Windowing : 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 penjendelaan seperti "jendela tetap (misalnya setiap hari kalender)", "jendela geser (5 menit terakhir)", "jendela sesi (selama perjalanan ini)", yang harus Anda pilih. Makin panjang jendelanya, makin lama pula penundaan dalam menghasilkan hasil. Pilih model dan konfigurasi yang tepat yang memenuhi kebutuhan Anda.
  • Pemicu : Ada kasus di mana Anda tidak punya pilihan lain selain memiliki jendela yang relatif lebih panjang. Namun, Anda tidak ingin menunggu hingga akhir jendela untuk menghasilkan kejadian, tetapi sebaliknya, memancarkan hasil antara di antaranya. Konsep ini dapat diimplementasikan untuk kasus penggunaan yang bernilai dalam mengembalikan hasil cepat terlebih dahulu, lalu memperbaikinya nanti. Bayangkan memancarkan status menengah pada penyelesaian pengiriman sebesar 25%, 50%, 75%.
  • Pengurutan : Peristiwa tidak selalu sampai ke sistem sesuai urutan pembuatannya. Terutama untuk kasus penggunaan yang melibatkan komunikasi melalui jaringan seluler yang menambah penundaan dan jalur perutean yang rumit. Anda perlu menyadari perbedaan antara "waktu kejadian" (saat kejadian benar-benar terjadi) dan "waktu proses" (saat kejadian mencapai sistem) dan menangani kejadian sebagaimana mestinya. Secara umum, Anda ingin memproses peristiwa berdasarkan "waktu peristiwa".
  • Pengiriman pesan - Setidaknya-sekali versus Tepat-sekali: Platform acara yang berbeda memiliki dukungan yang berbeda untuk hal ini. Bergantung pada kasus penggunaan Anda, Anda perlu mempertimbangkan strategi percobaan ulang atau deduplikasi.
  • Kelengkapan : Sama seperti perubahan pemesanan, ada kemungkinan pesan akan hilang. Hal ini dapat disebabkan oleh penutupan aplikasi dan perangkat karena masa pakai 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: