Saluton, Habr. Hodiaŭ mi daŭrigas serion da publikaĵoj, kiujn mi verkis specife por la komenco de nova fluo de la kurso. .
Enkonduko
La elekto de arkitektura stilo estas unu el la fundamentaj teknikaj decidoj dum konstruado de informsistemo. En ĉi tiu serio de artikoloj, mi proponas analizi la plej popularajn arkitekturajn stilojn por konstrui aplikojn kaj respondi la demandon, kiam kiu arkitektura stilo estas plej preferinda. En la procezo de prezento, mi provos desegni logikan ĉenon, kiu klarigas la evoluon de arkitekturaj stiloj de monolitoj ĝis mikroservoj.
Lastan fojon ni parolis pri la malsamaj specoj de monolitoj kaj la uzo de komponantoj por konstrui ilin, ambaŭ konstrui komponantojn kaj deplojajn komponantojn. Ni komprenas servo-orientitan arkitekturon.
Nun ni finfine difinos la ĉefajn karakterizaĵojn de mikroserva arkitekturo.
Rilato de arkitekturoj
Necesas kompreni, ke laŭ la difinoj donitaj en antaŭaj artikoloj, iu ajn servo estas komponanto, sed ne ĉiu servo estas mikroservo.
Karakterizaĵoj de Microservice Architecture
La ĉefaj karakterizaĵoj de mikroserva arkitekturo estas:
- Organizite ĉirkaŭ Komercaj Kapabloj
- Produktoj ne Projektoj
- Inteligentaj finpunktoj kaj mutaj tuboj
- Malcentralizita Regado
- Malcentra Administrado de Datumoj
- Infrastruktura Aŭtomatigo
- Dezajno por fiasko
- Arkitekturo kun evolua evoluo (Evolua Dezajno)
La unua punkto venas de serva arkitekturo ĉar mikroservoj estas speciala kazo de servoj. Aliaj punktoj meritas apartan konsideron.
Organizite ĉirkaŭ Komercaj Kapabloj
Nun necesas memori la leĝon de Conway: organizoj kiuj kreas sistemojn organizas ĝian arkitekturon, kopiante la strukturon de interagado ene de tiuj organizoj. Kiel ekzemplo, ni povas rememori la kazon de kreado de kompililo: teamo de sep homoj evoluigis sep-pasan kompililon, kaj teamo de kvin evoluigis kvin-pasan kompililon.
Se ni parolas pri monolitoj kaj mikroservoj, tiam se disvolviĝo estas organizita de funkciaj fakoj (backend, frontend, datumbazaj administrantoj), tiam ni ricevas klasikan monoliton.
Por akiri mikroservojn, teamoj devas esti organizitaj laŭ komerca kapablo (mendoj, sendoj, katalogo-teamo). Ĉi tiu organizo permesos al teamoj koncentriĝi pri konstruado de specifaj partoj de la aplikaĵo.
Produktoj ne Projektoj
Projektaliro en kiu teamo transdonas la evoluintajn funkciecon al aliaj teamoj estas tute maltaŭga en la kazo de mikroserva arkitekturo. La teamo devas subteni la sistemon dum sia vivociklo. Amazon, unu el la gvidantoj en la efektivigo de mikroservoj, deklaris: "vi konstruas, vi prizorgas ĝin." La produkta aliro permesas al la teamo senti la bezonojn de la komerco.
Inteligentaj finpunktoj kaj mutaj tuboj
SOA-arkitekturo tre atentis komunikajn kanalojn, precipe la Enterprise Service Bus. Kio ofte kondukas al Erara Spaghetti Box, tio estas, la komplekseco de la monolito iĝas la komplekseco de ligoj inter servoj. Mikroserva arkitekturo uzas nur simplajn komunikadmetodojn.
Malcentralizita Regado
Ŝlosilaj decidoj pri mikroservoj devas esti faritaj de homoj, kiuj efektive disvolvas la mikroservojn. Ĉi tie, ŝlosilaj decidoj signifas elektojn
programlingvoj, deplojmetodaro, publikaj interfacaj kontraktoj, ktp.
Malcentra Administrado de Datumoj
La norma aliro, en kiu la aplikaĵo dependas de ununura datumbazo, ne povas konsideri la specifaĵojn de ĉiu specifa servo. MSA implikas malcentran administradon de datumoj, inkluzive de la uzo de diversaj teknologioj.
Infrastruktura Aŭtomatigo
MSA subtenas kontinuajn deplojajn kaj liverajn procezojn. Ĉi tio povas esti atingita nur per aŭtomatigado de procezoj. Samtempe, deploji grandan nombron da servoj ne plu aspektas kiel io timiga. La deploja procezo devus fariĝi enuiga. La dua aspekto rilatas al serva administrado en produkta medio. Sen aŭtomatigo, administri procezojn kurantajn en malsamaj operaciumoj fariĝas neebla.
Dezajno por fiasko
Multaj MSA-servoj estas emaj al fiasko. Samtempe, erartraktado en distribuita sistemo ne estas bagatela tasko. Aplika arkitekturo devas esti rezistema al tiaj fiaskoj. Rebecca Parsons opinias, ke estas tre grave, ke ni eĉ ne plu uzas enprocezan komunikadon inter servoj; anstataŭe, ni recurre al HTTP por komunikado, kiu ne estas preskaŭ tiel fidinda.
Arkitekturo kun evolua evoluo (Evolua Dezajno)
La arkitekturo de la MSA-sistemo devus evolui evolue. Estas konsilinde limigi la necesajn ŝanĝojn al la limoj de ununura servo. La efiko al aliaj servoj ankaŭ devas esti konsiderata. La tradicia aliro estas provi solvi ĉi tiun problemon per versionado, sed MSA sugestas uzi versioning en
kiel lasta rimedo.
konkludo
Post ĉio ĉi-supra, ni povas formuli, kio estas mikroservoj. Mikroserva arkitekturo estas aliro al evoluigado de ununura aplikaĵo kiel kolekto de malgrandaj servoj, ĉiu funkciante en sia propra procezo kaj interagante per malpezaj mekanismoj, ofte HTTP-rimeda API. Ĉi tiuj servoj estas konstruitaj sur komercaj kapabloj kaj povas esti deplojitaj sendepende uzante plene
aŭtomatigita disfalda mekanismo. Estas minimuma nivelo de centralizita administrado de ĉi tiuj servoj, kiuj povas esti skribitaj en malsamaj programlingvoj kaj uzi malsamajn datumtenajn teknologiojn.
fonto: www.habr.com