Microservices minangka cara kanggo ngrusak aplikasi gedhe dadi modul sing digandhengake karo siji liyane liwat API sing prasaja.
Akhir-akhir iki, mung wong bodho sing ora ngomong babagan layanan mikro. Iki dadi luwih populer. Gaya arsitektur modular katon cocog banget karo lingkungan berbasis awan lan dadi populer. Sadurunge kita menyang rincian, ayo njupuk tampilan mripat manuk kabeh . Mulane: Microservices minangka cara kanggo ngilangi proyek gedhe dadi modul cilik, mandiri lan ora ana gandhengane. Modul independen tanggung jawab kanggo tugas sing ditetepake kanthi jelas lan diskrit lan komunikasi karo saben liyane liwat API sing gampang lan bisa diakses. Ing tembung liya, layanan mikro mung minangka gaya arsitektur sing beda kanggo ngrancang kompleks, biasane aplikasi web. Nanging apa sing ala babagan solusi arsitektur sing ana kayata SOA (Arsitektur berorientasi layanan)? Umume solusi perusahaan modern sing ditulis nggunakake SOA katon apik banget. Iki bisa dadi wektu sing apik kanggo ngomong babagan sawetara tantangan sing diadhepi industri saiki ... Ayo miwiti kanthi conto sing gampang. Ayo dadi ngomong aku kudu mbukak aplikasi klasik ditulis ing Jawa. Kaping pisanan, aku bakal ngembangake Antarmuka Panganggo, banjur lapisan logika bisnis, kanthi sawetara komponen sing bakal sesambungan karo UI, lan pungkasane lapisan database, sing bakal bisa diakses kanggo database sing terus-terusan. Saiki miturut kasunyatan yen aku pengin mbukak aplikasi kasebut, aku bakal nggawe WAR / EAR / JAR lan dipasang ing server (kayata JBoss, Tomcat utawa WebLogic). Amarga iki rampung kabeh, aku entuk aplikasi monolitik, tegese kabeh komponen ana ing sak panggonan ... Conto ing gambar:
Paling kamungkinan, sampeyan wis menowo pendekatan iki lan wis digunakake, nanging idea kanggo nggunakake conto iki kanggo nuduhake apa tantangan pangembang bakal ngadhepi nggunakake solusi arsitektur iki. Aplikasi monolitik: tantangan tantangan
God Microservices kanggo ngluwari Salah sawijining ciri sing paling penting ing solusi arsitektur yaiku skalabilitas. Nalika aku sinau microservices kanggo pisanan, Aku weruh sing kabeh padha kaya kuotasi saka buku "The Art of Scalability". Iki minangka wiwitan lan papan kanggo diskusi. Buku iki nemtokake model sing disebut "Scalability Cube", sing nggambarake sistem skalabilitas telung dimensi:
Nalika sampeyan bisa ndeleng, sumbu X njlèntrèhaké "scaling horisontal" (kang kita wis katon uga kasedhiya kanggo arsitektur monolithic), sumbu Y nggantosi njongko ing pangertèn saka misahake komponen layanan beda . Gagasan sumbu Z dimangerteni nalika data dipérang lan aplikasi ngirim panjalukan menyang ngendi data kasebut dumunung. Tegese, ora kabeh ana ing sak panggonan. Gagasan sumbu Y yaiku sing bakal kita fokusake kanthi luwih rinci. Sumbu iki nggambarake dekomposisi fungsional . Ing strategi iki, macem-macem fungsi bisa dianggep minangka layanan mandiri. Mulane, kanthi masang kabeh aplikasi mung nalika kabeh wis rampung, pangembang bisa masang layanan individu kanthi mandiri lan ora ngenteni wong liya rampung nggarap modul kasebut. Iki ora mung bakal nambah wektu pembangunan, nanging uga nawakake keluwesan kanggo ngganti lan rewire tanpa sumelang ing bab liyane saka komponen aplikasi. Ayo mbandhingake diagram iki karo monolitik sadurunge:
Microservices: Keuntungan Keuntungan saka microservices katon cukup kanggo gawe uwong yakin pangembang perusahaan kayata Amazon, Netflix, Ebay kanggo miwiti nggunakake pendekatan iki. Ora kaya aplikasi arsitektur monolitik, layanan mikro:
- Nalika aplikasi tuwuh, uga jumlah kode sing ditulis, sing bisa uga kakehan lingkungan pangembangan saben sampeyan kudu mbukak. Iki mesthi nyuda efisiensi pangembang.
- Amarga kabeh kudu dipasang ing sak panggonan, iki nyebabake kasunyatan manawa ngalih menyang basa pamrograman liyane utawa ngalih menyang teknologi liya minangka masalah gedhe. Contone, sampeyan nulis aplikasi ing Jawa, lan sawise sawetara wektu Kotlin metu lan sampeyan kepengin nulis maneh, amarga dipromosekake
dadiluwih adhem, luwih apik, luwih cepet. Kanthi aplikasi monolitik, malah mikir babagan refactoring bakal nyebabake rasa nyeri sing nyata, ora kanggo sebutno proses kasebut. Saiki ana akeh aplikasi sing digawe kanthi cara iki lan jumlah baris kode mung luar biasa. Yen salah sawijining komponen mandhegbisa digunakake kanthi alesan apa wae , kabeh aplikasi uga bakal nabrak. Bayangake yen ana aplikasi web sing duwe modul kayata wewenang, pambayaran, riwayat, lsp. Lan sakperangan alesan salah siji saka wong-wong mau break. Iki mung kejut kanggo bisnis lan, minangka asil, kanggo pangembang.- Scaling aplikasi monolithic mung bisa ngrambah dening mundhakaken aplikasi liyane saka jinis padha. Nanging apa yen sampeyan mung kudu ngukur siji komponen, lan ora kabeh aplikasi. Pira sumber daya sing bakal dibuwang?...
- Iki bisa nduwe pengaruh gedhe ing proses pangembangan lan proses instalasi aplikasi kasebut. Aplikasi sing luwih gedhe, luwih penting yen pangembang bisa mbagi aplikasi kasebut dadi bagean kerja sing luwih cilik. Amarga kabeh modul ing aplikasi monolithic disambungake kanggo saben liyane, pangembang ora bisa / Gunung modul iki independen saka saben liyane. Wiwit pangembang gumantung ing saben liyane, wektu pembangunan mundhak.
- Ngapikake isolasi kegagalan komponen: Aplikasi gedhe bisa terus mlaku kanthi efisien sanajan siji modul gagal.
- Ngilangi komitmen aplikasi kanggo siji tumpukan teknologi: yen sampeyan pengin nyoba tumpukan teknologi anyar ing sawetara layanan, terusake. Dependensi bakal luwih entheng tinimbang monolitik, lan uga bakal luwih gampang kanggo muter maneh kabeh. Kode kurang ing siji aplikasi, luwih gampang bisa digunakake.
- Ndadekake luwih gampang kanggo karyawan anyar kanggo ngerti fungsi saka layanan.
- Ngembangake sistem sing disebarake bisa dadi angel. Iki tegese kabeh komponen saiki dadi layanan mandiri - sampeyan kudu ngati-ati banget panjalukan sing ngliwati modul. Bisa uga ana skenario sing siji modul ora nanggapi, meksa sampeyan nulis kode tambahan supaya ora nabrak sistem. Iki bisa dadi luwih angel yen telpon remot sensitif latensi .
- Multiple database lan manajemen transaksi bisa dadi nyeri nyata.
- testing aplikasi microservice bisa dadi cumbersome. Nggunakake aplikasi monolitik, kita mung kudu mbukak arsip WAR / EAR / JAR ing server lan priksa manawa disambungake menyang database. Lan ing layanan mikro, saben layanan individu kudu diwiwiti sadurunge tes bisa diwiwiti.
- Aplikasi pemasangan bisa dadi angel. Bisa uga mbutuhake koordinasi babagan macem-macem layanan sing bisa uga ora gampang dipasang kaya wadhah WAR.
GO TO FULL VERSION