Jau sen gribÄju uzrakstÄ«t rakstu par mikropakalpojumu arhitektÅ«ras tÄmu, taÄu mani apturÄja divas lietas - jo dziļÄk iedziļinÄjos tÄmÄ, jo vairÄk man Ŕķita, ka tas, ko es zinu, ir paÅ”saprotami, un tas, ko es zinu. t zinÄt, ir jÄpÄta un jÄmÄcÄs. No otras puses, es domÄju, ka jau ir par ko apspriest plaÅ”u auditoriju. TÄpÄc alternatÄ«vi viedokļi ir apsveicami.
Konveja likums un attiecÄ«bas starp biznesu, organizÄciju un informÄcijas sistÄmu
VÄlreiz atļauÅ”os citÄt:
"Jebkura organizÄcija, kas izstrÄdÄ sistÄmu (plaÅ”Ä nozÄ«mÄ), saÅems dizainu, kura struktÅ«ra atkÄrto Ŕīs organizÄcijas komandu struktÅ«ru."
ā Melvins Konvejs, 1967. gads
ManuprÄt, Å”is likums drÄ«zÄk saistÄs ar biznesa organizÄÅ”anas iespÄjamÄ«bu, nevis tieÅ”i ar informÄcijas sistÄmu. Ä»aujiet man paskaidrot ar piemÄru. Teiksim, mums ir diezgan stabila biznesa iespÄja ar tÄdu dzÄ«ves ciklu, ka ir jÄga organizÄt uzÅÄmumu (Ŕī nav drukas kļūda, bet man ļoti patÄ«k Å”is manis nozagtais termins). Protams, Ŕī biznesa atbalsta sistÄma organizatoriski un procesuÄli atbildÄ«s Å”im biznesam.
InformÄcijas sistÄmu biznesa orientÄcija
Ä»aujiet man paskaidrot ar piemÄru. PieÅemsim, ka pastÄv biznesa iespÄja organizÄt biznesu, kas pÄrdod picu. V1 versijÄ (sauksim to par iepriekÅ”Äju informÄciju) uzÅÄmums bija picÄrija, kases aparÄts un piegÄdes serviss. Å Ä« versija bija ilgstoÅ”a zemas vides mainÄ«guma apstÄkļos. PÄc tam to aizstÄja 2. versija ā progresÄ«vÄka un spÄj izmantot informÄcijas sistÄmu savÄ pamatÄ uzÅÄmÄjdarbÄ«bai ar monolÄ«tu arhitektÅ«ru. Un Å”eit, manuprÄt, ir vienkÄrÅ”i briesmÄ«ga netaisnÄ«ba attiecÄ«bÄ uz monolÄ«tiem - it kÄ monolÄ«ta arhitektÅ«ra neatbilst domÄna biznesa modelim. JÄ, ja tas tÄ bÅ«tu, sistÄma vispÄr nevarÄtu darboties ā pretrunÄ ar to paÅ”u Konveja likumu un veselo saprÄtu. NÄ, monolÄ«tÄ arhitektÅ«ra pilnÄ«bÄ atbilst biznesa modelim Å”ajÄ biznesa attÄ«stÄ«bas stadijÄ - es, protams, domÄju posmu, kad sistÄma jau ir izveidota un nodota ekspluatÄcijÄ. Tas ir absolÅ«ti brÄ«niŔķīgs fakts, ka neatkarÄ«gi no arhitektÅ«ras pieejas vienlÄ«dz labi darbosies gan uz servisu orientÄtÄs arhitektÅ«ras versija 3, gan mikropakalpojumu arhitektÅ«ras versija N. KÄds ir loms?
Viss plÅ«st, viss mainÄs, vai arÄ« mikropakalpojumi ir lÄ«dzeklis, lai cÄ«nÄ«tos pret sarežģītÄ«bu?
Pirms turpinÄm, aplÅ«kosim dažus nepareizus priekÅ”status par mikropakalpojumu arhitektÅ«ru.
Mikropakalpojumu pieejas izmantoÅ”anas atbalstÄ«tÄji bieži apgalvo, ka monolÄ«ta sadalÄ«Å”ana mikropakalpojumos vienkÄrÅ”o attÄ«stÄ«bas pieeju, samazinot atseviŔķu pakalpojumu kodu bÄzi. ManuprÄt, Å”is apgalvojums ir pilnÄ«gs absurds. Ja nopietni, acÄ«mredzamÄ mijiedarbÄ«ba monolÄ«tÄ un viendabÄ«gÄ kodÄ Å”Ä·iet sarežģīta? Ja tas tÄ patieÅ”Äm bÅ«tu, visi projekti sÄkotnÄji tiktu veidoti kÄ mikropakalpojumi, savukÄrt prakse rÄda, ka migrÄcija no monolÄ«ta uz mikropakalpojumiem ir daudz izplatÄ«tÄka. SarežģītÄ«ba nepazÅ«d; tÄ vienkÄrÅ”i pÄriet no atseviŔķiem moduļiem uz saskarnÄm (datu kopnÄm, RPC, API vai citiem protokoliem) un orÄ·estrÄÅ”anas sistÄmÄm. Un tas ir grÅ«ti!
ApÅ”aubÄma ir arÄ« neviendabÄ«gas kaudzes izmantoÅ”anas priekÅ”rocÄ«ba. Es neapstrÄ«dÄÅ”u, ka arÄ« tas ir iespÄjams, bet patiesÄ«bÄ tas notiek reti (skatoties uz priekÅ”u - tam vajadzÄtu notikt, bet drÄ«zÄk kÄ sekas, nevis priekÅ”rocÄ«bas).
Produkta dzīves cikls un pakalpojuma dzīves cikls
VÄlreiz apskatiet iepriekÅ” redzamo diagrammu. Ne velti atzÄ«mÄju atseviŔķas biznesa versijas dzÄ«ves cikla samazinÄÅ”anos - mÅ«sdienu apstÄkļos tieÅ”i biznesa pÄrejas starp versijÄm paÄtrinÄjums ir noteicoÅ”ais tÄ panÄkumiem. Produkta panÄkumus nosaka biznesa hipotÄžu pÄrbaudes Ätrums tajÄ. Un Å”eit, manuprÄt, slÄpjas galvenÄ mikropakalpojumu arhitektÅ«ras priekÅ”rocÄ«ba. Bet iesim kÄrtÄ«bÄ.
PÄriesim uz nÄkamo informÄcijas sistÄmu evolÅ«cijas posmu ā uz SOA servisu orientÄtu arhitektÅ«ru. TÄtad, kÄdÄ noteiktÄ brÄ«dÄ« mÄs izcÄlÄm mÅ«su produktu ilgstoÅ”i pakalpojumi - ilgmūžīgs tÄdÄ nozÄ«mÄ, ka, pÄrvietojoties starp produkta versijÄm, pastÄv iespÄja, ka pakalpojuma dzÄ«ves cikls bÅ«s garÄks nekÄ nÄkamÄs produkta versijas dzÄ«ves cikls. LoÄ£iski bÅ«tu tos nemaz nemainÄ«t ā mÄs SvarÄ«gs ir pÄrejas Ätrums uz nÄkamo versiju. Bet diemžÄl mÄs esam spiesti pastÄvÄ«gi mainÄ«t pakalpojumus - un Å”eit viss darbojas mÅ«su labÄ, DevOps prakse, konteinerizÄcija un tÄ tÄlÄk - viss, kas ienÄk prÄtÄ. Bet tie joprojÄm nav mikropakalpojumi!
Mikropakalpojumi kÄ lÄ«dzeklis cÄ«Åai pret sarežģītÄ«bu... konfigurÄcijas pÄrvaldÄ«ba
Un Å”eit mÄs beidzot varam pÄriet uz mikropakalpojumu noteicoÅ”o lomu - Ŕī ir pieeja, kas vienkÄrÅ”o produkta konfigurÄcijas pÄrvaldÄ«bu. SÄ«kÄk katra mikropakalpojuma funkcija apraksta tieÅ”i biznesa funkciju produkta iekÅ”ienÄ atbilstoÅ”i domÄna modelim - un tÄs ir lietas, kas dzÄ«vo nevis Ä«slaicÄ«gÄ versijÄ, bet gan ilgtermiÅa biznesa iespÄjÄs. Un pÄreja uz nÄkamo produkta versiju notiek burtiski nemanot - jÅ«s mainÄt/pievienojat vienu mikropakalpojumu un, iespÄjams, tikai to mijiedarbÄ«bas shÄmu, un pÄkÅ”Åi jÅ«s nonÄkat nÄkotnÄ, atstÄjot aiz sevis raudoÅ”us konkurentus, kuri turpina lÄkÄt starp versijÄm. to monolÄ«ti. Tagad iedomÄjieties, ka ir diezgan liels mikropakalpojumu apjoms ar iepriekÅ” definÄtÄm saskarnÄm un biznesa iespÄjÄm. Un jÅ«s nÄkat un veidojat sava produkta struktÅ«ru no gataviem mikropakalpojumiem ā vienkÄrÅ”i uzzÄ«mÄjot, piemÄram, diagrammu. Apsveicam, jums ir platforma, un tagad jÅ«s varat piesaistÄ«t biznesu sev. SapÅi SapÅi.
Atzinumi
- SistÄmas arhitektÅ«ra jÄnosaka tÄs komponentu dzÄ«ves ciklam. Ja komponents atrodas produkta versijÄ, nav jÄgas palielinÄt sistÄmas sarežģītÄ«bu, izmantojot mikropakalpojumu pieeju.
- Mikropakalpojumu arhitektÅ«ra jÄbalsta uz domÄna modeli, jo biznesa iespÄja ir visilgÄk dzÄ«vojoÅ”ais domÄns
- PiegÄdes prakse (DevOps prakse) un orÄ·estrÄÅ”ana ir viena no vissvarÄ«gÄkajÄm mikropakalpojumu arhitektÅ«rÄ ā tÄpÄc, ka komponentu maiÅas Ätruma pieaugums izvirza paaugstinÄtas prasÄ«bas piegÄdes Ätrumam un kvalitÄtei.
Avots: www.habr.com