Programování

4 strategie nasazení pro odolné mikroslužby

Vytváření aplikací s mikroslužbami poskytuje vývojářům větší rychlost a hbitost než tradiční architektury. Každá změna kódu však stále přináší rizika, což připravuje půdu pro potenciální selhání, pokud nebudou objeveny a vyřešeny problémy s kvalitou kódu. Aby se tato rizika zmírnila, měly by aplikační týmy implementovat moderní strategie směrování založené na cloudu, které usnadní testování nebezpečí a zajistí, že aplikace budou skutečně připraveny k nasazení v produkčním prostředí.

Následující čtyři strategie nasazení využívají směrovací techniky k bezpečnému zavedení nových služeb a funkcí, testování funkčnosti a provádění iterativních vylepšení, identifikaci a eliminaci slabých míst a další. Společně jsou tyto přístupy virtuální sadou nástrojů, do které se mohou aplikační týmy dostat za účelem snížení rizika během vývoje a nasazení aplikací podporovaných mikroslužbami. Pochopení jejich rozdílů a podobností bude klíčem k tomu, abyste věděli, jak je nejlépe využít ve svém vlastním prostředí.

Kanárské nasazení

Pojmenováno po historické praxi posílání skutečných ptáků do uhelných dolů, aby se zjistilo, zda je kvalita ovzduší pro člověka bezpečná, jsou kanárská rozmístění způsobem, jak testovat skutečné rozmístění produkce s minimálním dopadem nebo rizikem. Tzv. Kanár je kandidátská verze služby, která zachytí určité procento podmnožiny příchozích požadavků (řekněme 1%) k vyzkoušení nových funkcí nebo sestavení. Týmy pak mohou zkoumat výsledky a pokud to půjde hladce, postupně zvyšujte nasazení na 100% serverů nebo uzlů. A pokud ne? Provoz lze rychle přesměrovat z kanárských nasazení, zatímco se problematický kód kontroluje a ladí.

Kanárská nasazení lze implementovat prostřednictvím integrací s komponentami směrování okrajů odpovědnými za zpracování příchozího uživatelského provozu. Například v prostředí Kubernetes může kanárské nasazení klepnout na konfiguraci řadiče příchozího přenosu a přiřadit určitá procenta požadavků na provoz stabilním a kanárským nasazením. Směrování provozu tímto způsobem zajišťuje, že nové služby budou mít šanci prokázat se před přijetím úplného zavedení. Pokud tak neučiní, pošlou se zpět, aby odstranili problémy, a poté, když budou připraveni, projdou dalším kolem testování nasazení na kanárských ostrovech.

A / B testování

A / B testování je podobné jako u kanárských rozmístění, s jedním důležitým rozdílem. Zatímco kanárská nasazení mají tendenci se soustředit na identifikaci chyb a úzkých míst výkonu, testování A / B se zaměřuje na měření přijetí uživatelem nových funkcí aplikace. Například vývojáři možná budou chtít vědět, zda jsou nové funkce u uživatelů oblíbené, zda je lze snadno objevit nebo zda uživatelské rozhraní funguje správně.

Tento vzor používá směrování softwaru k aktivaci a testování konkrétních funkcí s různými segmenty provozu, vystavení nových funkcí určitému procentu provozu nebo omezeným skupinám. Segmenty směrování A a B mohou odesílat provoz do různých sestavení softwaru nebo instance služby mohou dokonce používat stejné sestavení softwaru, ale s různými atributy konfigurace (jak je uvedeno v orchestrátoru nebo jinde).

Modrozelené nasazení

Modrozelený vzor nasazení zahrnuje paralelní provozování dvou produkčních prostředí: jedno pro aktuální stabilní vydání (modré) a jedno pro fázi a provedení testování v dalším vydání (zelené). Tato strategie umožňuje vydávání aktualizovaných verzí softwaru snadno opakovatelným způsobem. Týmy Devops mohou pomocí této techniky automatizovat zavádění nových verzí pomocí kanálu CI / CD.

