Izbira arhitekturnega sloga (3. del)

Pozdravljeni, Habr. Danes nadaljujem serijo publikacij, ki sem jih napisal posebej za začetek novega toka tečaja. "Arhitekt programske opreme".

Predstavitev

Izbira arhitekturnega stila je ena temeljnih tehničnih odločitev pri izgradnji informacijskega sistema. V tej seriji člankov predlagam, da analiziram najbolj priljubljene arhitekturne sloge za gradbene aplikacije in odgovorim na vprašanje, kdaj je kateri arhitekturni slog najprimernejši. V procesu predstavitve bom poskušal narisati logično verigo, ki pojasnjuje razvoj arhitekturnih slogov od monolitov do mikrostoritev.

Zadnjič smo govorili o različnih vrstah monolitov in uporabi komponent za njihovo gradnjo, tako gradbenih komponent kot komponent za uvajanje. Razumemo storitveno usmerjeno arhitekturo.

Zdaj bomo končno definirali glavne značilnosti arhitekture mikrostoritve.

Odnos arhitektur

Treba je razumeti, da je na podlagi definicij, navedenih v prejšnjih člankih, vsaka storitev komponenta, ni pa vsaka storitev mikrostoritev.

Značilnosti mikrostoritvene arhitekture

Glavne značilnosti mikrostoritvene arhitekture so:

  • Organizirano okoli poslovnih zmogljivosti
  • Izdelki ne projekti
  • Pametne končne točke in neumne cevi
  • Decentralizirano upravljanje
  • Decentralizirano upravljanje podatkov
  • Avtomatizacija infrastrukture
  • Dizajn za neuspeh
  • Arhitektura z evolucijskim razvojem (Evolutionary Design)

1. točka izhaja iz storitveno usmerjene arhitekture, ker so mikrostoritve poseben primer storitev. Druge točke si zaslužijo ločeno obravnavo.

Organizirano okoli poslovnih zmogljivosti

Zdaj se je treba spomniti Conwayevega zakona: organizacije, ki ustvarjajo sisteme, organizirajo svojo arhitekturo in kopirajo strukturo interakcije znotraj teh organizacij. Kot primer se lahko spomnimo na primer ustvarjanja prevajalnika: ekipa sedmih ljudi je razvila sedemprehodni prevajalnik, ekipa petih pa je razvila petprehodni prevajalnik.

Če govorimo o monolitih in mikrostoritvah, potem, če je razvoj organiziran po funkcionalnih oddelkih (backend, frontend, skrbniki podatkovnih baz), potem dobimo klasičen monolit.

Za pridobitev mikrostoritev morajo biti ekipe organizirane po poslovnih zmožnostih (naročila, pošiljke, kataloška ekipa). Ta organizacija bo ekipam omogočila, da se osredotočijo na gradnjo določenih delov aplikacije.

Izdelki ne projekti

Projektni pristop, pri katerem ekipa razvito funkcionalnost prenaša na druge ekipe, je v primeru mikrostoritvene arhitekture popolnoma neprimeren. Ekipa mora podpirati sistem skozi njegov življenjski cikel. Amazon, eden od vodilnih na področju implementacije mikrostoritev, je izjavil: "vi gradite, vi to vodite." Produktni pristop omogoča ekipi, da začuti potrebe podjetja.

Pametne končne točke in neumne cevi

Arhitektura SOA je veliko pozornost namenila komunikacijskim kanalom, zlasti Enterprise Service Bus. Kar pogosto vodi v Erroneous Spaghetti Box, torej se kompleksnost monolita spremeni v kompleksnost povezav med storitvami. Arhitektura mikrostoritev uporablja samo preproste komunikacijske metode.

Decentralizirano upravljanje

Ključne odločitve o mikrostoritvah bi morali sprejemati ljudje, ki mikrostoritve dejansko razvijajo. Tukaj ključne odločitve pomenijo izbire
programski jeziki, metodologija uvajanja, javne pogodbe o vmesniku itd.

Decentralizirano upravljanje podatkov

Standardni pristop, pri katerem aplikacija temelji na eni sami bazi podatkov, ne more upoštevati posebnosti posamezne storitve. MSA vključuje decentralizirano upravljanje podatkov, vključno z uporabo različnih tehnologij.

Avtomatizacija infrastrukture

MSA podpira stalne procese uvajanja in dostave. To je mogoče doseči le z avtomatizacijo procesov. Hkrati uvedba velikega števila storitev ne izgleda več kot nekaj strašljivega. Postopek uvajanja bi moral postati dolgočasen. Drugi vidik je povezan z upravljanjem storitev v produktnem okolju. Brez avtomatizacije postane upravljanje procesov, ki tečejo v različnih operacijskih okoljih, nemogoče.

Dizajn za neuspeh

Številne storitve MSA so nagnjene k odpovedi. Obenem obravnavanje napak v porazdeljenem sistemu ni nepomembna naloga. Arhitektura aplikacij mora biti odporna na takšne napake. Rebecca Parsons meni, da je zelo pomembno, da ne uporabljamo več niti medprocesne komunikacije med storitvami, temveč se za komunikacijo zatečemo k HTTP-ju, ki ni niti približno tako zanesljiv.

Arhitektura z evolucijskim razvojem (Evolutionary Design)

Arhitektura sistema MSA naj bi se razvijala evolucijsko. Priporočljivo je omejiti potrebne spremembe na meje ene same storitve. Upoštevati je treba tudi vpliv na druge storitve. Tradicionalni pristop je poskusiti to težavo rešiti z različicami, vendar MSA predlaga uporabo različic v
v skrajnem primeru.

Zaključek

Po vsem naštetem lahko formuliramo, kaj so mikrostoritve. Arhitektura mikrostoritev je pristop k razvoju ene same aplikacije kot zbirke majhnih storitev, od katerih vsaka teče v svojem procesu in medsebojno deluje prek lahkih mehanizmov, pogosto API-ja virov HTTP. Te storitve temeljijo na poslovnih zmožnostih in jih je mogoče uvesti neodvisno s polno uporabo
mehanizem samodejnega uvajanja. Obstaja minimalna raven centraliziranega upravljanja teh storitev, ki so lahko napisane v različnih programskih jezikih in uporabljajo različne tehnologije za shranjevanje podatkov.

Izbira arhitekturnega sloga (3. del)

Preberi 2. del

Vir: www.habr.com

Dodaj komentar