Sangat mudah, cukup ketuk tombol di ponsel kita dan taksi tersedia dalam beberapa menit kapan pun dan di mana pun kita mau.
Uber/Ola /Lyft… menggunakan aplikasi ini dan mendapatkan layanan transportasi tanpa repot sangatlah sederhana, namun sederhanakah membangun aplikasi raksasa ini yang dikerjakan oleh ratusan insinyur perangkat lunak selama satu dekade? …? tentu saja tidak. Sistem ini memiliki arsitektur yang jauh lebih kompleks dan terdapat banyak komponen yang digabungkan secara internal untuk menyediakan layanan berkendara di seluruh dunia. Mari kita bahas…

Arsitektur Sistem Uber

Kita semua akrab dengan layanan Uber. Pengguna dapat meminta tumpangan melalui aplikasi dan dalam beberapa menit, pengemudi tiba di dekat lokasinya untuk mengantarkan mereka ke tujuan. Sebelumnya Uber dibangun berdasarkan model arsitektur perangkat lunak “monolitik”. Mereka memiliki layanan backend, layanan frontend, dan database tunggal. Mereka menggunakan Python dan kerangka kerjanya serta SQLAlchemy sebagai lapisan ORM ke database. Arsitektur ini baik-baik saja untuk sejumlah kecil perjalanan di beberapa kota tetapi ketika layanan mulai berkembang di kota-kota lain, tim Uber mulai menghadapi masalah dengan aplikasi tersebut. Setelah tahun 2014, tim Uber memutuskan untuk beralih ke “arsitektur berorientasi layanan” dan kini Uber juga menangani pengiriman makanan dan kargo.

1. Bicara Tentang Tantangannya

Salah satu tugas utama dalam layanan Uber adalah mencocokkan pengendara dengan taksi yang berarti kami memerlukan dua layanan berbeda dalam arsitektur kami yaitu.

  • Layanan Pasokan (untuk taksi)
  • Layanan Permintaan (untuk pengendara)

Uber memiliki sistem Pengiriman (Optimasi pengiriman/DISCO) dalam arsitekturnya untuk menyesuaikan pasokan dengan permintaan. Sistem pengiriman ini menggunakan telepon seluler dan bertanggung jawab untuk mencocokkan pengemudi dengan pengendara (supply to demand).

2. Bagaimana Sistem Pengiriman Bekerja?

DISCO harus memiliki tujuan ini…

  • Kurangi mengemudi ekstra.
  • Waktu tunggu minimal
  • ETA keseluruhan minimum

Sistem pengiriman sepenuhnya bekerja pada peta dan data lokasi/GPS, jadi hal pertama yang penting adalah memodelkan peta dan data lokasi kita.

  • Bumi berbentuk bulat sehingga sulit untuk melakukan peringkasan dan perkiraan dengan menggunakan garis lintang dan garis bujur. Untuk mengatasi masalah ini Uber menggunakan perpustakaan Google S2. Pustaka ini membagi data peta menjadi sel-sel kecil (misalnya 3 km) dan memberikan ID unik untuk setiap sel. Ini adalah cara mudah untuk menyebarkan data dalam sistem terdistribusi dan menyimpannya dengan mudah.
  • Pustaka S2 memberikan cakupan untuk bentuk apa pun dengan mudah. Misalkan Anda ingin mengetahui semua persediaan yang tersedia dalam radius 3 km dari sebuah kota. Dengan menggunakan perpustakaan S2 Anda dapat menggambar lingkaran dengan radius 3 km dan itu akan menyaring semua sel dengan ID yang ada di lingkaran tersebut. Dengan cara ini Anda dapat dengan mudah mencocokkan pengendara dengan pengemudi dan Anda dapat dengan mudah mengetahui jumlah mobil (persediaan) yang tersedia di wilayah tertentu.

3. Pelayanan Penyediaan Dan Cara Kerjanya?

  • Dalam kasus kami, taksi adalah layanan pasokan dan mereka akan dilacak berdasarkan geolokasi (lintang dan bujur). Semua taksi aktif terus mengirimkan lokasi ke server setiap 4 detik sekali melalui firewall aplikasi web dan penyeimbang beban. Lokasi GPS yang akurat dikirim ke pusat data melalui Rest API Kafka setelah melewati penyeimbang beban. Di sini kami menggunakan Apache Kafka sebagai pusat data.
  • Setelah lokasi terbaru diperbarui oleh Kafka, lokasi tersebut secara perlahan melewati memori utama catatan pekerja masing-masing.
  • Juga salinan lokasi (mesin negara/lokasi taksi terbaru) akan dikirim ke database dan ke optimasi pengiriman agar lokasi terbaru selalu diperbarui.
  • Kita juga perlu melacak beberapa hal lagi seperti jumlah kursi, keberadaan kursi mobil untuk anak-anak, jenis kendaraan, apakah kursi roda dapat muat, dan alokasi (misalnya, sebuah taksi mungkin memiliki empat kursi tetapi dua di antaranya terisi .)

