Arsitektur Microservice Berorientasi Domain milik Uber

DOMA adalah pendekatan yang diambil Uber, yang memiliki 2.200 microservice, untuk mengurangi kompleksitas sambil tetap mempertahankan fleksibilitas MSA

• Dirancang agar cocok untuk sistem terdistribusi skala besar di organisasi besar dengan mengambil konsep dari DDD, SOA, OO, CA, dan lain-lain

• Tulisan yang merangkum pengalaman panjang Uber dalam mengoperasikan MSA selama waktu yang cukup lama

Prinsip dasar DOMA

1. Mengumpulkan microservice sebagai koleksi berdasarkan unit Domain

2. Membuat koleksi domain yang disebut Layer, sehingga dependensi di dalam tiap layer dimungkinkan → Layer Design

3. Membuat Gateway yang menyediakan antarmuka yang rapi sebagai titik masuk tunggal untuk tiap koleksi

4. Tiap domain harus independen terhadap domain lain. Namun karena sering kali perlu memasukkan logika dari domain lain, disediakan arsitektur Extension yang mendukung hal ini dengan baik

** Implementasi Uber

• Domains

→ Kumpulan satu atau lebih microservice yang dikelompokkan secara logis.

→ Tiap domain bisa memiliki lebih dari 10 service, atau bisa juga hanya satu

→ Contoh: pencarian peta, tarif, platform pencocokan (rider dan pengemudi) adalah masing-masing satu domain

→ Tidak mengikuti struktur organisasi perusahaan, sehingga organisasi terkait peta di Uber terdiri dari 3 domain, 80 microservice, dan 3 gateway

• Layer Design

→ Jawaban atas pertanyaan "service mana yang boleh memanggil service lain?"

→ "separation of concerns at scale" atau "dependency management at scale"

→ Uber terdiri dari 5 Layer

1. Infrastructure : kemampuan yang bisa digunakan semua organisasi. Seperti storage/networking dan sebagainya

2. Business : kemampuan yang dapat digunakan pada unit bisnis. Tidak terbatas pada kategori produk tertentu atau LOB (Line Of Business) seperti Rides, Eats, Freight, dan sebagainya

3. Product : kemampuan yang terkait dengan kategori produk dan LOB tertentu, tetapi juga bisa berupa hal seperti "Request a ride" yang dipakai bersama di beberapa aplikasi

4. Presentation : fungsi terkait aplikasi yang menghadap pengguna (mobile / web)

5. Edge : mengekspos layanan Uber ke luar secara aman. Juga terhubung dengan aplikasi mobile

• Gateways

→ Tidak jauh berbeda dari API Gateway pada microservice. Namun, ini dipandang sebagai titik masuk tunggal (Single Entry-point) yang terhubung ke Domain

→ Karena secara internal hanya memiliki satu dependensi ke luar, migrasi, discovery, dan kompleksitas sistem secara keseluruhan berkurang

• Extensions

→ Mekanisme untuk memperluas domain tanpa mengubah implementasi service atau memengaruhi stabilitasnya

1. Ekstensi Logic : memperluas logika service dengan pola Provider atau Plugin

2. Ekstensi Data : mekanisme untuk menautkan data arbitrer agar core data tidak terus membesar. Memanfaatkan tipe Any dari Protobuf

3. Ekstensi Custom : tiap tim melakukan ekstensi dengan pola yang sesuai untuk domainnya

Waktu onboarding berkurang 25~50%

2.200 microservice dipisahkan menjadi 70 domain.

Di Uber, half-life microservice dihitung 1,5 tahun. Artinya, setiap 1,5 tahun 50% microservice akan hilang

Jika tidak ada gateway, setiap kali hal ini terjadi akan muncul migration hell.

Di Uber, telah terbukti bahwa platform yang dirancang menggunakan DOMA jauh lebih mudah diskalakan dan lebih mudah dipelihara.

Saran praktis untuk perusahaan lain

• Startup :

→ Pertanyaan seperti "kapan sebaiknya mengadopsi MSA?" dan "apakah ini cocok untuk organisasi kami?" itu penting.

→ MSA memberi keuntungan operasional untuk organisasi dengan banyak engineer, tetapi juga meningkatkan kompleksitas sehingga pengembangan fitur bisa menjadi lebih sulit

→ Pada organisasi kecil, bisa jadi yang didapat hanya peningkatan kompleksitas arsitektur tanpa keuntungan operasional, dan biaya pun bisa lebih besar.

→ Mengadopsinya secara perlahan juga tidak masalah, dan jika memutuskan beralih ke MSA maka perlu memikirkan microservice sebagai "program terdistribusi skala besar" dan memisahkannya dengan tepat satu sama lain.

→ Microservice pertama akan penting ketika menjelaskan fungsi inti bisnis, dan kemungkinan akan bertahan lama

• Perusahaan menengah :

→ Ketika perusahaan mulai terbagi menjadi beberapa tim dan pemisahan concern antar platform mulai muncul, MSA menjadi lebih berguna

→ Pada tahap ini, struktur berlapis antar microservice mulai bisa dipertimbangkan, dan karena lebih banyak service dipakai maka manajemen dependensi menjadi penting

→ Jumlah microservice masih belum terlalu banyak, jadi clustering mungkin belum bermakna, tetapi berpikir secara domain-oriented tetap berguna

• Perusahaan besar :

→ Untuk organisasi engineering skala besar yang memiliki ratusan engineer, microservice, dan dependensi, DOMA sepenuhnya berguna

→ Dapat dengan mudah dikelompokkan ke dalam domain yang memiliki gateway, dan gateway juga berguna saat me-refactor atau menulis ulang sistem legacy

Di Uber pun makin banyak tim yang secara bertahap mengadopsi DOMA. (Disebutkan bahwa sekitar 60 orang dari seluruh organisasi Uber ikut terlibat bersama selama 2 tahun untuk membuatnya)

[algedian]

https://eng.uber.com/microservice-architecture/

Sekarang sepertinya bisa terlihat dengan baik.. tapi sepertinya gambar di versi yang ada di Wayback Machine agak berbeda.

[xguru]

Ah, sekarang sudah hidup lagi ya hehe Saya sudah mengembalikannya seperti semula.

Sepertinya gambar yang menampilkan nama layanan secara detail itulah masalahnya.

[jaeyeonling]

Sepertinya artikelnya sudah dihapus T.T

[xguru]

Wah, benar juga ya. Untuk saat ini, itu bisa dilihat di Wayback Machine.

https://web.archive.org/web/20200803012939/…

[jaeyeonling]

Terima kasih :)