V roce 1984 Rob Pike a Brian W. Kernighan publikovali článek nazvaný „Program Design in the Unix Environment“ v AT&T Bell Laboratories Technical Journal, ve kterém argumentovali filozofií Unixu na příkladu cat -v
Zní vám to povědomě?
Jo, myslel jsem si to. To je v podstatě definice mikroslužeb, kterou nabízejí James Lewis a Martin Fowler:
Stručně řečeno, architektonický styl mikroslužeb je přístup k vývoji jedné aplikace jako sady malých služeb, z nichž každá běží ve svém vlastním procesu a komunikuje s lehkými mechanismy, často s API prostředku HTTP.
Zatímco jeden *nixový program nebo jedna mikroslužba mohou být velmi omezené nebo dokonce ne příliš zajímavé samy o sobě, je to právě kombinace těchto samostatně pracujících jednotek, která odhaluje jejich skutečný přínos, a tedy i jejich sílu.
*nix vs. mikroslužby
Následující tabulka porovnává programy (jako je cat nebo lsof ) v prostředí *nix proti programům v prostředí mikroslužeb.
| *nix | Mikroslužby | |
|---|---|---|
| Jednotka provádění | program pomocí stdin /stdout | služba s HTTP nebo gRPC API |
| Datový tok | Potrubí | ? |
| Konfigurace a parametrizace | Argumenty příkazového řádku, proměnné prostředí, konfigurační soubory | Dokumenty JSON/YAML |
| Zjištění | Správce balíčků, člověče, značka | DNS, proměnné prostředí, OpenAPI |
Pojďme prozkoumat každý řádek trochu podrobněji.
Jednotka provedení
Více o Microservices
- Cheat sheet Microservices
- Jak vysvětlit mikroslužby svému generálnímu řediteli
- Zdarma e-kniha:Mikroslužby vs. architektura orientovaná na služby
- Bezplatný online kurz:Vývoj cloudových nativních aplikací s architekturou mikroslužeb
- Nejnovější články o mikroslužbách
Jednotkou spuštění v *nix (jako je Linux) je spustitelný soubor (binární nebo interpretovaný skript), který v ideálním případě čte vstup z stdin a zapíše výstup do stdout . Nastavení mikroslužeb se zabývá službou, která zpřístupňuje jedno nebo více komunikačních rozhraní, jako jsou HTTP nebo gRPC API. V obou případech najdete bezstavové příklady (v podstatě čistě funkční chování) a stavové příklady, kde o tom, co se stane, rozhoduje kromě vstupu nějaký vnitřní (přetrvávající) stav.
Datový tok
Tradičně mohly programy *nix komunikovat prostřednictvím rour. Jinými slovy, díky Dougu McIlroyovi nemusíte vytvářet dočasné soubory, které by bylo možné předávat, a každý může zpracovávat prakticky nekonečné proudy dat mezi procesy. Pokud je mi známo, kromě mého malého experimentu založeného na Apache Kafka z roku 2017 neexistuje nic srovnatelného s potrubím standardizovaným v mikroslužbách.
Konfigurace a parametrizace
Jak nakonfigurujete program nebo službu – ať už trvale nebo jako vedlejší hovor? U programů *nix máte v podstatě tři možnosti:argumenty příkazového řádku, proměnné prostředí nebo plnohodnotné konfigurační soubory. V mikroslužbách se obvykle zabýváte dokumenty YAML (nebo ještě hůře, JSON), definujete rozvržení a konfiguraci jedné mikroslužby a také závislosti a nastavení komunikace, úložiště a běhu. Příklady zahrnují definice prostředků Kubernetes, specifikace úloh Nomad nebo soubory Docker Compose. Ty mohou nebo nemusí být parametrizovány; to znamená, že buď máte nějaký šablonovací jazyk, jako je Helm v Kubernetes, nebo zjistíte, že děláte strašně moc sed -i příkazy.
Objevování
Jak víte, jaké programy nebo služby jsou k dispozici a jak se mají používat? No, v *nix máte obvykle správce balíčků a také dobrého starého muže; mezi nimi by měli být schopni odpovědět na všechny otázky, které byste mohli mít. V nastavení mikroslužeb je při hledání služby trochu více automatizace. Kromě přístupů na míru, jako je SmartStack od Airbnb nebo Eureka od Netflixu, obvykle existují přístupy založené na proměnných prostředí nebo DNS, které vám umožňují dynamicky objevovat služby. Stejně důležité je, že OpenAPI poskytuje de-facto standard pro dokumentaci a návrh HTTP API a gRPC dělá totéž pro těsněji propojené vysoce výkonné případy. V neposlední řadě vezměte v úvahu vývojářské zkušenosti (DX), počínaje psaním dobrých souborů Makefiles a konče psaním dokumentů (nebo v?) stylu .
Pro a proti
*nix i mikroslužby nabízejí řadu výzev a příležitostí
Složitelnost
Je těžké navrhnout něco, co má jasné, ostré zaostření a navíc může dobře hrát s ostatními. Ještě těžší je to správně nastavit v různých verzích a zavést příslušné možnosti zpracování případu chyb. V mikroslužbách by to mohlo znamenat logiku opakování a časové limity – možná je lepší možnost outsourcovat tyto funkce do sítě služeb? Je to těžké, ale pokud to pochopíte správně, jeho znovupoužitelnost může být obrovská.
Pozorovatelnost
V monolitu (v roce 2018) nebo velkém programu, který se o to všechno pokouší (v roce 1984), je poměrně jednoduché najít viníka, když věci jdou na jih. Ale v
yes | tr \\n x | head -c 450m | grep nnebo cestu požadavku v nastavení mikroslužeb, které zahrnuje řekněme 20 služeb, jak vůbec začít zjistit, který z nich se chová špatně? Naštěstí máme standardy, zejména OpenCensus a OpenTracing. Pozorovatelnost může být stále největším blokátorem, pokud se chystáte přejít na mikroslužby.
Globální stát
I když to nemusí být tak velký problém pro programy *nix, v mikroslužbách zůstává globální stav něčím jako diskuse. Jmenovitě, jak zajistit, aby byl místní (trvalý) stav řízen efektivně a jak zajistit soulad globálního stavu s co nejmenším úsilím.
Zabalení
Na závěr zbývá otázka:Používáte pro daný úkol správný nástroj? To znamená, že stejně jako specializovaný *nix program implementující řadu funkcí může být lepší volbou pro určité případy použití nebo fáze, může se stát, že monolit je nejlepší volbou pro vaši organizaci nebo pracovní zátěž. Bez ohledu na to doufám, že vám tento článek pomůže vidět mnoho silných paralel mezi filozofií Unixu a mikroslužbami – možná se od první z nich můžeme něco naučit, abychom pro ni měli prospěch.