4. Permintaan Pelayanan Dan Cara Kerjanya?

  • Layanan permintaan menerima permintaan taksi melalui soket web dan melacak lokasi GPS pengguna. Ia juga menerima berbagai jenis persyaratan seperti jumlah kursi, jenis mobil, atau mobil biliar.
  • Permintaan memberikan lokasi (ID sel) dan kebutuhan pengguna untuk memasok dan membuat permintaan taksi.

5. Bagaimana Sistem Pengiriman Mencocokkan Pengendara dengan Pengemudi?

  • Kita telah membahas bahwa DISCO membagi peta menjadi sel-sel kecil dengan ID unik. ID ini digunakan sebagai kunci sharding di DISCO. Ketika pasokan menerima permintaan dari permintaan, lokasi diperbarui menggunakan ID sel sebagai kunci pecahan. Tanggung jawab sel-sel kecil ini akan dibagi ke dalam server-server berbeda yang terletak di beberapa wilayah (hashing yang konsisten). Misalnya, kita dapat mengalokasikan tanggung jawab 12 sel kecil ke 6 server berbeda (2 sel untuk setiap server) yang terletak di 6 wilayah berbeda.

  • Pasokan mengirimkan permintaan ke server tertentu berdasarkan data lokasi GPS. Setelah itu, sistem menggambar lingkaran dan menyaring semua taksi terdekat yang memenuhi kebutuhan pengendara.
  • Setelah itu, daftar taksi dikirim ke ETA untuk menghitung jarak antara pengendara dan taksi, bukan secara geografis tetapi berdasarkan sistem jalan raya.
  • ETA yang diurutkan kemudian dikirim kembali ke sistem pasokan untuk ditawarkan kepada pengemudi.

Jika kami perlu menangani lalu lintas untuk kota yang baru ditambahkan maka kami dapat menambah jumlah server dan mengalokasikan tanggung jawab ID seluler kota yang baru ditambahkan ke server ini.

6. Bagaimana Menskalakan Sistem Pengiriman?

  • Sistem pengiriman (termasuk pasokan, permintaan, dan soket web) dibangun di atas NodeJS. NodeJS adalah kerangka kerja asinkron dan berbasis peristiwa yang memungkinkan Anda mengirim dan menerima pesan melalui WebSockets kapan pun Anda mau.
  • Uber menggunakan ringpop sumber terbuka untuk menjadikan aplikasinya kooperatif dan dapat diskalakan untuk lalu lintas padat. Ring pop terutama memiliki tiga bagian dan melakukan operasi di bawah ini untuk menskalakan sistem pengiriman.
  1. Ia mempertahankan hashing yang konsisten untuk menugaskan pekerjaan ke seluruh pekerja. Ini membantu dalam melakukan sharding pada aplikasi dengan cara yang terukur dan toleran terhadap kesalahan.
  2. Ringpop menggunakan protokol RPC (Panggilan Prosedur Jarak Jauh) untuk melakukan panggilan dari satu server ke server lain.
  3. Ringpop juga menggunakan protokol keanggotaan SWIM/protokol gosip yang memungkinkan pekerja independen mengetahui tanggung jawab satu sama lain. Dengan cara ini setiap server/node mengetahui tanggung jawab dan pekerjaan node lainnya.
  4. Ringpop mendeteksi node yang baru ditambahkan ke cluster dan node yang dihapus dari cluster. Ini mendistribusikan beban secara merata ketika sebuah node ditambahkan atau dihapus.

7. Bagaimana Uber Mendefinisikan Wilayah Peta?

Sebelum meluncurkan operasi baru di area baru, Uber memasukkan wilayah baru tersebut ke tumpukan teknologi peta. Di wilayah peta ini, kami mendefinisikan berbagai subwilayah yang diberi label nilai A, B, AB, dan C.

