JÅ«s esat pavadÄ«jis mÄneÅ”us, pÄrveidojot savu monolÄ«tu par mikropakalpojumiem, un beidzot visi ir sanÄkuÅ”i kopÄ, lai pÄrslÄgtu slÄdzi. JÅ«s dodaties uz pirmo tÄ«mekļa lapu... un nekas nenotiek. JÅ«s to ielÄdÄjat atkÄrtoti - un atkal nekas labs, vietne ir tik lÄna, ka tÄ nereaÄ£Ä vairÄkas minÅ«tes. Kas notika?
SavÄ runÄ Džimijs Bogards vadÄ«s āpÄcnÄves pÄtÄ«jumuā par reÄlÄs dzÄ«ves mikropakalpojuma katastrofu. ViÅÅ” parÄdÄ«s modelÄÅ”anas, izstrÄdes un ražoÅ”anas problÄmas, ko viÅÅ” atklÄja, un to, kÄ viÅa komanda lÄnÄm pÄrveidoja jauno izplatÄ«to monolÄ«tu galÄ«gajÄ saprÄta priekÅ”statÄ. Lai gan nav iespÄjams pilnÄ«bÄ novÄrst projektÄÅ”anas kļūdas, jÅ«s varat vismaz identificÄt problÄmas jau projektÄÅ”anas procesa sÄkumÄ, lai nodroÅ”inÄtu, ka galaprodukts kļūst par uzticamu izplatÄ«tu sistÄmu.
Sveiki visiem, es esmu Džimijs, un Å”odien jÅ«s uzzinÄsit, kÄ izvairÄ«ties no milzÄ«gÄm katastrofÄm, veidojot mikropakalpojumus. Å is ir stÄsts par uzÅÄmumu, kurÄ strÄdÄju apmÄram pusotru gadu, lai palÄ«dzÄtu novÄrst viÅu kuÄ£a sadursmi ar aisbergu. Lai pareizi izstÄstÄ«tu Å”o stÄstu, mums bÅ«s jÄatgriežas pagÄtnÄ un jÄrunÄ par to, kur Å”is uzÅÄmums sÄkÄs un kÄ tÄ IT infrastruktÅ«ra laika gaitÄ ir augusi. Lai aizsargÄtu Å”ajÄ katastrofÄ nevainÄ«go vÄrdus, esmu mainÄ«jis Ŕī uzÅÄmuma nosaukumu uz Bell Computers. NÄkamajÄ slaidÄ ir parÄdÄ«ts, kÄ Å”Ädu uzÅÄmumu IT infrastruktÅ«ra izskatÄ«jÄs 90. gadu vidÅ«. Å Ä« ir tipiska arhitektÅ«ra lielam universÄlam kļūmju izturÄ«gam HP Tandem Mainframe serveram datoru aparatÅ«ras veikala darbÄ«bai.
ViÅiem bija jÄizveido sistÄma, lai pÄrvaldÄ«tu visus pasÅ«tÄ«jumus, pÄrdoÅ”anu, atgrieÅ”anu, produktu katalogus un klientu bÄzi, tÄpÄc viÅi izvÄlÄjÄs tajÄ laikÄ visizplatÄ«tÄko lieldatoru risinÄjumu. Å Ä« gigantiskÄ sistÄma ietvÄra visu informÄciju par uzÅÄmumu, visu iespÄjamo, un katrs darÄ«jums tika veikts, izmantojot Å”o lieldatoru. ViÅi turÄja visas olas vienÄ grozÄ un domÄja, ka tas ir normÄli. VienÄ«gais, kas Å”eit nav iekļauts, ir katalogi pa pastu un pasÅ«tÄ«jumu veikÅ”ana pa tÄlruni.
Laika gaitÄ sistÄma kļuva arvien lielÄka, un tajÄ sakrÄjÄs milzÄ«gs daudzums atkritumu. TurklÄt COBOL nav izteiksmÄ«gÄkÄ valoda pasaulÄ, tÄpÄc sistÄma galu galÄ kļuva par lielu, monolÄ«tu atkritumu gabalu. LÄ«dz 2000. gadam viÅi pamanÄ«ja, ka daudziem uzÅÄmumiem ir vietnes, kurÄs tie veica visu savu uzÅÄmÄjdarbÄ«bu, un nolÄma izveidot savu pirmo komerciÄlo dot-com vietni.
SÄkotnÄjais dizains izskatÄ«jÄs diezgan jauks un sastÄvÄja no augstÄkÄ lÄ«meÅa vietnes bell.com un vairÄkiem apakÅ”domÄniem atseviŔķÄm lietojumprogrammÄm: catalog.bell.com, accounts.bell.com, orders.bell.com, produktu meklÄÅ”ana search.bell. com. Katrs apakÅ”domÄns izmantoja ASP.Net 1.0 sistÄmu un savas datu bÄzes, un tie visi runÄja ar sistÄmas aizmugursistÄmu. TaÄu visi pasÅ«tÄ«jumi turpinÄjÄs apstrÄdÄt un izpildÄ«t vienÄ milzÄ«gÄ lieldatorÄ, kurÄ palika viss atkritums, bet priekÅ”gals bija atseviŔķas mÄjaslapas ar atseviŔķÄm aplikÄcijÄm un atseviŔķÄm datu bÄzÄm.
TÄtad sistÄmas dizains izskatÄ«jÄs sakÄrtots un loÄ£isks, bet faktiskÄ sistÄma bija tÄda, kÄ parÄdÄ«ts nÄkamajÄ slaidÄ.
Visi elementi adresÄja viens otram zvanus, piekļuva API, iegultiem treÅ”o puÅ”u dll un tamlÄ«dzÄ«gi. Bieži gadÄ«jÄs, ka versiju kontroles sistÄmas sagrÄba kÄda cita kodu, iegrÅ«da to iekÅ”Ä projektÄ, un tad viss salÅ«za. MS SQL Server 2005 izmantoja saiÅ”u serveru jÄdzienu, un, lai gan es nerÄdÄ«ju bultiÅas slaidÄ, katra no datu bÄzÄm arÄ« runÄja savÄ starpÄ, jo nav nekas slikts tabulu veidoÅ”anai, pamatojoties uz datiem, kas iegÅ«ti no vairÄkÄm datu bÄzÄm .
TÄ kÄ dažÄdÄs sistÄmas loÄ£iskÄs jomas tagad bija zinÄmÄ mÄrÄ noŔķirtas, tÄs kļuva par izkliedÄtiem netÄ«rumiem, un lielÄkais atkritumu gabals joprojÄm palika lieldatora aizmugursistÄmÄ.
SmieklÄ«gÄkais bija tas, ka Å”o lieldatoru uzbÅ«vÄja Bell Computers konkurenti, un to joprojÄm uzturÄja viÅu tehniskie konsultanti. PÄrliecinÄts par savu lietojumprogrammu neapmierinoÅ”o darbÄ«bu, uzÅÄmums nolÄma no tiem atbrÄ«voties un pÄrveidot sistÄmu.
EsoÅ”Ä lietojumprogramma tika ražota 15 gadus, kas ir rekords ASP.Net lietojumprogrammÄm. Pakalpojums pieÅÄma pasÅ«tÄ«jumus no visas pasaules, un gada ieÅÄmumi no Ŕīs vienas lietojumprogrammas sasniedza miljardu dolÄru. IevÄrojamu peļÅas daļu guvusi vietne bell.com. MelnajÄs piektdienÄs vietnÄ veikto pasÅ«tÄ«jumu skaits sasniedza vairÄkus miljonus. TaÄu esoÅ”Ä arhitektÅ«ra neļÄva attÄ«stÄ«ties, jo sistÄmas elementu stingrie savienojumi praktiski neļÄva veikt izmaiÅas pakalpojumÄ.
NopietnÄkÄ problÄma bija nespÄja veikt pasÅ«tÄ«jumu no vienas valsts, samaksÄt par to citÄ un nosÅ«tÄ«t uz treÅ”o, neskatoties uz to, ka globÄlajos uzÅÄmumos Å”Äda tirdzniecÄ«bas shÄma ir ļoti izplatÄ«ta. EsoÅ”Ä vietne neko tÄdu neatļÄva, tÄpÄc viÅiem bija jÄpieÅem un jÄveic Å”ie pasÅ«tÄ«jumi pa tÄlruni. Tas lika uzÅÄmumam arvien vairÄk domÄt par arhitektÅ«ras maiÅu, jo Ä«paÅ”i par pÄreju uz mikropakalpojumiem.
ViÅi rÄ«kojÄs gudri, aplÅ«kojot citus uzÅÄmumus, lai redzÄtu, kÄ viÅi ir atrisinÄjuÅ”i lÄ«dzÄ«gu problÄmu. Viens no Å”iem risinÄjumiem bija Netflix pakalpojumu arhitektÅ«ra, kas sastÄv no mikropakalpojumiem, kas savienoti, izmantojot API, un ÄrÄju datu bÄzi.
Bell Computers vadÄ«ba nolÄma izveidot tieÅ”i Å”Ädu arhitektÅ«ru, ievÄrojot noteiktus pamatprincipus. PirmkÄrt, viÅi novÄrsa datu dublÄÅ”anos, izmantojot kopÄ«gu datu bÄzes pieeju. Dati netika nosÅ«tÄ«ti, gluži pretÄji, visiem, kam tie bija vajadzÄ«gi, bija jÄdodas uz centralizÄtu avotu. Tam sekoja izolÄcija un autonomija ā katrs dienests bija neatkarÄ«gs no pÄrÄjiem. ViÅi nolÄma izmantot Web API pilnÄ«gi visam ā ja vÄlÄjÄties iegÅ«t datus vai veikt izmaiÅas citÄ sistÄmÄ, tas viss tika darÄ«ts caur Web API. PÄdÄjÄ lielÄ lieta bija jauns lieldators ar nosaukumu "Bell on Bell" pretstatÄ "Bell" lieldatoram, kas balstÄ«ts uz konkurentu aparatÅ«ru.
TÄpÄc 18 mÄneÅ”u laikÄ viÅi izveidoja sistÄmu, pamatojoties uz Å”iem pamatprincipiem, un nodeva to pirmsražoÅ”anas stadijÄ. PÄc nedÄļas nogales atgriežoties darbÄ, izstrÄdÄtÄji sanÄca kopÄ un ieslÄdza visus serverus, kuriem bija pieslÄgta jaunÄ sistÄma. 18 mÄneÅ”i darba, simtiem izstrÄdÄtÄju, vismodernÄkÄ Bell aparatÅ«ra ā un neviena pozitÄ«va rezultÄta! Tas ir licis vilties daudziem cilvÄkiem, jo āāviÅi daudzas reizes ir palaiduÅ”i Å”o sistÄmu savos klÄpjdatoros, un viss bija kÄrtÄ«bÄ.
ViÅi bija gudri, iztÄrÄjot visu savu naudu Ŕīs problÄmas risinÄÅ”anai. UzstÄdÄ«ja modernÄkos serveru statÄ«vus ar slÄdžiem, izmantoja gigabitu optisko Ŕķiedru, jaudÄ«gÄko servera aparatÅ«ru ar neprÄtÄ«gi lielu operatÄ«vo atmiÅu, to visu savienoja, konfigurÄja - un atkal nekÄ! Tad viÅiem sÄka rasties aizdomas, ka iemesls varÄtu bÅ«t taimauts, tÄpÄc viÅi iegÄja visos tÄ«mekļa iestatÄ«jumos, visos API iestatÄ«jumos un atjauninÄja visu taimauta konfigurÄciju lÄ«dz maksimÄlajÄm vÄrtÄ«bÄm, lai viss, ko viÅi varÄtu darÄ«t, bija sÄdÄt un gaidÄ«t, kad kaut kas notiks. uz vietni. ViÅi gaidÄ«ja un gaidÄ«ja un gaidÄ«ja 9 ar pusi minÅ«tes, lÄ«dz vietne beidzot tika ielÄdÄta.
PÄc tam viÅiem saprata, ka paÅ”reizÄjÄ situÄcija ir rÅ«pÄ«gi jÄanalizÄ, un viÅi mÅ«s uzaicinÄja. Pirmais, ko uzzinÄjÄm, bija tas, ka visu 18 attÄ«stÄ«bas mÄneÅ”u laikÄ netika izveidots neviens Ä«sts āmikroā ā viss kļuva tikai lielÄks. PÄc tam mÄs sÄkÄm rakstÄ«t pÄcnÄves ziÅojumu, kas pazÄ«stams arÄ« kÄ ānožÄlaā vai āskumja retrospekcijaā, kas pazÄ«stama arÄ« kÄ āvainojuma vÄtraā, kas lÄ«dzinÄs āprÄta vÄtraiā, lai izprastu katastrofas cÄloni.
Mums bija vairÄkas norÄdes, no kurÄm viena bija pilnÄ«ga trafika piesÄtinÄjums API izsaukuma laikÄ. Izmantojot monolÄ«tu pakalpojumu arhitektÅ«ru, varat uzreiz saprast, kas tieÅ”i nogÄja greizi, jo jums ir viena steka izsekoÅ”ana, kas ziÅo par visu, kas varÄja izraisÄ«t kļūmi. GadÄ«jumÄ, ja vairÄki pakalpojumi vienlaikus piekļūst vienai un tai paÅ”ai API, izsekoÅ”anu nevar izsekot, izÅemot, izmantojot papildu tÄ«kla uzraudzÄ«bas rÄ«kus, piemÄram, WireShark, pateicoties kuriem varat pÄrbaudÄ«t vienu pieprasÄ«jumu un uzzinÄt, kas notika tÄ ievieÅ”anas laikÄ. TÄpÄc mÄs paÅÄmÄm vienu tÄ«mekļa lapu un pavadÄ«jÄm gandrÄ«z 2 nedÄļas, lai kopÄ saliktu puzles gabalus, piezvanÄ«tu uz to un analizÄtu, pie kÄ katrs no tiem noveda.
Paskaties uz Å”o attÄlu. Tas parÄda, ka viens ÄrÄjs pieprasÄ«jums liek pakalpojumam veikt daudzus iekÅ”Äjos zvanus, kas atgriežas. IzrÄdÄs, ka katrs iekÅ”Äjais zvans veic papildu lÄcienus, lai varÄtu patstÄvÄ«gi apkalpot Å”o pieprasÄ«jumu, jo nekur citur nevar griezties, lai iegÅ«tu nepiecieÅ”amo informÄciju. Å is attÄls izskatÄs pÄc bezjÄdzÄ«gas zvanu kaskÄdes, jo ÄrÄjais pieprasÄ«jums izsauc papildu pakalpojumus, kas izsauc citus papildu pakalpojumus un tÄ tÄlÄk, gandrÄ«z bezgalÄ«gi.
ZaÄ¼Ä krÄsa Å”ajÄ diagrammÄ parÄda pusloku, kurÄ pakalpojumi zvana viens otram - pakalpojums A izsauc pakalpojumu B, pakalpojums B izsauc pakalpojumu C un tas atkal izsauc pakalpojumu A. RezultÄtÄ mÄs iegÅ«stam āizplatÄ«tu strupceļuā. Viens pieprasÄ«jums radÄ«ja tÅ«kstoÅ” tÄ«kla API zvanu, un, tÄ kÄ sistÄmai nebija iebÅ«vÄtas kļūdu tolerances un cilpas aizsardzÄ«bas, pieprasÄ«jums neizdosies, ja pat viens no Å”iem API izsaukumiem neizdodas.
MÄs veicÄm matemÄtiku. Katram API zvanam SLA bija ne vairÄk kÄ 150 ms un 99,9% darbÄ«bas laiks. Viens pieprasÄ«jums izraisÄ«ja 200 dažÄdus zvanus, un labÄkajÄ gadÄ«jumÄ lapu varÄja parÄdÄ«t 200 x 150 ms = 30 sekundes. Protams, tas nebija labi. Reizinot 99,9% darbÄ«bas laiku ar 200, mÄs saÅÄmÄm 0% pieejamÄ«bu. IzrÄdÄs, ka Ŕī arhitektÅ«ra jau no paÅ”a sÄkuma bija lemta neveiksmei.
MÄs jautÄjÄm izstrÄdÄtÄjiem, kÄ viÅi nespÄja atpazÄ«t Å”o problÄmu pÄc 18 mÄneÅ”u darba? IzrÄdÄ«jÄs, ka viÅi skaitÄ«ja tikai SLA par kodu, kuru viÅi palaida, bet, ja viÅu pakalpojums izsauca citu pakalpojumu, viÅi to neskaitÄ«ja savÄ SLA. Viss, kas tika palaists viena procesa ietvaros, saglabÄjÄs 150 ms vÄrtÄ«bÄ, bet piekļuve citiem pakalpojumu procesiem palielinÄja kopÄjo aizkavi vairÄkas reizes. PirmÄ mÄcÄ«ba, kas gÅ«ta, bija: āVai jÅ«s kontrolÄjat savu SLA, vai arÄ« SLA kontrolÄ jÅ«s?ā MÅ«su gadÄ«jumÄ tas bija pÄdÄjais.
NÄkamÄ lieta, ko atklÄjÄm, bija tas, ka viÅi zinÄja par izplatÄ«to skaitļoÅ”anas nepareizo priekÅ”statu jÄdzienu, ko formulÄja PÄ«ters DeiÄs un Džeimss Goslings, taÄu viÅi ignorÄja tÄ pirmo daļu. TajÄ teikts, ka apgalvojumi ātÄ«kls ir uzticamsā, ānulles latentumsā un ābezgalÄ«ga caurlaidspÄjaā ir maldi. Citi maldÄ«gi priekÅ”stati ir apgalvojumi "tÄ«kls ir droÅ”s", "topoloÄ£ija nekad nemainÄs", "vienmÄr ir tikai viens administrators", "datu pÄrsÅ«tÄ«Å”anas izmaksas ir nulle" un "tÄ«kls ir viendabÄ«gs".
ViÅi pieļÄva kļūdu, jo pÄrbaudÄ«ja savus pakalpojumus vietÄjÄs iekÄrtÄs un nekad nepievienojÄs ÄrÄjiem pakalpojumiem. IzstrÄdÄjot lokÄli un izmantojot lokÄlo keÅ”atmiÅu, viÅi nekad nesaskÄrÄs ar tÄ«kla apiÅiem. Visos 18 attÄ«stÄ«bas mÄneÅ”os viÅi ne reizi nav domÄjuÅ”i, kas varÄtu notikt, ja tiktu ietekmÄti ÄrÄjie pakalpojumi.
Ja paskatÄs uz pakalpojuma robežas iepriekÅ”ÄjÄ attÄlÄ, var redzÄt, ka tÄs visas ir nepareizas. Ir daudz avotu, kas sniedz padomus, kÄ noteikt pakalpojumu robežas, un lielÄkÄ daļa to dara nepareizi, piemÄram, Microsoft nÄkamajÄ slaidÄ.
Å is attÄls ir no MS emuÄra par tÄmu āKÄ izveidot mikropakalpojumusā. Tas parÄda vienkÄrÅ”u tÄ«mekļa lietojumprogrammu, biznesa loÄ£ikas bloku un datu bÄzi. PieprasÄ«jums nÄk tieÅ”i, iespÄjams, ir viens serveris tÄ«meklim, viens serveris uzÅÄmumam un viens datubÄzei. Ja palielinÄsiet satiksmi, attÄls nedaudz mainÄ«sies.
Å eit ir slodzes lÄ«dzsvarotÄjs, lai sadalÄ«tu trafiku starp diviem tÄ«mekļa serveriem, keÅ”atmiÅa, kas atrodas starp tÄ«mekļa pakalpojumu un biznesa loÄ£iku, un vÄl viena keÅ”atmiÅa starp biznesa loÄ£iku un datu bÄzi. TieÅ”i Å”Ädu arhitektÅ«ru Bell izmantoja slodzes lÄ«dzsvaroÅ”anai un zilÄs/zaļÄs izvietoÅ”anas lietojumprogrammai 2000. gadu vidÅ«. LÄ«dz kÄdu laiku viss darbojÄs labi, jo Ŕī shÄma bija paredzÄta monolÄ«tai konstrukcijai.
NÄkamajÄ attÄlÄ parÄdÄ«ts, kÄ MS iesaka pÄriet no monolÄ«ta uz mikropakalpojumiem - vienkÄrÅ”i sadalot katru no galvenajiem pakalpojumiem atseviŔķos mikropakalpojumos. TieÅ”i Ŕīs shÄmas ievieÅ”anas laikÄ Bells kļūdÄ«jÄs.
ViÅi sadalÄ«ja visus savus pakalpojumus dažÄdos lÄ«meÅos, no kuriem katrs sastÄvÄja no daudziem atseviŔķiem pakalpojumiem. PiemÄram, tÄ«mekļa pakalpojums ietvÄra mikropakalpojumus satura renderÄÅ”anai un autentifikÄcijai, biznesa loÄ£ikas pakalpojums sastÄvÄja no mikropakalpojumiem pasÅ«tÄ«jumu un konta informÄcijas apstrÄdei, datu bÄze tika sadalÄ«ta mikropakalpojumos ar specializÄtiem datiem. Gan tÄ«meklis, gan biznesa loÄ£ika, gan datubÄze bija bezvalstniecÄ«bas pakalpojumi.
TomÄr Å”is attÄls bija pilnÄ«gi nepareizs, jo tajÄ netika kartÄta neviena biznesa vienÄ«ba Ärpus uzÅÄmuma IT klastera. Å Ä« shÄma neÅÄma vÄrÄ nekÄdu saistÄ«bu ar Ärpasauli, tÄpÄc nebija skaidrs, kÄ, piemÄram, iegÅ«t treÅ”Äs puses biznesa analÄ«zi. Es atzÄ«mÄju, ka viÅiem bija arÄ« vairÄki pakalpojumi, kas tika izgudroti vienkÄrÅ”i, lai attÄ«stÄ«tu atseviŔķu darbinieku karjeru, kuri centÄs vadÄ«t pÄc iespÄjas vairÄk cilvÄku, lai par to iegÅ«tu vairÄk naudas.
ViÅi uzskatÄ«ja, ka pÄreja uz mikropakalpojumiem ir tikpat vienkÄrÅ”a kÄ iekÅ”ÄjÄ N lÄ«meÅa fiziskÄ slÄÅa infrastruktÅ«ras izmantoÅ”ana un Docker pielÄ«mÄÅ”ana tai. ApskatÄ«sim, kÄ izskatÄs tradicionÄlÄ N lÄ«meÅa arhitektÅ«ra.
Tas sastÄv no 4 lÄ«meÅiem: lietotÄja interfeisa lÄ«meÅa, biznesa loÄ£ikas lÄ«meÅa, datu piekļuves lÄ«meÅa un datu bÄzes. ProgresÄ«vÄka ir DDD (Domain-Driven Design) jeb uz programmatÅ«ru orientÄta arhitektÅ«ra, kur divi vidÄjie lÄ«meÅi ir domÄna objekti un repozitorijs.
Es mÄÄ£inÄju aplÅ«kot dažÄdas pÄrmaiÅu jomas, dažÄdas atbildÄ«bas jomas Å”ajÄ arhitektÅ«rÄ. TipiskÄ N lÄ«meÅa lietojumprogrammÄ tiek klasificÄtas dažÄdas izmaiÅu jomas, kas caurstrÄvo struktÅ«ru vertikÄli no augÅ”as uz leju. Tie ir katalogs, konfigurÄcijas iestatÄ«jumi, kas veikti atseviŔķos datoros, un Checkout pÄrbaudes, ko veica mana komanda.
Å Ä«s shÄmas Ä«patnÄ«ba ir tÄda, ka Å”o pÄrmaiÅu jomu robežas ietekmÄ ne tikai biznesa loÄ£ikas lÄ«meni, bet arÄ« sniedzas lÄ«dz datu bÄzei.
ApskatÄ«sim, ko nozÄ«mÄ bÅ«t pakalpojumam. Pakalpojuma definÄ«cijai ir 6 raksturÄ«gas Ä«paŔības - tÄ ir programmatÅ«ra, kas:
- izveidojusi un izmantojusi konkrÄta organizÄcija;
- ir atbildÄ«gs par noteikta veida informÄcijas saturu, apstrÄdi un/vai nodroÅ”inÄÅ”anu sistÄmÄ;
- var uzbÅ«vÄt, izvietot un darboties neatkarÄ«gi, lai apmierinÄtu Ä«paÅ”as darbÄ«bas vajadzÄ«bas;
- sazinÄs ar patÄrÄtÄjiem un citiem dienestiem, sniedzot informÄciju, pamatojoties uz lÄ«gumiem vai lÄ«guma garantijÄm;
- pasargÄ sevi no nesankcionÄtas piekļuves un savu informÄciju no pazaudÄÅ”anas;
- risina kļūmes tÄ, lai tÄs neizraisÄ«tu informÄcijas bojÄjumus.
Visas Ŕīs Ä«paŔības var izteikt ar vienu vÄrdu āautonomijaā. Pakalpojumi darbojas neatkarÄ«gi viens no otra, atbilst noteiktiem ierobežojumiem un definÄ lÄ«gumus, uz kuru pamata cilvÄki var saÅemt viÅiem nepiecieÅ”amo informÄciju. Es neminÄju konkrÄtas tehnoloÄ£ijas, kuru izmantoÅ”ana ir paÅ”saprotama.
Tagad apskatīsim mikropakalpojumu definīciju:
- mikropakalpojums ir maza izmÄra un paredzÄts vienas konkrÄtas problÄmas risinÄÅ”anai;
- Mikropakalpojums ir autonoms;
- Veidojot mikropakalpojumu arhitektÅ«ru, tiek izmantota pilsÄtplÄnoÅ”anas metafora. Å Ä« ir definÄ«cija no Sema Å Å«mena grÄmatas Building Microservices.
IerobežotÄ konteksta definÄ«cija ir Åemta no Ärika Evansa grÄmatas Domain-Driven Design. Å is ir galvenais modelis DDD ā arhitektÅ«ras dizaina centrÄ, kas strÄdÄ ar apjomÄ«giem arhitektÅ«ras modeļiem, sadalot tos dažÄdos ierobežotajos kontekstos un skaidri definÄjot mijiedarbÄ«bu starp tiem.
VienkÄrÅ”i sakot, ierobežotais konteksts apzÄ«mÄ darbÄ«bas jomu, kurÄ var izmantot konkrÄtu moduli. Å ajÄ kontekstÄ ir loÄ£iski vienots modelis, ko var redzÄt, piemÄram, jÅ«su biznesa domÄnÄ. Ja pasÅ«tÄ«jumos iesaistÄ«tajam personÄlam jautÄsiet "kas ir klients", jÅ«s saÅemsiet vienu definÄ«ciju, ja jautÄsiet pÄrdoÅ”anas jomÄ iesaistÄ«tajiem, jÅ«s saÅemsiet citu, bet izpildÄ«tÄji sniegs treÅ”o definÄ«ciju.
TÄtad, Ierobežotais konteksts saka: ja mÄs nevaram sniegt skaidru definÄ«ciju tam, kas ir mÅ«su pakalpojumu patÄrÄtÄjs, definÄsim robežas, kurÄs mÄs varam runÄt par Ŕī termina nozÄ«mi, un pÄc tam definÄsim pÄrejas punktus starp Ŕīm dažÄdajÄm definÄ«cijÄm. Tas ir, ja mÄs runÄjam par klientu no pasÅ«tÄ«jumu veikÅ”anas viedokļa, tas nozÄ«mÄ to un to, un, ja no pÄrdoÅ”anas viedokļa, tas nozÄ«mÄ to un to.
NÄkamÄ mikropakalpojuma definÄ«cija ir jebkÄda veida iekÅ”Äjo darbÄ«bu iekapsulÄÅ”ana, novÄrÅ”ot darba procesa komponentu ānoplÅ«diā vidÄ. TÄlÄk nÄk "precÄ«zu lÄ«gumu definÄ«cija ÄrÄjai mijiedarbÄ«bai vai ÄrÄjai komunikÄcijai", ko atspoguļo ideja par lÄ«gumiem, kas atgriežas no SLA. PÄdÄjÄ definÄ«cija ir Ŕūnas vai Ŕūnas metafora, kas nozÄ«mÄ pilnÄ«gu darbÄ«bu kopuma iekapsulÄÅ”anu mikropakalpojumÄ un receptoru klÄtbÅ«tni tajÄ saziÅai ar Ärpasauli.
TÄpÄc mÄs teicÄm Bell Computers puiÅ”iem: "MÄs nevaram novÄrst jÅ«su radÄ«to haosu, jo jums vienkÄrÅ”i nav naudas, lai to izdarÄ«tu, bet mÄs izlabosim tikai vienu pakalpojumu, lai tas viss bÅ«tu sajÅ«tu.ā Å ajÄ brÄ«dÄ« es sÄkÅ”u ar to, kÄ mÄs labojÄm savu vienÄ«go pakalpojumu, lai tas atbildÄtu uz pieprasÄ«jumiem ÄtrÄk nekÄ 9 ar pusi minÅ«tes.
22:30 min
TurpinÄjums jau pavisam drÄ«z...
Kaut kÄda reklÄma
Paldies, ka palikÄt kopÄ ar mums. Vai jums patÄ«k mÅ«su raksti? Vai vÄlaties redzÄt interesantÄku saturu? Atbalsti mÅ«s, pasÅ«tot vai iesakot draugiem, , unikÄls sÄkuma lÄ«meÅa serveru analogs, ko mÄs jums izgudrojÄm: (pieejams ar RAID1 un RAID10, lÄ«dz 24 kodoliem un lÄ«dz 40 GB DDR4).
Dell R730xd 2x lÄtÄk Equinix Tier IV datu centrÄ AmsterdamÄ? Tikai Å”eit NÄ«derlandÄ! Dell R420 ā 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB ā no 99 USD! LasÄ«t par
Avots: www.habr.com