Kuring hayang nulis artikel dina topik arsitéktur microservice keur lila, tapi dua hal terus stopping kuring - nu salajengna kuring plunged kana topik, beuki eta seemed kuring yén naon anu kuring nyaho atra, sarta naon atuh '. t nyaho perlu diulik jeung diulik. Di sisi anu sanésna, kuring nyangka yén parantos aya anu kedah dibahas diantara pamiarsa anu lega. Janten pendapat alternatif wilujeng sumping.
Hukum Conway sareng hubungan antara bisnis, organisasi sareng sistem inpormasi
Sakali deui kuring bakal ngantepkeun kuring nyarios:
"Sakur organisasi anu ngadesain sistem (dina harti anu lega) bakal nampi desain anu strukturna réplikasi struktur tim dina organisasi éta."
- Melvyn Conway, 1967
Dina pamanggih kuring, hukum ieu leuwih gampang pakait sareng feasibility tina pangatur bisnis, tinimbang langsung kana sistem informasi. Hayu atuh ngajelaskeun kalawan conto. Anggap urang gaduh kasempetan bisnis anu cukup stabil kalayan siklus hirup anu panjangna sahingga masuk akal pikeun ngatur perusahaan (ieu sanés salah ketik, tapi kuring resep pisan istilah ieu anu kuring maling). sacara organisasi sareng prosés bakal pakait sareng bisnis ieu.
Orientasi bisnis sistem inpormasi
Hayu atuh ngajelaskeun kalawan conto. Hayu urang nyebutkeun aya kasempetan bisnis pikeun ngatur hiji bisnis ngajual pizza. Dina versi V1 (hayu urang sebut wae pre-informasi), parusahaan ieu pizzeria a, a cash register, sarta layanan pangiriman. Vérsi ieu lila-cicing dina kaayaan variability lingkungan low. Teras vérsi 2 ngagentos éta - langkung maju sareng tiasa ngagunakeun sistem inpormasi dina inti na pikeun bisnis sareng arsitektur monolithic. Sareng di dieu, dina pamanggih kuring, ngan ukur aya ketidakadilan anu dahsyat dina hubungan monoliths - disangka arsitéktur monolithic teu pakait jeung modél bisnis domain. Leres, upami kitu, sistem éta moal tiasa dianggo pisan - bertentangan sareng hukum Conway sareng akal sehat anu sami. Henteu, arsitéktur monolithic sapinuhna konsisten sareng modél bisnis dina tahap pangembangan bisnis ieu - kuring, tangtosna, hartosna tahap nalika sistem parantos didamel sareng dijalankeun. Ieu mangrupikeun kanyataan anu saé pisan yén henteu paduli pendekatan arsitéktur, boh arsitéktur berorientasi jasa vérsi 3 sareng arsitéktur microservices vérsi N bakal tiasa dianggo ogé. Naon nu nyekel?
Sagalana ngalir, sagalana robah, atawa microservices sarana pikeun merangan pajeulitna?
Sateuacan urang neraskeun, hayu urang tingali sababaraha kasalahpahaman ngeunaan arsitéktur microservice.
Proponents ngagunakeun pendekatan microservice mindeng ngajawab yén megatkeun monolith kana microservices simplifies pendekatan ngembangkeun ku cara ngurangan basis kode jasa individu. Dina pamanggih kuring, pernyataan ieu omong kosong lengkep. Serius, interaksi atra dina kode monolith sareng homogen sigana rumit? Upami ieu leres-leres, sadaya proyék mimitina bakal diwangun salaku microservices, sedengkeun prakték nunjukkeun yén migrasi ti monolith ka microservices langkung umum. Pajeulitna henteu ngaleungit; éta ngan saukur mindahkeun tina modul individu ka antarmuka (naha éta beus data, RPC, API, sareng protokol sanés) sareng sistem orkestra. Sareng ieu sesah!
Kauntungannana ngagunakeun tumpukan hétérogén ogé questionable. Kuring moal ngajawab yén ieu ogé mungkin, tapi dina kanyataanana eta jarang lumangsung (Nempo payun - ieu kudu lumangsung - tapi rada salaku konsekuensi tinimbang hiji kaunggulan).
Daur hirup produk sareng daur hirup jasa
Tingali deui dina diagram di luhur. Henteu kabeneran yén kuring nyatet turunna siklus hirup tina versi anu misah tina bisnis - dina kaayaan modéren, nyaéta akselerasi transisi bisnis antara versi anu penting pikeun kasuksésanna. Kasuksésan produk ditangtukeun ku laju nguji hipotesis bisnis di jerona. Sareng di dieu, dina pamanggih kuring, perenahna kaunggulan konci arsitéktur microservice. Tapi hayu urang balik dina urutan.
Hayu urang ngaléngkah ka tahap salajengna dina évolusi sistem inpormasi - kana arsitektur berorientasi jasa tina SOA. Janten, dina sababaraha waktos kami disorot dina produk urang jasa lila-cicing - lila-cicing dina harti yén nalika pindah antara versi produk, aya kasempetan yén siklus hirup jasa bakal leuwih panjang batan siklus kahirupan versi salajengna produk. Éta logis pikeun henteu ngarobih aranjeunna - urang Anu penting nyaéta laju transisi ka versi salajengna. Tapi hanjakalna, urang kapaksa ngalakukeun parobihan konstan kana jasa - sareng di dieu sadayana dianggo pikeun kami, prakték DevOps, wadahisasi, sareng sajabana - sadayana anu aya dina pikiran. Tapi ieu masih sanés microservices!
Microservices minangka sarana pikeun merangan pajeulitna ... manajemén konfigurasi
Sarta di dieu urang tungtungna bisa ngaléngkah ka peran watesan microservices - ieu pendekatan nu simplifies manajemén konfigurasi produk. Dina leuwih jéntré, fungsi unggal microservice ngajelaskeun persis fungsi bisnis di jero produk nurutkeun model domain - sarta ieu hal anu hirup teu dina versi pondok-cicing, tapi dina kasempetan bisnis lila-cicing. Jeung transisi ka versi salajengna produk lumangsung sacara harfiah unnoticed - Anjeun ngarobah / nambahkeun hiji microservice, jeung sugan ngan skéma interaksi maranéhanana, sarta ujug-ujug anjeun manggihan diri di mangsa nu bakal datang, ninggalkeun balik nangis pesaing anu terus luncat antara versi monoliths maranéhanana. Ayeuna bayangkeun yén aya volume microservices anu cukup ageung kalayan antarmuka anu tos siap sareng kamampuan bisnis. Sareng anjeun sumping sareng ngawangun struktur produk anjeun tina jasa mikro siap-dijieun - ngan ukur ku ngagambar diagram, contona. Wilujeng - anjeun gaduh platform - sareng ayeuna anjeun tiasa narik bisnis pikeun diri anjeun. Ngimpi Ngimpi.
papanggihan
- Arsitéktur sistem kedah ditangtukeun ku siklus kahirupan komponénna. Upami komponén hirup dina versi produk, teu aya gunana pikeun ningkatkeun pajeulitna sistem ku ngagunakeun pendekatan microservice.
- Arsitéktur Microservice kedah dumasar kana modél domain - sabab kasempetan bisnis mangrupikeun domain pangpanjangna
- Prakték pangiriman (prakték DevOps) sareng orkestra mangrupikeun salah sahiji anu paling penting pikeun arsitéktur microservice - ku sabab naékna laju parobihan komponén nyababkeun paménta pikeun laju sareng kualitas pangiriman.
sumber: www.habr.com