pengantar
Baru-baru ini, kelemahan arsitektur berorientasi layanan dan, khususnya, arsitektur layanan mikro (MA) telah secara aktif dibahas. Beberapa tahun yang lalu, banyak yang bersedia bermigrasi ke MA karena banyak manfaatnya: fleksibilitas dalam bentuk penerapan independen, kepemilikan transparan, peningkatan stabilitas sistem, dan pemisahan masalah yang lebih baik. Namun, situasinya baru-baru ini berubah: pendekatan layanan mikro mulai dikritik karena kecenderungannya untuk meningkatkan kompleksitas secara serius, yang terkadang menyulitkan penerapan fungsi yang bahkan sepele . (Kami membicarakan hal ini dalam pembicaraan "Layanan Mikro: Ukuran Itu Penting, Meskipun Anda Memiliki Kubernetes " - kira-kira. Terjemahan)
Uber saat ini memiliki sekitar 2.200 layanan mikro kritis, dan kami sendiri telah mengalami semua pro dan kontra dari pendekatan ini. Selama dua tahun terakhir, Uber telah mencoba mengurangi kompleksitas lanskap layanan mikro sambil mempertahankan keunggulan arsitekturnya. Dengan posting ini, kami berencana untuk mempresentasikan pendekatan generik kami untuk arsitektur layanan mikro yang disebut Domain-Oriented Microservice Architecture (DOMA).
Meskipun telah populer untuk mengkritik arsitektur layanan mikro karena kekurangannya dalam beberapa tahun terakhir, hanya sedikit yang berani menyatakan bahwa mereka harus ditinggalkan seluruhnya. Manfaat operasional mereka terlalu penting; lebih jauh, tampaknya tidak ada (atau sangat terbatas) alternatif untuk pendekatan ini. Tujuan dari pendekatan umum kami adalah untuk membantu organisasi yang ingin mengurangi kompleksitas sistem secara keseluruhan sambil mempertahankan fleksibilitas MA.
Artikel ini akan membahas DOMA, tantangan yang mengarah pada pendekatan ini di Uber, manfaatnya bagi tim platform dan produk, dan terakhir beberapa tip bagi mereka yang ingin bermigrasi ke arsitektur ini.
Apa itu layanan mikro?
Layanan mikro adalah perpanjangan dari arsitektur berorientasi layanan. Tidak seperti "layanan" yang cukup besar di tahun 2000-an, layanan mikro menjalankan tugas tertentu. Aplikasi ini di-host dan dapat diakses melalui jaringan dan menyediakan antarmuka yang terdefinisi dengan baik. Aplikasi lain mengakses antarmuka ini menggunakan remote procedure call (RPC).
Karakteristik utama MA adalah cara kode diposting, dipanggil, dan diterapkan. Aplikasi besar dan monolitik biasanya dibagi menjadi komponen yang dikemas dengan antarmuka yang terdefinisi dengan baik. Antarmuka ini kemudian dipanggil langsung dari dalam proses daripada melalui jaringan. Dalam pengertian ini, layanan mikro dapat dipandang sebagai semacam pustaka dengan kinerja lebih rendah (karena efek penundaan jaringan dan waktu pada serialisasi / deserialisasi) saat memanggil salah satu fungsinya.
Memikirkan layanan mikro dengan cara ini, kita mungkin bertanya-tanya mengapa kita membutuhkan arsitektur layanan mikro sama sekali? Jawaban klasik untuk pertanyaan ini adalah karena kemampuan untuk menyebarkan komponen individu secara mandiri dan dengan mudah menskalakannya .... Dalam kasus aplikasi monolitik yang besar, organisasi dipaksa untuk menyebarkan atau melepaskan semua kode pada waktu yang sama. Alhasil, setiap versi baru membawa banyak perubahan. Penerapan menjadi berisiko dan memakan waktu. Setiap kesalahan dapat menjatuhkan seluruh sistem.
Jadi, perusahaan beralih ke layanan mikro untuk kemudahan penggunaan sambil mengorbankan kinerja . Mereka juga harus menanggung biaya tambahan untuk memelihara infrastruktur yang diperlukan untuk layanan mikro. Pengalaman menunjukkan bahwa dalam banyak situasi kompromi semacam itu masuk akal. Pada saat yang sama, ini adalah argumen kuat yang menentang transisi dini ke MA.
Motivasi
Pada saat transisi ke layanan mikro (sekitar 2012-2013), kami di Uber memiliki dua layanan monolitik utama, dan kami menghadapi banyak masalah operasional yang berhasil diselesaikan oleh layanan mikro:
- Risiko ketersediaan. Kesalahan apa pun dalam basis kode monolit dapat menjatuhkan seluruh sistem (dalam hal ini, seluruh Uber).
- Penerapan yang berisiko dan mahal. Mereka sangat sulit untuk dijalankan, dan sering kali harus memutar kembali ke versi sebelumnya.
- Pemisahan bidang tanggung jawab yang buruk. Sangat sulit untuk melacak siapa yang bertanggung jawab atas apa dalam basis kode kolosal. Dengan pertumbuhan eksponensial, tergesa-gesa terkadang mengaburkan garis antara logika dan komponen.
- Pekerjaan yang tidak efisien. Masalah di atas bersama-sama menyulitkan tim untuk bekerja secara mandiri atau independen satu sama lain.
Dengan kata lain, dengan latar belakang peningkatan jumlah insinyur di Uber dari puluhan menjadi ratusan orang dan munculnya sejumlah besar tim yang memiliki bagian dari tumpukan teknologi mereka, arsitektur monolitik semakin mengikat nasib tim-tim ini dan tidak memungkinkan mereka untuk bekerja secara mandiri.
Oleh karena itu, kami memutuskan untuk beralih ke MA. Hasilnya, sistem kami menjadi lebih fleksibel dan memungkinkan tim menjadi lebih mandiri .
- Keandalan sistem. Keandalan sistem secara keseluruhan meningkat dengan transisi ke MA. Layanan individu dapat macet (dan dapat digulung kembali ke versi sebelumnya) tanpa berisiko merusak seluruh sistem.
- . - : « ?», — .
- . , . , , , , .
- . .
- . .
Tidaklah berlebihan untuk mengatakan bahwa Uber tidak dapat mencapai skala dan tingkat kualitasnya saat ini tanpa MA.
Namun, seiring perusahaan terus berkembang dan jumlah teknisi meningkat dari ratusan menjadi ribuan, kami mulai memperhatikan sejumlah masalah yang terkait dengan kompleksitas sistem yang meningkat secara signifikan . Dalam kasus MA, kami mengorbankan satu basis kode monolitik dengan imbalan sejumlah kotak hitam, yang fungsinya dapat berubah kapan saja dan mengarah pada perilaku yang tidak terduga.
Misalnya, teknisi harus menganalisis ~ 50 layanan di 12 tim berbeda untuk sampai ke akar masalah.
Memahami ketergantungan antar layanan bisa menjadi sangat sulit karena mereka dapat berinteraksi satu sama lain di banyak tingkatan. Lonjakan penundaan dalam ketergantungan ke-n dapat menyebabkan longsornya masalah di layanan hulu. Selain itu, tanpa alat yang tepat, mustahil untuk memahami apa yang terjadi. Semua ini membuat proses debug menjadi sangat sulit.
Arsitektur layanan mikro Uber mulai pertengahan 2018 oleh Jaeger
Untuk mengimplementasikan fungsi yang paling sederhana, seorang insinyur sering kali harus bekerja dengan banyak layanan, sementara tim dan orang yang sama sekali berbeda bertanggung jawab untuk itu. Akibatnya, banyak waktu dihabiskan untuk mengatur kerja tim, rapat, konsultasi desain, dan tinjauan kode (tinjauan inti). Manfaat awal dari transparansi kepemilikan secara bertahap menjadi kabur karena tim terus-menerus menyerang layanan satu sama lain, mengubah model data, dan bahkan menerapkan atas nama pemilik layanan. Ini dapat membuat monolit jaringan di mana layanan hanya tampak independen, tetapi pada kenyataannya mereka harus diterapkan bersama untuk membuat perubahan apa pun dengan aman.
Contoh sistem yang begitu kompleks di Uber (~ 2018) dengan sepuluh poin kontak untuk integrasi yang mudah (bahkan sebelum DOMA).
Akibatnya, kami mengalami perlambatan dalam proses pengembangan, ketidakstabilan melanda pemilik layanan, migrasi yang lebih memakan waktu, dll. Sayangnya, organisasi yang telah beralih ke MA tidak dapat dipungkiri lagi. Situasi ini diilustrasikan dengan sempurna oleh ungkapan terkenal: " Tidak mungkin tinggal bersama mereka, dan Anda tidak bisa menembak mereka ."
Arsitektur layanan mikro khusus domain
Bayangkan layanan mikro sebagai pustaka yang terhubung dengan I / O, dan arsitektur layanan mikro sebagai aplikasi besar yang terdistribusi. Dalam hal ini, kita dapat menggunakan solusi arsitektur terkenal untuk memikirkan cara terbaik untuk mengatur kode kita.
Dengan demikian, Arsitektur Layanan Mikro Berorientasi Domain (DOMA) dapat mengandalkan cara-cara yang mapan untuk mengatur kode seperti Desain Berorientasi Domain , Arsitektur Bersih , Arsitektur Berorientasi Layanan , dan Pola Pengembangan Berorientasi Objek dan Berorientasi Antarmuka.Kami melihat DOMA sebagai inovatif dalam arti bahwa ini adalah cara yang relatif baru untuk memanfaatkan prinsip desain yang ada dalam sistem organisasi besar yang terdistribusi secara global .
Berikut adalah beberapa konsep DOMA dasar dan terminologi terkait:
- Alih-alih melihat layanan mikro individu, kami melihat kelompok mereka. Dan kami menyebutnya domain (domain) .
- Selanjutnya, kami menggabungkan domain yang disebut lapisan (lapisan) . Lapisan yang dimiliki domain menentukan dependensi mana yang tersedia untuk layanan mikro di domain itu. Kami menyebut arsitektur yang dihasilkan dari multi-layer (desain lapisan) .
- , . (gateways).
- , , , 'hardcode' , . (, - ), (extension architecture) .
Dengan kata lain, arsitektur terstruktur, gerbang domain, dan titik ekstensi DOMA yang dibuat sebelumnya mengubah arsitektur layanan mikro dari sesuatu yang kompleks menjadi sesuatu yang dapat dipahami dan berwujud: sekumpulan komponen terstruktur yang fleksibel, dapat digunakan kembali, dan berlapis.
Sisa artikel ini akan fokus pada implementasi Uber atas DOMA dan manfaatnya. Saran praktis juga akan diberikan kepada perusahaan yang ingin mengadopsi pendekatan ini.
Implementasi di Uber
Domain
Domain Uber adalah kumpulan dari satu atau beberapa layanan mikro yang ditautkan bersama berdasarkan kombinasi fungsionalitas yang logis. Pertanyaan yang muncul secara alami, seberapa besar seharusnya domain tersebut. Dalam hal ini, kami tidak memberikan instruksi apa pun. Beberapa domain dapat menyertakan lusinan layanan, yang lainnya hanya satu. Penting di sini untuk memikirkan dengan hati-hati tentang peran logis dari setiap asosiasi. Misalnya, kami telah mengelompokkan layanan pencarian di peta, layanan tarif, layanan pemilihan (membandingkan pengemudi dan penumpang) ke dalam domain terpisah. Apalagi mereka tidak selalu mengulang struktur organisasi perusahaan. Uber Maps dibagi menjadi tiga domain dengan 80 layanan mikro tersembunyi di balik tiga gateway berbeda.
Arsitektur berbasis lapisan
Arsitektur multilayer menjawab pertanyaan tentang layanan mana dan layanan mana yang dapat dikomunikasikan dalam batas-batas MA Uber. Artinya, ini dapat dilihat sebagai distribusi global area tanggung jawab atau sebagai mekanisme untuk manajemen ketergantungan global.
Arsitektur berlapis membantu untuk memahami radius kerusakan setelah kegagalan dan mencerminkan kekhususan produk dalam hal jumlah layanan yang bergantung pada Uber. Saat Anda berpindah dari bawah ke atas, jumlah layanan yang terpengaruh jika terjadi kegagalan akan berkurang dan cakupan aplikasi produk menyempit . Dan sebaliknya, jumlah layanan yang lebih besar bergantung pada fungsionalitas di tingkat yang lebih rendah, oleh karena itu, radius kerusakan akibat kegagalan, sebagai aturan, lebih besar, dan cakupan tugas bisnis yang harus diselesaikan lebih luas. Gambar di bawah mengilustrasikan konsep ini.
Anda dapat membayangkan bahwa tingkat atas difokuskan pada fungsi yang bertanggung jawab untuk pengalaman pengguna tertentu (sempit) (misalnya, fungsi seluler), sedangkan tingkat yang lebih rendah dihuni oleh fungsi bisnis yang lebih global (misalnya, pengelolaan akun atau perjalanan melalui pasar ridesharing) ... Setiap lapisan hanya bergantung pada lapisan yang mendasarinya, yang memberikan kejelasan pada konsep seperti radius ledakan dan integrasi domain.
Perlu dicatat bahwa fungsionalitas sering kali bergerak ke bawah dalam bagan ini, dari sempit ke lebih lebar. Anda dapat membayangkan beberapa fungsi sederhana yang menjadi lebih penting ("platform") seiring waktu seiring dengan berkembangnya persyaratan. Faktanya, migrasi ke bawah semacam ini sudah diperkirakan, dan banyak platform bisnis inti Uber dimulai sebagai fitur bagi pengemudi atau penumpang, dan seiring waktu berkembang dan menjadi lebih umum sebagai lini bisnis baru (seperti Uber Eats atau Uber Freight). ) dan menghubungkan lebih banyak dependensi ke sana.
Dalam Uber, kami membedakan lima level berikut.
- . , . — Uber , .
- -. , Uber , , Rides (), Eats ( ) Freight ( ).
- . , , . , «request a ride» ( ) , Rides: Rider, Rider «Lite», m.uber.com, ..
- . , (/), .
- . Uber . .
Seperti yang Anda lihat, setiap level berikutnya mewakili kombinasi fungsi yang semakin sempit dan memiliki radius klik yang lebih kecil (dengan kata lain, lebih sedikit komponen yang bergantung pada fungsionalitas dalam lapisan ini).
Gateway
Istilah API gateway sudah mapan dalam arsitektur layanan mikro. Definisi kami tidak jauh berbeda dari definisi yang sudah mapan - kecuali bahwa kami cenderung menganggap gateway sebagai titik masuk tunggal ke grup layanan yang sesuai (yang kami sebut domain ). Keberhasilan gateway bergantung pada arsitektur API yang dirancang dengan baik:
Diagram ini menggambarkan desain gateway tingkat tinggi. Ini mengabstraksi dari detail struktur internal domain: satu set layanan, tabel dengan data, pipeline ETL, dll. Domain lain hanya memiliki akses ke antarmuka: API untuk panggilan prosedur jarak jauh, peristiwa, dan permintaan dalam sistem perpesanan.
Karena konsumen hulu hanya berjalan pada satu layanan, gateway memberikan banyak manfaat dalam hal migrasi di masa mendatang , kemudahan untuk ditemukan , dan pengurangan keseluruhan kompleksitas sistem ketika layanan hulu hanya memiliki satu ketergantungan (alih-alih bergantung pada beberapa layanan hilir yang mungkin ada di domain). Jika dilihat dari perspektif desain OO, gateway adalah definisi antarmuka dan memungkinkan kita melakukan apa pun yang kita inginkan dengan "implementasi" internal (yaitu, sekelompok layanan mikro).
Ekstensi
Extensions (ekstensi) , sesuai dengan namanya, merupakan mekanisme perluasan domain. Definisi dasar dari add-on tersebut adalah bahwa add-on menyediakan mekanisme untuk memperluas fungsionalitas layanan tanpa mengubah internal layanan tersebut atau memengaruhi keandalannya secara keseluruhan. Di Uber kami memiliki dua model ekspansi: logika (ekstensi logika) dan berdasarkan data (data ekstensi) . Konsep ekstensi memungkinkan kami untuk menskalakan arsitektur sehingga beberapa tim dapat bekerja secara independen satu sama lain.
Ekstensi logis
Ekstensi logis menyediakan mekanisme untuk memperluas logika yang mendasari layanan. Untuk mereka, kami menggunakan semacam penyedia atau pola plugin dengan antarmuka yang ditentukan secara terpisah untuk setiap layanan. Hal ini memungkinkan tim untuk mengimplementasikan logika mereka hanya dengan menggunakan antarmuka dan tanpa mengganggu kode platform utama.
Misalkan, misalnya, pengemudi sedang online. Kami biasanya melakukan berbagai pemeriksaan untuk memastikan mereka diizinkan berstatus online (keamanan, kepatuhan, dll.). Masing-masing memiliki tim sendiri. Salah satu cara yang mungkin untuk melakukannya adalah dengan memaksa setiap perintah untuk menulis logika pada titik akhir yang sama, tetapi ini dapat menambah kompleksitas. Setiap pemeriksaan akan membutuhkan logika yang berbeda - dan sama sekali tidak terkait -.
Dalam kasus ekstensi titik akhir logis yang disebut go onlineakan menentukan antarmuka yang setiap ekstensi diharapkan untuk menyesuaikan dengan permintaan yang telah ditentukan dan jenis respons. Setiap tim akan mendaftarkan ekstensi yang akan bertanggung jawab untuk mengimplementasikan logika ini. Dalam hal ini, mereka cukup mengambil beberapa informasi tentang driver dan mengembalikan nilai logika (bool) , yang akan menentukan apakah driver tersebut "layak" untuk status online atau tidak. Dan titik akhir itu sendiri (daring) hanya akan mengulangi jawaban-jawaban ini dan menentukan jika ada yang salah .
Pendekatan ini memisahkan kode inti dari ekstensi dan menyediakan isolasi di antara keduanya. Namun, ekstensi tidak mengetahui logika lain apa yang sedang dijalankan. Ini memudahkan pembuatan fungsionalitas tambahan, misalnya untuk pengamatan atau penandaan fitur .
Ekstensi berbasis data
Jenis ekstensi ini menyediakan mekanisme untuk melampirkan data arbitrer ke antarmuka untuk menghindari membengkaknya model data platform yang mendasarinya secara tidak perlu. Di ekstensi data, kami secara aktif menggunakan fitur seperti Any from Protobuf, yang memungkinkan penambahan data arbitrer ke permintaan. Layanan sering kali menyimpan data ini atau meneruskannya ke ekstensi logis, sehingga platform utama tidak pernah melakukan deserialisasi (dan karenanya tidak "tahu" apa pun) tentang konteks arbitrer ini. Setiap implementasi menimbulkan beberapa overhead infrastruktur sebagai imbalan untuk pengetikan yang lebih kuat. Alternatif yang lebih sederhana adalah format JSON untuk mewakili data apa pun:
Pelengkap sewenang-wenang
Selain boolean dan ekstensi data, banyak tim di Uber telah mengembangkan template ekstensi khusus agar sesuai dengan domain mereka. Misalnya, sebagian besar integrasi yang terkait dengan arsitektur presentasi menggunakan logika eksekusi tugas berbasis DAG.
Manfaat
DOMA telah memengaruhi hampir setiap bisnis utama Uber sampai tingkat tertentu. Selama setahun terakhir, kami terutama berfokus pada lapisan bisnis. Ini memberikan logika umum untuk berbagai lini bisnis di sebuah perusahaan.
DOMA relatif baru di Uber, dan di masa mendatang kami pasti akan membagikan lebih banyak informasi dan contoh arsitektur kami. Hasil pertama sangat menggembirakan: mereka sangat menyederhanakan pekerjaan pengembang dan mengurangi keseluruhan kompleksitas sistem.
Produk dan platform
DOMA adalah hasil upaya kolaboratif antara berbagai tim produk dan platform di Uber. Dalam banyak kasus, biaya dukungan platform turun dalam urutan besarnya. Tim produk mendapat manfaat dari kekhususan dan pengembangan yang dipercepat.
Misalnya, konsumen platform awal arsitektur ekstensi kami dapat mengurangi waktu yang diperlukan untuk memprioritaskan dan mengintegrasikan fitur baru dari tiga hari menjadi tiga jam dengan mengurangi waktu peninjauan kode, penjadwalan, dan mempercepat pendidikan konsumen.
Kompleksitas berkurang
Sebelumnya, tim produk harus bekerja dengan banyak layanan hilir dalam domain, tetapi sekarang mereka hanya perlu memanggil satu. Dengan mengurangi jumlah titik kontak saat memperkenalkan fitur baru, waktu penerapan telah berkurang 25-30%. Selain itu, kami dapat mendistribusikan 2.200 layanan di 70 domain. Sekitar setengahnya telah dilaksanakan, dan sebagian besar ada rencana implementasi dalam satu bentuk atau lainnya.
Migrasi masa depan
Di Uber, kami telah menghitung bahwa layanan mikro memiliki waktu paruh 1,5 tahun. Dengan kata lain, setiap setengah tahun, 50% layanan kami kehilangan relevansinya. Tanpa gateway, arsitektur layanan mikro bisa menjadi neraka migrasi. Layanan mikro yang selalu berubah membutuhkan migrasi upstream yang konstan. Gateway memungkinkan tim menghindari ketergantungan pada layanan domain hilir, yang berarti layanan ini dapat berubah tanpa harus bermigrasi ke hulu.
Dua peningkatan platform terbesar Uber selama setahun terakhir terjadi di balik gateway. Platform ini memiliki ratusan layanan yang bergantung, dan tanpa gateway, semua konsumen yang ada harus dipindahkan. Ini akan menjadi sangat mahal, membuat desain ulang platform yang lengkap tidak realistis.
Lini bisnis dan produk baru
Kerangka kerja berbasis DOMA telah terbukti jauh lebih dapat dikembangkan dan lebih mudah dipelihara. Sebagian besar tim di Uber yang beralih ke DOMA melakukannya karena terlalu mahal untuk mempertahankan lini bisnis baru.
Saran praktis
Di bagian ini, saya telah mengumpulkan beberapa tip praktis untuk perusahaan yang mungkin tertarik dengan DOMA. Prinsip yang memandu di sini adalah, menurut pengalaman kami, arsitektur layanan mikro yang matang dan bijaksana didasarkan pada perubahan bertahap ke arah yang benar pada waktu yang tepat. Pada kenyataannya, hampir tidak mungkin untuk "menulis ulang" MA sepenuhnya.
Oleh karena itu, kami memandang evolusi MA sebagai semacam proses "memotong pagar", berkat itu ia tumbuh ke arah yang benar, dan bukan sebagai upaya kemauan satu kali. Ini adalah proses yang dinamis dan bertahap.
Startup
Pertanyaan kuncinya di sini adalah: "Kapan kita harus pindah ke MA?" dan "Apakah ini masuk akal untuk organisasi kita?" Seperti yang kita lihat di atas, meskipun layanan mikro memberikan keuntungan operasional dalam organisasi dengan banyak insinyur, mereka juga menambah kompleksitas keseluruhan yang dapat mempersulit penerapan fitur baru.
Dalam organisasi kecil, keuntungan operasional tidak mungkin untuk mengimbangi peningkatan kompleksitas arsitektur. Selain itu, MA biasanya membutuhkan sumber daya teknik khusus untuk mendukungnya, yang mungkin terlalu mahal untuk perusahaan tahap awal atau kurang optimal dalam hal penentuan prioritas.
Karena itu, mungkin bijaksana untuk menunda transisi ke layanan mikro untuk sementara waktu. Jika organisasi memutuskan untuk beralih ke layanan mikro, sebaiknya gunakan analogi aplikasi terdistribusi besar dan pikirkan terlebih dahulu tentang membagi area masalah di antara layanan. Juga perlu diingat bahwa layanan mikro paling awal cenderung menjadi yang paling penting dan berumur paling lama, karena mereka menggambarkan bagian penting dari bisnis.
Bisnis menengah
Kegunaan MA meningkat di perusahaan menengah dengan banyak tim, di mana garis tanggung jawab secara bertahap kabur antara berbagai fungsi dan platform.
Di sinilah Anda dapat mulai memikirkan hierarki layanan mikro. Manajemen ketergantungan mungkin mengemuka karena beberapa layanan dapat menjadi jauh lebih penting untuk menjalankan bisnis dan lebih banyak tim akan bergantung padanya.
Investasi awal dalam platforming dapat membayar dividen nanti. Pembuatan platform bisnis yang tidak bergantung pada produk lain memungkinkan menghindari akumulasi utang teknis dan penetrasi logika produk yang sewenang-wenang ke dalam layanan utama platform. Mungkin pada tahap ini mekanisme penyuluhan harus diperkenalkan untuk mencapai tujuan ini.
Mengingat jumlah layanan mikro yang masih kecil, mungkin belum masuk akal untuk menggabungkannya. Namun, perlu dicatat di sini bahwa domain dalam konteks implementasi DOMA di Uber mungkin menyertakan satu layanan, jadi alur pemikiran "berorientasi domain" tetap tidak merugikan.
Bisnis besar
Organisasi teknik besar dapat memiliki ratusan spesialis, layanan mikro, dan banyak dependensi. Dalam kondisi inilah DOMA mencapai potensi penuhnya. Tentunya perusahaan seperti itu akan memiliki kelompok layanan mikro yang jelas yang dapat dengan mudah digabungkan ke dalam domain dengan gateway di depannya. Layanan lama sering kali memerlukan pemfaktoran ulang / penulisan ulang dan migrasi berikutnya. Artinya, gateway akan segera mulai membawa manfaat nyata dalam hal kemudahan migrasi (jika, tentu saja, sudah diterapkan).
Pentingnya hierarki yang transparan dan dapat dipahami juga akan meningkat: beberapa layanan akan menjadi "produk" untuk fungsi atau kelompok fungsi tertentu, sementara yang lain akan mendukung banyak produk dan bertindak sebagai "platform". Sangat penting pada tahap ini untuk memisahkan logika produk yang berubah-ubah dari platform untuk menghindari tekanan operasional yang besar pada tim platform, dan untuk meminimalkan risiko ketidakstabilan sistem global.
Pikiran terakhir
Di Uber, kami terus secara aktif mengembangkan DOMA karena lebih banyak tim yang bermigrasi ke sana. Ide utama di balik DOMA adalah bahwa arsitektur layanan mikro hanyalah satu program terdistribusi besar. Dan prinsip yang sama dapat diterapkan pada evolusinya seperti halnya perangkat lunak lain. DOMA hanyalah sebuah pendekatan untuk pemikiran praktis tentang prinsip-prinsip ini. Kami harap Anda merasa terbantu dan menantikan tanggapan Anda!
DOMA sendiri merupakan hasil upaya lintas fungsi yang dilakukan oleh hampir 60 teknisi dari semua divisi Uber. Saya ingin mengucapkan terima kasih yang khusus kepada orang-orang berikut atas kontribusinya pada pekerjaan ini selama 2 tahun terakhir:
Alex Zylman, Alexandre Wilhelm, Allen Lu, Ankit Srivastava, Anthony Tran, Anupam Dikshit, Anurag Biyani, Daniel Wolf, Deepti Chedda, Dmitriy Bryndin, Gaurav Tungatkar, Jacob Greenleaf, Jaikumar Ganesh, Jennie Ngyabuae, Joeoshinier , Kusha Kapoor, Linda Fu, Madan Thangavelu, Nimish Sheth, Parth Shah, Shawn Burke, Simon Newton, Steve Sherwood, Uday Kiran Medisetty dan Waleed Kadous.
Ucapan Terima Kasih: Karya ini menggabungkan banyak pola desain yang ada di industri untuk menyelesaikan masalah di Uber, dan juga menyarankan beberapa pola baru (seperti ekstensi). Kami berterima kasih kepada industri karena telah mengerjakannya. Kami juga berterima kasih kepada para insinyur Linkedin yang bekerja di Superblocks karena telah berbagi pengalaman mereka dengan kami.
PS dari penerjemah
Baca juga di blog kami:
- «: , Kubernetes»;
- « 2018 ».