Ahoj Habr. Dnes pokračujem v sérii publikácií, ktoré som napísal špeciálne pre začiatok nového prúdu kurzu. .
Úvod
Výber architektonického štýlu je jedným zo zásadných technických rozhodnutí pri budovaní informačného systému. V tejto sérii článkov navrhujem analyzovať najpopulárnejšie architektonické štýly pre stavebné aplikácie a odpovedať na otázku, kedy je ktorý architektonický štýl najvýhodnejší. V procese prezentácie sa pokúsim nakresliť logický reťazec, ktorý vysvetľuje vývoj architektonických štýlov od monolitov po mikroslužby.
Minule sme hovorili o rôznych typoch monolitov a použití komponentov na ich zostavenie, a to ako komponentov zostavy, tak komponentov nasadenia. Rozumieme architektúre orientovanej na služby.
Teraz konečne definujeme hlavné charakteristiky architektúry mikroslužieb.
Vzťah architektúr
Je potrebné pochopiť, že na základe definícií uvedených v predchádzajúcich článkoch je každá služba komponent, ale nie každá služba je mikroslužba.
Charakteristika mikroservisnej architektúry
Hlavné charakteristiky architektúry mikroslužieb sú:
- Organizované okolo obchodných schopností
- Produkty nie projekty
- Inteligentné koncové body a hlúpe potrubia
- Decentralizované riadenie
- Decentralizovaná správa údajov
- Automatizácia infraštruktúry
- Dizajn pre zlyhanie
- Architektúra s evolučným vývojom (Evolutionary Design)
Prvý bod pochádza z architektúry orientovanej na služby, pretože mikroslužby sú špeciálnym prípadom služieb. Ostatné body si zaslúžia osobitnú pozornosť.
Organizované okolo obchodných schopností
Teraz je potrebné pripomenúť Conwayov zákon: organizácie, ktoré vytvárajú systémy, organizujú jeho architektúru, kopírujúc štruktúru interakcie v rámci týchto organizácií. Ako príklad si môžeme pripomenúť prípad vytvorenia kompilátora: tím siedmich ľudí vyvinul sedempriechodový prekladač a päťčlenný päťpriechodový kompilátor.
Ak hovoríme o monolitoch a mikroslužbách, tak ak vývoj organizujú funkčné oddelenia (backend, frontend, správcovia databáz), tak dostaneme klasický monolit.
Na získanie mikroslužieb musia byť tímy organizované podľa obchodných schopností (objednávky, zásielky, katalógový tím). Táto organizácia umožní tímom sústrediť sa na vytváranie špecifických častí aplikácie.
Produkty nie projekty
Projektový prístup, pri ktorom tím prenáša vyvinutú funkcionalitu na iné tímy, je v prípade architektúry mikroslužieb úplne nevhodný. Tím musí podporovať systém počas celého životného cyklu. Amazon, jeden z lídrov v implementácii mikroslužieb, uviedol: „Vy zostavíte, spustíte to.“ Produktový prístup umožňuje tímu cítiť potreby podniku.
Inteligentné koncové body a hlúpe potrubia
Architektúra SOA venovala veľkú pozornosť komunikačným kanálom, najmä Enterprise Service Bus. Čo často vedie k Erroneous Spaghetti Box, to znamená, že zložitosť monolitu sa mení na zložitosť spojení medzi službami. Architektúra mikroservisov využíva iba jednoduché komunikačné metódy.
Decentralizované riadenie
Kľúčové rozhodnutia o mikroslužbách by mali robiť ľudia, ktorí mikroslužby skutočne vyvíjajú. Tu kľúčové rozhodnutia znamenajú voľby
programovacie jazyky, metodika nasadenia, zmluvy s verejným rozhraním atď.
Decentralizovaná správa údajov
Štandardný prístup, v ktorom sa aplikácia spolieha na jednu databázu, nemôže brať do úvahy špecifiká každej konkrétnej služby. MSA zahŕňa decentralizovanú správu údajov vrátane využívania rôznych technológií.
Automatizácia infraštruktúry
MSA podporuje nepretržité procesy nasadzovania a doručovania. To sa dá dosiahnuť iba automatizáciou procesov. Zároveň nasadenie veľkého množstva služieb už nevyzerá ako niečo strašidelné. Proces nasadenia by sa mal stať nudným. Druhý aspekt súvisí s riadením služieb v prostredí produktu. Bez automatizácie je riadenie procesov bežiacich v rôznych operačných prostrediach nemožné.
Dizajn pre zlyhanie
Početné služby MSA sú náchylné na zlyhanie. Ošetrenie chýb v distribuovanom systéme zároveň nie je triviálna úloha. Architektúra aplikácie musí byť odolná voči takýmto zlyhaniam. Rebecca Parsons si myslí, že je veľmi dôležité, aby sme už ani nepoužívali komunikáciu medzi službami počas procesu; namiesto toho sa na komunikáciu uchyľujeme k HTTP, ktoré nie je ani zďaleka také spoľahlivé.
Architektúra s evolučným vývojom (Evolutionary Design)
Architektúra systému MSA by sa mala vyvíjať evolučne. Je vhodné obmedziť potrebné zmeny na hranice jedinej služby. Je potrebné vziať do úvahy aj vplyv na ostatné služby. Tradičným prístupom je pokúsiť sa vyriešiť tento problém verziou, ale MSA navrhuje použitie verzií v
ako posledná možnosť.
Záver
Po všetkom vyššie uvedenom môžeme sformulovať, čo sú mikroslužby. Architektúra mikroslužieb je prístup k vývoju jednej aplikácie ako kolekcie malých služieb, z ktorých každá beží vo svojom vlastnom procese a interaguje prostredníctvom ľahkých mechanizmov, často API zdrojov HTTP. Tieto služby sú postavené na podnikových schopnostiach a možno ich nasadiť samostatne
automatizovaný mechanizmus nasadenia. Existuje minimálna úroveň centralizovaného riadenia týchto služieb, ktoré môžu byť napísané v rôznych programovacích jazykoch a používať rôzne technológie ukladania údajov.
Zdroj: hab.com