Sugeng rawuh, Habr. Dina iki aku terus seri saka publikasi sing aku wrote khusus kanggo wiwitan stream anyar mesthi. .
Pambuka
Pilihan gaya arsitektur minangka salah sawijining keputusan teknis dhasar nalika mbangun sistem informasi. Ing seri artikel iki, aku ngusulake kanggo nganalisa gaya arsitektur sing paling populer kanggo aplikasi bangunan lan mangsuli pitakon babagan kapan gaya arsitektur sing paling disenengi. Ing proses presentasi, aku bakal nyoba nggambar rantai logis sing nerangake pangembangan gaya arsitektur saka monoliths menyang microservices.
Pungkasan, kita ngomong babagan macem-macem jinis monoliths lan panggunaan komponen kanggo mbangun, komponen mbangun lan komponen penyebaran. Kita ngerti arsitektur berorientasi layanan.
Saiki kita bakal nemtokake karakteristik utama arsitektur microservice.
Hubungane arsitektur
Sampeyan kudu ngerti manawa adhedhasar definisi sing diwenehake ing artikel sadurunge, layanan apa wae minangka komponen, nanging ora saben layanan minangka layanan mikro.
Karakteristik Arsitektur Microservice
Karakteristik utama arsitektur microservice yaiku:
- Diatur babagan Kapabilitas Bisnis
- Produk bukan Proyek
- Titik pungkasan sing cerdas lan pipa bisu
- Pamrentahan Desentralisasi
- Manajemen Data Desentralisasi
- Otomasi Infrastruktur
- Desain kanggo kegagalan
- Arsitektur kanthi pangembangan evolusi (Desain Evolusi)
Titik 1 asale saka arsitektur berorientasi layanan amarga layanan mikro minangka kasus layanan khusus. Titik liyane kudu dipikirake kanthi kapisah.
Diatur babagan Kapabilitas Bisnis
Saiki sampeyan kudu ngelingi hukum Conway: organisasi sing nggawe sistem ngatur arsitektur, nyalin struktur interaksi ing organisasi kasebut. Minangka conto, kita bisa ngelingi kasus nggawe compiler: tim pitung wong ngembangaken compiler pitu-pass, lan tim saka limang ngembangaken compiler limang pass.
Yen kita ngomong babagan monoliths lan microservices, banjur yen pembangunan diatur dening departemen fungsional (backend, frontend, administrator database), banjur kita njaluk monolith klasik.
Kanggo entuk layanan mikro, tim kudu diatur miturut kemampuan bisnis (pesenan, kiriman, tim katalog). Organisasi iki bakal ngidini tim fokus kanggo mbangun bagean tartamtu saka aplikasi kasebut.
Produk bukan Proyek
Pendekatan proyek ing ngendi tim nransfer fungsi sing dikembangake menyang tim liyane pancen ora cocog kanggo arsitektur microservice. Tim kudu ndhukung sistem sajrone siklus urip. Amazon, salah sawijining pimpinan ing implementasi layanan mikro, nyatakake: "sampeyan mbangun, sampeyan mbukak." Pendekatan produk ngidini tim ngrasakake kabutuhan bisnis.
Titik pungkasan sing cerdas lan pipa bisu
Arsitektur SOA menehi perhatian gedhe marang saluran komunikasi, utamane Bus Layanan Perusahaan. Kang asring ndadΓ©kakΓ© kanggo Erroneous Spaghetti Box, yaiku, kerumitan monolit dadi kerumitan sambungan antarane layanan. Arsitektur microservice mung nggunakake cara komunikasi sing prasaja.
Pamrentahan Desentralisasi
Keputusan penting babagan layanan mikro kudu ditindakake dening wong sing bener-bener ngembangake layanan mikro. Ing kene, keputusan utama tegese pilihan
basa pemrograman, metodologi penyebaran, kontrak antarmuka umum, lsp.
Manajemen Data Desentralisasi
Pendekatan standar, ing ngendi aplikasi kasebut gumantung ing basis data siji, ora bisa nganggep spesifik saben layanan tartamtu. MSA nyakup manajemen data sing terdesentralisasi, kalebu panggunaan macem-macem teknologi.
Otomasi Infrastruktur
MSA ndhukung proses penyebaran lan pangiriman sing terus-terusan. Iki mung bisa digayuh kanthi ngotomatisasi proses. Ing wektu sing padha, nyebarake akeh layanan ora katon kaya medeni. Proses penyebaran kudu dadi mboseni. Aspek kapindho ana hubungane karo manajemen layanan ing lingkungan produk. Tanpa otomatisasi, ngatur proses sing mlaku ing lingkungan operasi sing beda dadi ora mungkin.
Desain kanggo kegagalan
Akeh layanan MSA sing rawan gagal. Ing wektu sing padha, penanganan kesalahan ing sistem sing disebarake dudu tugas sing ora pati penting. Arsitektur aplikasi kudu tahan kanggo kegagalan kasebut. Rebecca Parsons nganggep penting banget yen kita ora nggunakake komunikasi sajrone proses ing antarane layanan; tinimbang, kita nggunakake HTTP kanggo komunikasi, sing ora bisa dipercaya.
Arsitektur kanthi pangembangan evolusi (Desain Evolusi)
Arsitektur sistem MSA kudu berkembang kanthi evolusi. Disaranake kanggo matesi owah-owahan sing perlu kanggo wates layanan siji. Dampak ing layanan liyane uga kudu digatekake. Pendekatan tradisional yaiku nyoba ngatasi masalah iki kanthi versi, nanging MSA nyaranake nggunakake versi ing
minangka pilihan pungkasan.
kesimpulan
Sawise kabeh kasebut ing ndhuwur, kita bisa ngrumusake apa microservices. Arsitektur Microservice minangka pendekatan kanggo ngembangake aplikasi siji minangka kumpulan layanan cilik, saben mlaku ing proses dhewe lan sesambungan liwat mekanisme entheng, asring sumber HTTP API. Layanan kasebut dibangun kanthi kapabilitas bisnis lan bisa digunakake kanthi mandiri kanthi lengkap
mekanisme panyebaran otomatis. Ana tingkat minimal manajemen terpusat layanan kasebut, sing bisa ditulis ing macem-macem basa pamrograman lan nggunakake teknologi panyimpenan data sing beda.
Source: www.habr.com