Kelas A: Subkawasan ini mencakup pusat kota dan kawasan perjalanan. Sekitar 90% lalu lintas Uber tercakup dalam subwilayah ini, jadi penting untuk membuat peta dengan kualitas terbaik untuk subwilayah A.

Kelas B: Subwilayah ini mencakup wilayah pedesaan dan pinggiran kota yang berpenduduk lebih sedikit dan jarang dilalui oleh pelanggan Uber.

Kelas AB: Gabungan subkawasan kelas A dan B.

Kelas C: Mencakup rangkaian koridor jalan raya yang menghubungkan berbagai Wilayah Uber.

8. Bagaimana Uber Membuat Peta?

Uber menggunakan penyedia layanan peta pihak ketiga untuk membuat peta di aplikasinya. Sebelumnya Uber menggunakan layanan Mapbox namun kemudian Uber beralih ke Google Maps API untuk melacak lokasi dan menghitung ETA.

1. Cakupan jejak: Cakupan jejak menemukan segmen jalan yang hilang atau geometri jalan yang salah. Penghitungan cakupan jejak didasarkan pada dua masukan: data peta yang sedang diuji dan jejak GPS historis dari semua perjalanan Uber yang dilakukan selama jangka waktu tertentu. Ini mencakup jejak GPS pada peta, membandingkan dan mencocokkannya dengan segmen jalan. Jika kami menemukan ruas jalan yang hilang (tidak ada jalan yang ditampilkan) pada jejak GPS, maka kami mengambil beberapa langkah untuk memperbaiki kekurangan tersebut.

2. Akurasi titik akses (penjemputan) pilihan: Kami mendapatkan titik penjemputan di aplikasi saat memesan taksi di Uber. Titik penjemputan adalah metrik yang sangat penting di Uber terutama untuk tempat-tempat besar seperti bandara, kampus, stadion, pabrik, atau perusahaan. Kami menghitung jarak antara lokasi sebenarnya dan semua titik penjemputan dan pengantaran yang digunakan oleh pengemudi.

Jarak terpendek (titik penjemputan terdekat) kemudian dihitung dan kita atur pin ke lokasi tersebut sebagai titik akses pilihan di peta. Ketika pengendara meminta lokasi yang ditunjukkan oleh pin peta, peta akan memandu pengemudi ke titik akses pilihan. Perhitungan dilanjutkan dengan lokasi penjemputan dan pengantaran terkini untuk memastikan kesegaran dan keakuratan titik akses pilihan yang disarankan. Uber menggunakan pembelajaran mesin dan algoritme berbeda untuk menentukan titik akses pilihan.

9. Bagaimana ETA Dihitung?

ETA adalah metrik yang sangat penting di Uber karena berdampak langsung pada pencocokan perjalanan dan pendapatan. ETA dihitung berdasarkan sistem jalan (bukan geografis) dan ada banyak faktor yang terlibat dalam menghitung ETA (seperti lalu lintas padat atau pembangunan jalan). Ketika pengendara meminta taksi dari suatu lokasi, aplikasi tidak hanya mengidentifikasi taksi yang kosong/tidak digunakan tetapi juga mencakup taksi yang akan menyelesaikan perjalanan. Mungkin saja salah satu taksi yang akan menyelesaikan perjalanan lebih dekat dengan permintaan dibandingkan taksi yang jauh dari pengguna. Begitu banyak mobil uber di jalan yang mengirimkan lokasi GPS setiap 4 detik, jadi untuk memprediksi lalu lintas kita dapat menggunakan data lokasi GPS aplikasi pengemudi.

Kita dapat merepresentasikan seluruh jaringan jalan dalam grafik untuk menghitung ETA. Kita dapat menggunakan algoritma simulasi AI atau algoritme Dijkstra sederhana untuk mengetahui rute terbaik dalam grafik ini. Dalam grafik tersebut, simpul mewakili persimpangan (taksi yang tersedia), dan tepi mewakili segmen jalan. Kami mewakili jarak segmen jalan atau waktu perjalanan melalui bobot tepi. Kami juga merepresentasikan dan memodelkan beberapa faktor tambahan dalam grafik kami seperti jalan satu arah, biaya belokan, pembatasan belokan, dan batas kecepatan.