S modrozelenou strategií vývojáři nasazují novou verzi služby vedle stávající instance, která aktuálně zpracovává produkční provoz. Potrubí CI / CD by mělo být nastaveno na provádění automatických kouřových testů, aby se ověřilo, že nová verze uspěje ve své klíčové funkčnosti. Jakmile nová služba prošla posledními testy, lze provoz bezpečně a automaticky přesměrovat na něj pomocí softwarového směrování k bezproblémové správě přerušení provozu z modré na zelenou. Stejně důležité je, že v případě kritických problémů na poslední chvíli je jednoduché vrátit nasazení do modré verze, pokud dojde k kritickým problémům.

Dopravní stínování

Stínování provozu je podobné modrozeleným nasazením, ale namísto použití syntetických testů k ověření „zeleného“ prostředí směrovací technologie duplikuje veškerý příchozí produkční provoz a zrcadlí jej do samostatného testovacího nasazení, které ještě není veřejné. Stínování provozu tedy vytváří přesný obraz toho, co by se stalo, kdyby byla nasazena nová verze, na základě skutečného provozu. Současně stínování provozu zajišťuje, že testy nemají žádný dopad na skutečnou produkci. V praxi se vývojáři mohou rozhodnout duplikovat stanovené procento požadavků na testovací službu, kde pak mohou provádět testování integrace a porovnávání výkonu (buď ručně, nebo v rámci automatizovaného kanálu CI / CD).

Podnikoví vývojáři již využívají řadu testovacích technik, jejichž cílem je zajistit, aby nový kód aplikace splňoval určité požadavky. Například základní a funkční testy zůstávají základními opatřeními, která musí kód vymazat. Díky povaze architektur založených na mikroslužbách je testování integrace end-to-end důležitější než kdy dříve. Vzhledem k objemu vzájemných závislostí a riziku dlouhodobého posunu rozhraní, které jsou vlastní architekturám mikroslužeb, mají syntetické testy stále hodnotu, ale nakonec nedosáhnou toho, aby přesně představovaly všechny interakce mezi službami v produkčních prostředích.

Čtyři strategie, jeden cíl

Všechny tyto techniky směrování nabízejí odlišné, přesto související metody pomoci při zjišťování, zmírňování a testování defektů v aplikacích založených na mikroslužbách. Jsou to silné nástroje pro řešení chyb, problémů s výkonem a bezpečnostních slabin, zvláště pokud jsou nasazeny jako součást komplexního kanálu kontinuální integrace a doručování (CI / CD).

Která z těchto metod je pro váš případ nejvhodnější, bude do značné míry záviset na tom, jaké obavy jsou nejdůležitější. Například velká revize uživatelského rozhraní může z A / B testování značně těžit, zatímco modrozelené nasazení může být neocenitelné, aby se zjistilo, jak může nová funkce ovlivnit výkon existujícího úložiště dat.

Kombinace těchto technik může často nabídnout nejlepší pokrytí. Je však důležité zvážit, jak dobře se bude každý integrovat s vaším stávajícím vývojovým modelem. Kanárské rozmístění jednotlivých funkcí může být vhodnější například pro agilní vývojové metody než modrozelené rozmístění plných verzí. A zatímco stínování provozu může poskytnout vynikající přehled o předběžném nasazení výkonu aplikace, může být obtížné a časově náročné jej implementovat a nákladně z hlediska výpočetních prostředků.

Nicméně, jak je zaměstnáváte, směrovací techniky, jako jsou tyto, mohou být neocenitelnou součástí procesu vývoje softwaru, zejména když se průmysl odkloní od tradičních monolitických aplikací směrem k cloudovým nativním systémům založeným na mikroslužbách. Použitím jedné, některé nebo všech těchto technik, přičemž si budou vědomy svých specifických výhod, mohou aplikační týmy lépe zajistit integritu a úspěch svých projektů a spolehlivěji přejít do výroby.

Manuel Zapf je vedoucím produktu OSS ve společnosti Containous, cloudové síťové společnosti, která stojí za open source projekty Traefik a Maesh.

Nové technologické fórum poskytuje místo, kde můžete prozkoumat a diskutovat o nově vznikajících podnikových technologiích v nebývalé hloubce a šíři. Výběr je subjektivní, založený na našem výběru technologií, které považujeme za důležité a pro čtenáře nejzajímavější. nepřijímá marketingové materiály ke zveřejnění a vyhrazuje si právo upravovat veškerý přispěný obsah. Všechny dotazy zasílejte na [email protected].

$config[zx-auto] not found$config[zx-overlay] not found