Aku pengin nulis artikel babagan topik arsitektur microservice kanggo wektu sing suwe, nanging ana rong perkara sing tetep mandheg - luwih akeh aku nyemplungake topik kasebut, luwih-luwih yen aku ngerti apa sing aku ngerti, lan apa sing dakkarepake. t ngerti kudu sinau lan sinau. Ing sisih liya, aku mikir yen wis ana sing bisa dirembug ing antarane para pamirsa. Dadi panemu alternatif olèh.
Hukum Conway lan hubungan antarane bisnis, organisasi lan sistem informasi
Sepisan maneh aku bakal ngidini aku ngutip:
"Sembarang organisasi sing ngrancang sistem (ing pangertèn sing wiyar) bakal nampa desain sing strukturé niru struktur tim ing organisasi kasebut."
— Melvyn Conway, 1967
Ing mratelakake panemume, undang-undang iki luwih cenderung gegayutan karo kelayakan kanggo ngatur bisnis, tinimbang langsung menyang sistem informasi. Ayo kula nerangake karo conto. Ayo kita ngomong yen kita duwe kesempatan bisnis sing cukup stabil kanthi siklus urip sing dawa banget, sing ndadekake pangertèn kanggo ngatur perusahaan (iki dudu salah ketik, nanging aku seneng banget karo istilah iki sing dicolong). organisasi lan proses bakal cocog karo bisnis iki.
Orientasi bisnis sistem informasi
Ayo kula nerangake karo conto. Ayo dadi ngomong ana kesempatan bisnis kanggo ngatur bisnis adol pizza. Ing versi V1 (ayo diarani pra-informasi), perusahaan kasebut minangka pizzeria, mesin kasir, lan layanan pangiriman. Versi iki wis suwe umure ing kahanan variabilitas lingkungan sing sithik. Banjur versi 2 diganti - luwih maju lan bisa nggunakake sistem informasi ing inti kanggo bisnis kanthi arsitektur monolitik. Lan ing kene, miturut pendapatku, mung ana ketidakadilan sing nggegirisi babagan monoliths - dinuga arsitektur monolithic ora cocog karo model bisnis domain. Ya, yen mangkono, sistem kasebut ora bakal bisa digunakake - kanthi kontradiksi karo hukum lan akal sehat Conway sing padha. Ora, arsitektur monolitik kanthi konsisten karo model bisnis ing tahap pangembangan bisnis iki - Aku, mesthi, tegese tataran nalika sistem wis digawe lan dileksanakake. Kasunyatan sing apik banget yen ora preduli saka pendekatan arsitektur, arsitektur berorientasi layanan versi 3 lan arsitektur microservices versi N bakal bisa digunakake kanthi apik. Apa sing nyekel?
Kabeh mili, kabeh owah-owahan, utawa layanan mikro minangka sarana kanggo nglawan kerumitan?
Sadurunge nerusake, ayo goleki sawetara misconceptions babagan arsitektur microservice.
Para panyengkuyung nggunakake pendekatan microservice asring mbantah manawa ngrusak monolit dadi layanan mikro nyederhanakake pendekatan pangembangan kanthi nyuda basis kode layanan individu. Miturut pendapatku, statement iki pancen omong kosong. Serius, interaksi sing jelas ing kode monolit lan homogen katon rumit? Yen iki pancene kedadeyan, kabeh proyek bakal dibangun minangka layanan mikro, dene praktik nuduhake yen migrasi saka monolit menyang layanan mikro luwih umum. Kompleksitas ora ilang; mung pindhah saka modul individu menyang antarmuka (dadi bus data, RPC, API, lan protokol liyane) lan sistem orkestra. Lan iki angel!
Kauntungan saka nggunakake tumpukan heterogen uga dipertanyakan. Aku ora argue sing iki uga bisa, nanging ing kasunyatan iku arang occurs (Looking ahead - iki kudu kelakon - nanging rodo minangka akibat saka kauntungan).
Siklus urip produk lan siklus urip layanan
Deleng liyane ing diagram ing ndhuwur. Ora ana kebetulan yen aku nyathet siklus urip sing mudhun saka versi bisnis sing kapisah - ing kahanan modern, yaiku percepatan transisi bisnis antarane versi sing nemtokake sukses. Sukses produk ditemtokake dening kacepetan nguji hipotesis bisnis ing njero. Lan ing kene, miturut pendapatku, ana kauntungan utama arsitektur microservice. Nanging ayo padha pindhah ing urutan.
Ayo pindhah menyang tahap sabanjure ing evolusi sistem informasi - menyang arsitektur berorientasi layanan SOA. Dadi, ing sawetara titik tartamtu kita disorot ing produk kita layanan dawa-urip - dawa-urip ing pangertèn sing nalika obah antarane versi produk, ana kasempatan sing siklus urip layanan bakal maneh saka siklus urip saka versi sabanjuré produk. Iku bakal logis kanggo ora ngganti kabeh - kita Sing penting yaiku kacepetan transisi menyang versi sabanjure. Nanging sayangé, kita kepeksa nggawe owah-owahan terus-terusan ing layanan - lan ing kene kabeh bisa digunakake kanggo kita, praktik DevOps, containerization, lan liya-liyane - kabeh sing ana ing pikiran. Nanging iki isih dudu layanan mikro!
Microservices minangka sarana kanggo nglawan kerumitan ... manajemen konfigurasi
Lan ing kene pungkasane kita bisa pindhah menyang peran sing nemtokake microservices - iki minangka pendekatan sing nyederhanakake manajemen konfigurasi produk. Kanthi luwih rinci, fungsi saben layanan mikro njlèntrèhaké persis fungsi bisnis ing produk miturut model domain - lan iki minangka barang sing ora urip ing versi sing cendhak, nanging ing kesempatan bisnis sing dawa. Lan transisi menyang versi sabanjure prodhuk kelakon secara harfiah unnoticed - sampeyan ngganti / nambah siji microservice, lan mbok menawa mung rencana interaksi, lan dumadakan sampeyan nemokake dhewe ing mangsa, ninggalake konco nangis saingan sing terus mlumpat antarane versi saka monoliths sing. Saiki bayangake manawa ana volume layanan mikro sing cukup gedhe kanthi antarmuka lan kapabilitas bisnis sing wis ditemtokake. Lan sampeyan teka lan mbangun struktur produk saka layanan mikro sing wis siap - mung kanthi nggambar diagram, umpamane. Sugeng - sampeyan duwe platform - lan saiki sampeyan bisa narik bisnis dhewe. Impen Impen.
temonan
- Arsitektur sistem kasebut kudu ditemtokake dening siklus urip komponen kasebut. Yen komponen urip ing versi produk, ora ana gunane nambah kerumitan sistem kanthi nggunakake pendekatan microservice.
- Arsitektur microservice kudu adhedhasar model domain - amarga kesempatan bisnis minangka domain paling dawa
- Praktek pangiriman (praktik DevOps) lan orkestrasi minangka salah sawijining sing paling penting kanggo arsitektur layanan mikro - amarga kenaikan tingkat owah-owahan komponen nyebabake panjaluk kacepetan lan kualitas pangiriman.
Source: www.habr.com