Hallo, habr. Ynskriuwing foar in nije kursusstream is op it stuit iepen by OTUS . Oan 'e foarjûn fan' e start fan 'e kursus wol ik myn orizjinele artikel mei jo diele.
Ynlieding
De kar fan arsjitektoanyske styl is ien fan 'e fûnemintele technyske besluten by it bouwen fan in ynformaasjesysteem. Yn dizze searje artikels stel ik foar om de populêrste arsjitektoanyske stilen te analysearjen foar bouwapplikaasjes en beantwurdzje de fraach wannear hokker arsjitektoanyske styl it meast de foarkar is. Yn it proses fan presintaasje sil ik besykje in logyske keatling te tekenjen dy't de ûntwikkeling fan arsjitektoanyske stilen ferklearret fan monoliten oant mikrotsjinsten.
In bytsje skiednis
As jo besykje ûntwikkelders te freegjen: "Wêrom hawwe wy mikrotsjinsten nedich?", krije jo in ferskaat oan antwurden. Jo sille hearre dat mikrotsjinsten skaalberens ferbetterje, koade makliker meitsje te begripen, fouttolerânsje ferbetterje, en soms sille jo hearre dat se jo tastean om "jo koade skjin te meitsjen." Litte wy de skiednis besjen om it doel efter it ûntstean fan mikrotsjinsten te begripen.
Koartsein, mikrotsjinsten yn ús hjoeddeistige ferstân ûntstienen as folget: yn 2011, James Lewis, analysearjen fan it wurk fan ferskate bedriuwen, luts omtinken foar it ûntstean fan in nij "micro-app" patroan, dy't SOA optimalisearre yn termen fan it fersnellen fan de ynset fan tsjinsten. Wat letter, yn 2012, op in arsjitektuertop, waard it patroan omneamd ta mikroservice. Sa wie it earste doel fan it ynfieren fan mikrotsjinsten it ferbetterjen fan de beruchte tiid om te merken.
Mikrotsjinsten wiene yn 2015 op 'e hypewelle. Neffens guon stúdzjes wie gjin inkele konferinsje folslein sûnder in rapport oer it ûnderwerp fan mikrotsjinsten. Boppedat wiene guon konferinsjes eksklusyf wijd oan mikrotsjinsten. Tsjintwurdich begjinne in protte projekten dizze arsjitektoanyske styl te brûken, en as it projekt tonnen legacy-koade befettet, dan wurdt migraasje nei mikrotsjinsten wierskynlik aktyf útfierd.
Nettsjinsteande al it boppesteande kin in frij lyts oantal ûntwikkelders it konsept fan "mikroservice" noch definiearje. Mar wy sille it hjir efkes letter oer ha...
Monolith
De arsjitektoanyske styl dy't mikrotsjinsten kontrast is de monolith (as alles-yn-ien). It hat nei alle gedachten gjin sin om te fertellen wat in monolith is, dus ik sil daliks de neidielen fan dizze arsjitektoanyske styl opskriuwe, dy't de fierdere ûntwikkeling fan arsjitektoanyske stilen inisjearre: grutte, ferbining, ynset, skalberens, betrouberens en rigiditeit. Hjirûnder stel ik foar om elk fan 'e tekoarten apart te besjen.
grutte
De monolith is tige grut. En it kommunisearret normaal mei in heul grutte databank. De applikaasje wurdt te grut foar ien ûntwikkelder om hielendal te begripen. Allinnich dejingen dy't in protte tiid hawwe bestege oan dizze koade kinne goed wurkje mei de monolith, wylst begjinners in protte tiid sille besteegje om te besykjen om de monolith út te finen en d'r is gjin garânsje dat se it útfine. Meastentiids, by it wurkjen mei in monolith, is d'r altyd wat "betingsten" senior dy't de monolyt min of mear goed ken en de hannen fan oare nije ûntwikkelders binnen in jier en in heal slacht. Fansels, sa'n betingst senior - ien punt fan mislearring, en syn fuortgean kin liede ta de dea fan 'e monolith.
Ferbining
De monolith is in "grutte bal fan modder", feroarings dêr't kin liede ta ûnfoarspelbere gefolgen. Troch feroaringen op ien plak te meitsjen, kinne jo de monolyt op in oar beskeadigje (itselde "jo hawwe jo ear bekrast, *@ foel ôf"). Dat komt troch it feit dat de komponinten yn 'e monolith hawwe tige komplekse en, vooral, net-dúdlike relaasjes.
Ynset
It ynsetten fan in monolyt, troch de komplekse relaasjes tusken syn komponinten, is in lang proses mei in eigen ritueel. Sa'n ritueel is normaal net folslein standerdisearre en wurdt "mûnling" trochjûn.
Skalberens
Monolith-modules kinne tsjinstridige boarnebehoeften hawwe, wêrtroch't in kompromis moat wurde makke yn termen fan hardware. Yntinke dat jo in monolith besteande út tsjinsten A en B. Service A is easket op 'e grutte fan' e hurde skiif, en tsjinst B is easket op RAM. Yn dit gefal, of de masine dêr't de monolith is ynstallearre moat stypje de easken fan beide tsjinsten, of jo moatte de hân, keunstmjittich útskeakelje ien fan de tsjinsten.
In oar foarbyld (klassikerer): tsjinst A is folle populêrder as tsjinst B, dus jo wolle dat d'r 100 tsjinsten A binne, en 10 tsjinsten B. Nochris twa opsjes: of wy ynsette 100 folsleine monoliten, of op guon dan tsjinsten B moatte mei de hân útskeakele wurde.
Reliabiliteit
Sûnt alle tsjinsten lizze tegearre, as de monolith falt, dan falle alle tsjinsten tagelyk. Yn feite kin dit net sa slim wêze, teminsten sille d'r gjin dielfalen wêze yn in ferspraat systeem, mar oan 'e oare kant, troch in brek yn funksjonaliteit dy't brûkt wurdt troch 0.001% fan brûkers, kinne jo alle brûkers ferlieze. fan jo systeem.
Inertia
Troch de grutte fan 'e monolith is it dreech om te wikseljen nei nije technologyen. Dêrtroch liket it behâlden fan dy tige betingste senior in aparte taak te wêzen. De technologystack keazen oan it begjin fan in projekt kin in blok wurde dat de ûntwikkeling fan it produkt hinderet.
konklúzje
Folgjende kear sille wy prate oer hoe't minsken hawwe besocht dizze problemen op te lossen troch te ferpleatsen nei komponinten en SOA.
Lês mear:
Boarne: www.habr.com