Setelah struktur data ditentukan, kita dapat menemukan rute terbaik menggunakan algoritma pencarian Dijkstra yang merupakan salah satu algoritma perutean modern terbaik saat ini. Untuk kinerja yang lebih cepat, kita juga perlu menggunakan OSRM (Open Source Routing Machine) yang didasarkan pada hierarki kontraksi. Sistem berdasarkan hierarki kontraksi hanya memerlukan beberapa milidetik untuk menghitung rute — dengan melakukan pra-pemrosesan grafik perutean.

10. Basis Data

Uber harus mempertimbangkan beberapa persyaratan database untuk pengalaman pelanggan yang lebih baik. Persyaratan tersebut adalah…

  • Basis data harus dapat diskalakan secara horizontal. Anda dapat menambah kapasitas secara linear dengan menambahkan lebih banyak server.
  • Ini harus mampu menangani banyak pembacaan dan penulisan karena setiap 4 detik taksi akan mengirimkan lokasi GPS dan lokasi tersebut akan diperbarui dalam database.
  • Sistem tidak boleh memberikan waktu henti (downtime) untuk operasi apa pun. Ini harus selalu tersedia, apa pun operasi yang Anda lakukan (memperluas penyimpanan, membuat cadangan, ketika node baru ditambahkan, dll).

Sebelumnya Uber menggunakan database RDBMS PostgreSQL tetapi karena masalah skalabilitas, uber beralih ke berbagai database. Uber menggunakan database NoSQL (tanpa skema) yang dibangun di atas database MySQL.

  • Redis untuk caching dan antrian. Beberapa berada di belakang “Twemproxy” (yang menyediakan skalabilitas lapisan caching). Beberapa berada di balik sistem pengelompokan khusus.
  • Uber menggunakan skema (dibangun sendiri di atas MySQL), Riak, dan Cassandra. Schemaless untuk penyimpanan data jangka panjang. Riak dan Cassandra memenuhi permintaan ketersediaan tinggi dan latensi rendah.
  • basis data MySQL.
  • Uber sedang membangun penyimpanan kolom terdistribusi mereka sendiri yang mengatur banyak instance MySQL.

11. Analisis

Untuk mengoptimalkan sistem, meminimalkan biaya pengoperasian, dan untuk pengalaman pelanggan yang lebih baik, Uber melakukan pengumpulan dan analisis log. Uber menggunakan alat dan kerangka kerja yang berbeda untuk analisis. Untuk analisis log, Uber menggunakan beberapa cluster Kafka. Kafka mengambil data historis bersama dengan data real-time. Data diarsipkan ke Hadoop sebelum masa berlakunya habis dari Kafka. Data juga diindeks ke dalam tumpukan pencarian elastis untuk pencarian dan visualisasi. Pencarian elastis melakukan beberapa analisis log menggunakan Kibana/Graphana. Beberapa analisis yang dilakukan oleh Uber menggunakan alat dan kerangka kerja yang berbeda adalah…

  • Lacak API HTTP
  • Kelola profil
  • Kumpulkan umpan balik dan peringkat
  • Promosi dan kupon dll
  • Deteksi penipuan
  • Penipuan pembayaran
  • Penyalahgunaan insentif oleh pengemudi
  • Akun yang disusupi oleh peretas. Uber menggunakan data historis pelanggan dan beberapa teknik pembelajaran mesin untuk mengatasi masalah ini.

12. Bagaimana Mengatasi Kegagalan Pusat Data?

Kegagalan pusat data tidak terlalu sering terjadi namun Uber tetap menyediakan pusat data cadangan untuk menjalankan perjalanan dengan lancar. Pusat data ini mencakup semua komponen tetapi Uber tidak pernah menyalin data yang ada ke pusat data cadangan.

Lalu bagaimana cara Uber mengatasi kegagalan pusat data??

Ini sebenarnya menggunakan telepon pengemudi sebagai sumber data perjalanan untuk mengatasi masalah kegagalan pusat data.
Saat aplikasi telepon pengemudi berkomunikasi dengan sistem pengiriman atau panggilan API terjadi di antara keduanya, sistem pengiriman mengirimkan intisari status terenkripsi (untuk melacak informasi/data terbaru) ke aplikasi telepon pengemudi. Setiap saat, intisari status ini akan diterima oleh aplikasi ponsel pengemudi. Jika terjadi kegagalan pusat data, pusat data cadangan (disco cadangan) tidak mengetahui apa pun tentang perjalanan sehingga akan meminta intisari status dari aplikasi telepon pengemudi dan akan memperbarui dirinya dengan informasi intisari status yang diterima oleh pengemudi. aplikasi telepon.