Nais kong magsulat ng isang artikulo sa paksa ng arkitektura ng microservice sa loob ng mahabang panahon, ngunit dalawang bagay ang patuloy na pumipigil sa akin - habang ako ay bumagsak sa paksa, mas tila sa akin na ang alam ko ay halata, at kung ano ang ginagawa ko. t alam kailangang pag-aralan at pag-aralan. Sa kabilang banda, sa palagay ko ay mayroon nang dapat talakayin sa malawak na madla. Kaya ang mga alternatibong opinyon ay malugod na tinatanggap.
Batas ng Conway at ang relasyon sa pagitan ng negosyo, organisasyon at sistema ng impormasyon
Muli kong hahayaan ang aking sarili na sumipi:
"Anumang organisasyon na nagdidisenyo ng isang sistema (sa malawak na kahulugan) ay makakatanggap ng isang disenyo na ang istraktura ay kinokopya ang istraktura ng mga koponan sa organisasyong iyon."
β Melvyn Conway, 1967
Sa aking opinyon, ang batas na ito ay mas malamang na nauugnay sa pagiging posible ng pag-aayos ng isang negosyo, sa halip na direkta sa sistema ng impormasyon. Hayaan akong ipaliwanag sa isang halimbawa. Sabihin nating mayroon tayong medyo matatag na pagkakataon sa negosyo na may tagal ng ikot ng buhay na makatuwiran na mag-organisa ng isang negosyo (hindi ito isang typo, ngunit talagang gusto ko ang terminong ito na ninakaw ko). Natural, ang sumusuportang sistema ng negosyong ito ay tumutugma sa organisasyonal at proseso sa negosyong ito.
Oryentasyon ng negosyo ng mga sistema ng impormasyon
Hayaan akong ipaliwanag sa isang halimbawa. Sabihin nating may pagkakataon sa negosyo na mag-organisa ng negosyong nagbebenta ng pizza. Sa bersyon ng V1 (tawagin natin itong pre-information), ang kumpanya ay isang pizzeria, isang cash register, at isang serbisyo sa paghahatid. Ang bersyon na ito ay matagal nang nabuhay sa mga kondisyon ng mababang pagbabago sa kapaligiran. Pagkatapos ay dumating ang bersyon 2 upang palitan ito - mas advanced at magagawang gumamit ng isang sistema ng impormasyon sa core nito para sa negosyo na may monolitikong arkitektura. At dito, sa palagay ko, mayroon lamang isang kakila-kilabot na kawalan ng katarungan na may kaugnayan sa mga monolith - diumano'y monolitikong arkitektura ay hindi tumutugma sa modelo ng negosyo ng domain. Oo, kung ito ay gayon, ang sistema ay hindi gagana sa lahat - sa kontradiksyon sa parehong batas at sentido komun ng Conway. Hindi, ang monolitikong arkitektura ay ganap na naaayon sa modelo ng negosyo sa yugtong ito ng pag-unlad ng negosyo - Ako, siyempre, ang ibig sabihin ay ang yugto kung kailan ang sistema ay nagawa na at naisagawa na. Ito ay isang ganap na kahanga-hangang katotohanan na anuman ang diskarte sa arkitektura, pareho ang bersyon 3 ng arkitektura na nakatuon sa serbisyo at ang bersyon ng arkitektura ng microservices N ay gagana nang maayos. Ano ang catch?
Lahat ay dumadaloy, lahat ay nagbabago, o ang mga microservice ay isang paraan upang labanan ang pagiging kumplikado?
Bago tayo magpatuloy, tingnan natin ang ilang maling kuru-kuro tungkol sa arkitektura ng microservice.
Ang mga tagapagtaguyod ng paggamit ng isang microservice na diskarte ay madalas na nangangatuwiran na ang pagsira ng isang monolith sa mga microservice ay pinapasimple ang pag-unlad na diskarte sa pamamagitan ng pagbabawas ng code base ng mga indibidwal na serbisyo. Sa aking opinyon, ang pahayag na ito ay ganap na walang kapararakan. Seryoso, ang halatang pakikipag-ugnayan sa loob ng isang monolith at homogenous na code ay tila kumplikado? Kung ganito talaga ang sitwasyon, lahat ng proyekto ay unang itatayo bilang mga microservice, habang ipinapakita ng kasanayan na ang paglipat mula sa isang monolith patungo sa mga microservice ay mas karaniwan. Hindi nawawala ang pagiging kumplikado; lumilipat lang ito mula sa mga indibidwal na module patungo sa mga interface (maging mga data bus, RPC, API, at iba pang protocol) at mga sistema ng pag-orkestra. At ito ay mahirap!
Ang bentahe ng paggamit ng isang heterogenous stack ay kaduda-dudang din. Hindi ako magtatalo na posible rin ito, ngunit sa katotohanan ay bihirang mangyari ito (Pagtingin sa hinaharap - dapat itong mangyari - ngunit sa halip bilang isang resulta kaysa sa isang kalamangan).
Ikot ng buhay ng produkto at ikot ng buhay ng serbisyo
Tingnan muli ang diagram sa itaas. Ito ay hindi nagkataon na napansin ko ang bumababa na ikot ng buhay ng isang hiwalay na bersyon ng isang negosyo - sa mga modernong kondisyon, ito ay ang pagpabilis ng paglipat ng isang negosyo sa pagitan ng mga bersyon na mapagpasyahan para sa tagumpay nito. Ang tagumpay ng isang produkto ay tinutukoy ng bilis ng pagsubok ng mga hypotheses ng negosyo dito. At dito, sa aking opinyon, namamalagi ang pangunahing bentahe ng microservice architecture. Ngunit pumunta tayo sa pagkakasunud-sunod.
Lumipat tayo sa susunod na yugto sa ebolusyon ng mga sistema ng impormasyon - sa arkitektura na nakatuon sa serbisyo ng SOA. Kaya, sa ilang partikular na punto ay na-highlight namin sa aming produkto pangmatagalang serbisyo - matagal nang nabubuhay sa kahulugan na kapag lumipat sa pagitan ng mga bersyon ng isang produkto, may posibilidad na ang ikot ng buhay ng serbisyo ay mas mahaba kaysa sa ikot ng buhay ng susunod na bersyon ng produkto. Magiging lohikal na huwag baguhin ang mga ito - kami Ang mahalaga ay ang bilis ng paglipat sa susunod na bersyon. Ngunit sayang, napipilitan kaming gumawa ng mga patuloy na pagbabago sa mga serbisyo - at dito gumagana ang lahat para sa amin, mga kasanayan sa DevOps, containerization, at iba pa - lahat ng naiisip. Ngunit hindi pa rin ito mga microservice!
Microservices bilang isang paraan upang labanan ang pagiging kumplikado... pamamahala ng configuration
At dito na tayo sa wakas ay makakapagpatuloy sa pagtukoy sa papel ng mga microservice - ito ay isang diskarte na nagpapasimple sa pamamahala ng configuration ng produkto. Sa higit pang detalye, eksaktong inilalarawan ng function ng bawat microservice ang function ng negosyo sa loob ng produkto ayon sa modelo ng domain - at ito ang mga bagay na hindi nabubuhay sa panandaliang bersyon, ngunit sa pangmatagalang pagkakataon sa negosyo. At literal na hindi napapansin ang paglipat sa susunod na bersyon ng produkto - binago mo/nagdagdag ka ng isang microservice, at marahil ay ang pamamaraan lamang ng kanilang pakikipag-ugnayan, at bigla mong makikita ang iyong sarili sa hinaharap, na iniiwan ang umiiyak na mga kakumpitensya na patuloy na tumatalon sa pagitan ng mga bersyon ng kanilang mga monolith. Ngayon isipin na mayroong isang medyo malaking dami ng mga microservice na may paunang natukoy na mga interface at mga kakayahan sa negosyo. At darating ka at bubuo ng istraktura ng iyong produkto mula sa mga yari na microservice - sa pamamagitan lamang ng pagguhit ng diagram, halimbawa. Binabati kita - mayroon kang isang platform - at ngayon ay maaari mong maakit ang negosyo para sa iyong sarili. Pangarap Pangarap.
Natuklasan
- Ang arkitektura ng system ay dapat matukoy sa pamamagitan ng ikot ng buhay ng mga bahagi nito. Kung ang isang bahagi ay nabubuhay sa loob ng isang bersyon ng produkto, walang punto sa pagtaas ng pagiging kumplikado ng system sa pamamagitan ng paggamit ng isang microservice approach.
- Ang arkitektura ng microservice ay dapat na nakabatay sa modelo ng domain - dahil ang pagkakataon sa negosyo ay ang pinakamatagal na nabubuhay na domain
- Ang mga kasanayan sa paghahatid (Mga kasanayan sa DevOps) at orkestra ay isa sa pinakamahalaga para sa arkitektura ng microservice - sa kadahilanang ang pagtaas sa rate ng pagbabago ng mga bahagi ay naglalagay ng mga pangangailangan sa bilis at kalidad ng paghahatid.
Pinagmulan: www.habr.com