Ahoj, Habr. Dnes pokračuji v sérii publikací, kterou jsem napsal speciálně k zahájení nového běhu kurzu .
Úvod
Volba architektonického stylu je jedním z klíčových technických rozhodnutí při vytváření informačního systému. V této sérii článků se pokusím prozkoumat nejpopulárnější architektonické styly pro výstavbu aplikací a odpovědět na otázku, kdy je jaký architektonický styl nejvhodnější. Během vyprávění se pokusím provést logickou linii, která vysvětluje vývoj architektonických stylů od monolitů po mikroservisy.
Minule jsme hovořili o různých typech monolitů a o používání komponentů pro jejich stavbu, jak komponentů sestavení, tak komponentů nasazení. Zjistili jsme, co je to architektura orientovaná na služby.
Nyní konečně definujeme hlavní charakteristiky mikroservisní architektury.
Vztah architektur
Je třeba chápat, že na základě předchozích definic je jakákoliv služba komponentou, ale ne každá služba je mikroservis.
Charakteristiky mikroservisní architektury
Hlavními charakteristikami mikroservisní architektury jsou:
- Organizace podle obchodních schopností (Organized around Business Capabilities)
- Produkty, ne projekty (Products not Projects)
- Inteligentní vstupy a hloupé kanály (Smart endpoints and dumb pipes)
- Decentralizované řízení (Decentralized Governance)
- Decentralizované řízení dat (Decentralized Data Management)
- Automatizace infrastruktury (Infrastructure Automation)
- Pojistka proti selhání (Design for failure)
- Architektura s evolučním vývojem (Evolutionary Design)
1. bod vychází ze služby orientované na služby, protože mikroservisy jsou zvláštním případem služeb. Ostatní body si zaslouží samostatné projednání.
Organizace podle obchodních schopností (Organized around Business Capabilities)
Nyní je nutné si připomenout Conwayův zákon: organizace vytvářející systémy organizují jejich architekturu, která kopíruje strukturu interakce uvnitř těchto organizací. Jako příklad si můžeme vzpomenout na případ vývoje kompilátoru: tým sedmi lidí vyvinul sedmiprasový kompilátor, zatímco tým pěti lidí — pětiprasový.
Pokud hovoříme o monolitech a mikroslužbách, v případě, že je vývoj organizován podle funkčních oddělení (backend, frontend, administrace databází), vzniká klasický monolit.
Pro získání mikroslužeb je nutné organizovat týmy podle obchodních příležitostí (tým objednávek, expedice, katalog). Taková organizace umožní týmům soustředit se na vytváření konkrétních částí aplikace.
Produkty, ne projekty (Products not Projects)
Projektový přístup, kdy tým předává vyvinutou funkcionalitu jiným týmům v případě mikroslužbové architektury, se zcela nehodí. Tým by měl podporovat systém po celou dobu jeho životního cyklu. Společnost Amazon, jedna z průkopnic zavádění mikroslužeb, prohlašovala: „vytváříte produkt, a vy ho také spouštíte“ („you build, you run it“). Produktový přístup umožňuje týmu pocítit potřeby podnikání.
Inteligentní vstupy a hloupé kanály (Smart endpoints and dumb pipes)
Architektura SOA věnovala velkou pozornost komunikačním kanálům, zejména Enterprise Service Bus (služební sběrnici podniku). Což často vede k Erroneous Spaghetti Box, tedy složitost monolitu se přenáší do složitosti vztahů mezi službami. V mikroslužbové architektuře jsou používány pouze jednoduché způsoby interakce.
Decentralizované řízení (Decentralized Governance)
Klíčová rozhodnutí ohledně mikroslužeb by měli přijímat lidé, kteří skutečně vyvíjejí mikroslužby. Zde se pod klíčovými rozhodnutími rozumí volba
programovacích jazyků, metodologie nasazení, kontraktů veřejných rozhraní atd.
Decentralizované řízení dat (Decentralized Data Management)
Standardní přístup, kdy aplikace spoléhá na jednu databázi, nemůže zohlednit specifika každé jednotlivé služby. MSA předpokládá decentralizované řízení dat, až po použití různých technologií.
Automatizace infrastruktury (Infrastructure Automation)
MSA podporuje procesy kontinuálního nasazení a dodávání. Toho lze dosáhnout pouze automatizací procesů. Přitom nasazení velkého množství služeb už nevypadá jako něco hrozného. Proces nasazení by se měl stát nudným. Druhý aspekt se týká řízení služeb v produkčním prostředí. Bez automatizace se řízení procesů spuštěných v různých operačních prostředích stává nemožným.
Pojistka proti selhání (Design for failure)
Mnohé služby MSA jsou náchylné k chybám. Zpracování chyb v distribuovaných systémech je však velmi netriviální úkol. Architektura aplikací by měla být odolná vůči těmto chybám. Rebecca Parsons považuje za velmi důležité, abychom již nepoužívali ani meziprocesovou komunikaci mezi službami; 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 měla vyvíjet evolučně. Je vhodné omezit nezbytné změny hranicemi jedné služby. Je také nutné vzít v úvahu vliv na ostatní služby. Tradiční přístup spočívá v pokusu o řešení tohoto problému pomocí řízení verzí, ale MSA znamená používat řízení verzí jako
poslední možnost.
Závěr
Po všech výše zmíněných skutečnostech lze formulovat, co jsou mikroservisy. Mikroservisní architektura je přístup k vývoji jednotlivé aplikace jako sada malých služeb, z nichž každá pracuje ve svém vlastním procesu a vzájemně interaguje pomocí zjednodušených mechanismů, často prostřednictvím API rozhraní HTTP zdrojů. Tyto služby jsou postaveny na obchodních možnostech a mohou být nasazeny nezávisle pomocí zcela
automatizovaného mechanismu nasazení. Existuje minimální úroveň centralizovaného řízení 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: habr.com
