Dobrý den, Habr. Dnes pokračuji v sérii publikací, které jsem napsal speciálně pro začátek nového proudu kurzu. .
úvod
Volba architektonického stylu je jedním ze zásadních technických rozhodnutí při budování informačního systému. V této sérii článků navrhuji analyzovat nejoblíbenější architektonické styly pro stavební aplikace a odpovědět na otázku, kdy je který architektonický styl nejvýhodnější. V procesu prezentace se pokusím nakreslit logický řetězec, který vysvětluje vývoj architektonických stylů od monolitů po mikroslužby.
Minule jsme hovořili o různých typech monolitů a použití komponent k jejich sestavení, a to jak komponent sestavení, tak komponent pro nasazení. Rozumíme architektuře orientované na služby.
Nyní konečně definujeme hlavní charakteristiky architektury mikroslužeb.
Vztah architektur
Je nutné pochopit, že na základě definic uvedených v předchozích článcích je každá služba komponentou, ale ne každá služba je mikroslužba.
Charakteristika architektury Microservice
Hlavní charakteristiky architektury mikroslužeb jsou:
- Organizované kolem obchodních schopností
- Produkty ne projekty
- Inteligentní koncové body a hloupé trubky
- Decentralizované řízení
- Decentralizovaná správa dat
- Automatizace infrastruktury
- Design pro selhání
- Architektura s evolučním vývojem (Evolutionary Design)
První bod pochází z architektury orientované na služby, protože mikroslužby jsou speciálním případem služeb. Další body si zaslouží samostatnou úvahu.
Organizované kolem obchodních schopností
Nyní je třeba si připomenout Conwayův zákon: organizace, které vytvářejí systémy, organizují jeho architekturu a kopírují strukturu interakce uvnitř těchto organizací. Jako příklad si můžeme připomenout případ vytvoření kompilátoru: tým sedmi lidí vyvinul sedmiprůchodový překladač a pětiprůchodový překladač.
Pokud se bavíme o monolitech a mikroslužbách, tak pokud je vývoj organizován funkčními odděleními (backend, frontend, administrátoři databází), tak dostaneme klasický monolit.
Pro získání mikroslužeb musí být týmy organizovány podle obchodních schopností (objednávky, zásilky, katalogový tým). Tato organizace umožní týmům soustředit se na vytváření konkrétních částí aplikace.
Produkty ne projekty
Projektový přístup, kdy tým předává vyvinutou funkcionalitu dalším týmům, je v případě architektury mikroslužeb zcela nevhodný. Tým musí podporovat systém po celou dobu jeho životního cyklu. Amazon, jeden z lídrů v implementaci mikroslužeb, prohlásil: „Vy postavíte, spustíte to.“ Produktový přístup umožňuje týmu cítit potřeby podniku.
Inteligentní koncové body a hloupé trubky
Architektura SOA věnovala velkou pozornost komunikačním kanálům, zejména Enterprise Service Bus. Což často vede k Erroneous Spaghetti Box, tedy složitost monolitu přechází ve složitost propojení mezi službami. Architektura mikroslužeb využívá pouze jednoduché komunikační metody.
Decentralizované řízení
Klíčová rozhodnutí o mikroslužbách by měli činit lidé, kteří mikroslužby skutečně vyvíjejí. Zde klíčová rozhodnutí znamenají volby
programovací jazyky, metodika nasazení, smlouvy o veřejném rozhraní atd.
Decentralizovaná správa dat
Standardní přístup, kdy se aplikace spoléhá na jedinou databázi, nemůže zohledňovat specifika každé konkrétní služby. MSA zahrnuje decentralizovanou správu dat, včetně využití různých technologií.
Automatizace infrastruktury
MSA podporuje procesy nepřetržitého zavádění a dodávání. Toho lze dosáhnout pouze automatizací procesů. Nasazení velkého množství služeb už přitom nevypadá jako něco děsivého. Proces nasazení by měl být nudný. Druhý aspekt souvisí se správou služeb v prostředí produktu. Bez automatizace je řízení procesů běžících v různých operačních prostředích nemožné.
Design pro selhání
Četné služby MSA jsou náchylné k selhání. Ošetření chyb v distribuovaném systému přitom není triviální úkol. Architektura aplikace musí být odolná vůči takovýmto selháním. Rebecca Parsons si myslí, že je velmi důležité, abychom už ani nepoužívali komunikaci mezi službami v průběhu procesu, místo toho se pro komunikaci uchylujeme k HTTP, které není zdaleka tak spolehlivé.
Architektura s evolučním vývojem (Evolutionary Design)
Architektura systému MSA by se měla vyvíjet evolučně. Je vhodné omezit nutné změny na hranice jedné služby. Je třeba vzít v úvahu i dopad na ostatní služby. Tradičním přístupem je pokusit se tento problém vyřešit verzováním, ale MSA doporučuje používat verzování v
jako poslední možnost.
Závěr
Po všem výše uvedeném můžeme formulovat, co jsou mikroslužby. Architektura mikroslužeb je přístup k vývoji jediné aplikace jako kolekce malých služeb, z nichž každá běží ve svém vlastním procesu a interaguje prostřednictvím odlehčených mechanismů, často rozhraní API zdroje HTTP. Tyto služby jsou založeny na podnikových možnostech a lze je nasadit nezávisle na plném využití
mechanismus automatického nasazení. Existuje minimální úroveň centralizované správy těchto služeb, které mohou být napsány v různých programovacích jazycích a používat různé technologie ukládání dat.
Zdroj: www.habr.com