Prázdniny skončily a my jsme zpět s naším druhým příspěvkem v sérii Istio Service Mesh.
Dnešním tématem je Circuit Breaker, což v překladu do ruské elektrotechniky znamená „jistič“, v běžné řeči – „jistič“. Pouze v Istiu tento stroj nerozpojuje zkratovaný nebo přetížený obvod, ale vadné nádoby.
Jak by to mělo ideálně fungovat
Když jsou mikroslužby spravovány Kubernetes, například v rámci platformy OpenShift, automaticky se škálují nahoru a dolů v závislosti na zatížení. Protože mikroslužby běží v podech, může existovat více instancí kontejnerové mikroslužby na jednom koncovém bodu a Kubernetes mezi nimi směruje požadavky a vyrovnává zatížení. A – v ideálním případě – by to vše mělo perfektně fungovat.
Pamatujeme si, že mikroslužby jsou malé a pomíjivé. Pomíjivost, která zde znamená snadnost objevování a mizení, je často podceňována. Zrození a smrt další instance mikroslužby v podu jsou docela očekávané věci, OpenShift a Kubernetes to zvládají dobře a vše funguje skvěle - ale opět teoreticky.
Jak to vlastně funguje
Nyní si představte, že se konkrétní instance mikroslužby, tedy kontejner, stala nepoužitelnou: buď neodpovídá (chyba 503), nebo, což je nepříjemnější, reaguje, ale příliš pomalu. Jinými slovy, stává se závadným nebo nereaguje na požadavky, ale není automaticky odstraněn z fondu. Co je třeba v tomto případě udělat? Chcete to zkusit znovu? Mám to odstranit ze schématu směrování? A co znamená „příliš pomalé“ – kolik je to v číslech a kdo je určuje? Možná tomu dát pauzu a zkusit to znovu později? Pokud ano, o kolik později?
Co je vysunutí bazénu v Istiu
A zde přichází na pomoc společnost Istio se svými ochrannými stroji Circuit Breaker, které dočasně odstraňují vadné kontejnery z fondu zdrojů pro směrování a vyrovnávání zátěže, přičemž implementují proceduru Pool Ejection.
Pomocí strategie detekce odlehlých hodnot Istio detekuje křivkové moduly, které jsou mimo linii, a odstraňuje je z fondu zdrojů na určitou dobu, která se nazývá okno spánku.
Abychom ukázali, jak to funguje v Kubernetes na platformě OpenShift, začněme screenshotem normálně fungujících mikroslužeb z příkladu v úložišti . Zde máme dva pody, v1 a v2, každý s jedním kontejnerem. Když se nepoužívají pravidla směrování Istio, Kubernetes jako výchozí použije rovnoměrně vyvážené kruhové směrování:
Příprava na havárii
Než provedete vysunutí bazénu, musíte vytvořit pravidlo směrování Istio. Řekněme, že chceme rozdělit požadavky mezi moduly v poměru 50/50. Navíc zvýšíme počet kontejnerů v2 z jednoho na dva, a to takto:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
Nyní nastavíme pravidlo směrování tak, aby byl provoz distribuován mezi moduly v poměru 50/50.
Výsledek tohoto pravidla vypadá takto:
Můžete najít chybu v tom, že tato obrazovka není 50/50, ale 14:9, ale časem se situace zlepší.
Dělat závadu
Nyní deaktivujeme jeden ze dvou kontejnerů v2, abychom měli jeden zdravý kontejner v1, jeden zdravý kontejner v2 a jeden vadný kontejner v2:
Oprava závady
Takže máme vadný kontejner a je čas na vysunutí bazénu. Pomocí velmi jednoduché konfigurace vyřadíme tento neúspěšný kontejner ze všech směrovacích schémat na 15 sekund v naději, že se vrátí do zdravého stavu (buď restart nebo obnovení výkonu). Takto vypadá tato konfigurace a výsledky její práce:
Jak můžete vidět, kontejner verze 2, který selhal, se již nepoužívá pro požadavky na směrování, protože byl odebrán z fondu. Ale po 15 sekundách se automaticky vrátí do bazénu. Ve skutečnosti jsme právě ukázali, jak funguje Pool Ejection.
Začněme budovat architekturu
Pool Ejection v kombinaci s monitorovacími schopnostmi Istio vám umožňuje začít budovat rámec pro automatickou výměnu vadných kontejnerů, aby se snížily, ne-li eliminovaly, prostoje a poruchy.
NASA má jedno hlasité motto – Failure Is Not an Option, za jehož autora je považován letový ředitel . Do ruštiny se to dá přeložit jako „Neúspěch není možnost“, a to znamená, že všechno může fungovat, pokud máte dostatek vůle. Ve skutečném životě se však neúspěchy nestávají jen tak, jsou nevyhnutelné, všude a ve všem. A jak se s nimi vypořádat v případě mikroslužeb? Podle nás je lepší spoléhat ne na vůli, ale na schopnosti kontejnerů, , A .
Istio, jak jsme psali výše, implementuje koncept jističů, který se dobře osvědčil ve fyzickém světě. A stejně jako jistič elektrického obvodu vypíná problémovou část obvodu, software Circuit Breaker společnosti Istio otevírá spojení mezi proudem požadavků a problémovým kontejnerem, když je s koncovým bodem něco v nepořádku, například když se server zhroutil nebo začal zpomal.
Navíc ve druhém případě je pouze více problémů, protože brzdy jednoho kontejneru nejen způsobují kaskádu zpoždění služeb, které k němu přistupují, a v důsledku toho snižují výkon systému jako celku, ale také generují opakované požadavky na již pomalu běžící službu, což situaci jen zhoršuje .
Jistič teoreticky
Circuit Breaker je proxy, která řídí tok požadavků ke koncovému bodu. Když tento bod přestane fungovat nebo se v závislosti na zadaných nastaveních začne zpomalovat, proxy přeruší spojení s kontejnerem. Provoz je pak přesměrován do jiných kontejnerů, jednoduše kvůli vyrovnávání zátěže. Připojení zůstává otevřené po dané okno spánku, řekněme dvě minuty, a poté je považováno za polootevřené. Pokus o odeslání dalšího požadavku určuje další stav připojení. Pokud je se službou vše v pořádku, spojení se vrátí do funkčního stavu a opět se uzavře. Pokud je se službou stále něco v nepořádku, připojení se odpojí a okno spánku se znovu povolí. Zde je návod, jak vypadá zjednodušený stavový diagram jističe:
Zde je důležité poznamenat, že toto vše se děje na úrovni takříkajíc systémové architektury. V určitém okamžiku tedy budete muset své aplikace naučit pracovat s jističem, například poskytnutím výchozí hodnoty v reakci nebo, pokud je to možné, ignorováním existence služby. K tomu se používá přepážkový vzor, ale to je nad rámec tohoto článku.
Jistič v praxi
Například na OpenShift spustíme dvě verze naší doporučovací mikroslužby. Verze 1 bude fungovat dobře, ale ve verzi 2 zabudujeme zpoždění pro simulaci zpomalení na serveru. Chcete-li zobrazit výsledky, použijte nástroj :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Zdá se, že vše funguje, ale za jakou cenu? Na první pohled máme 100% dostupnost, ale podívejte se blíže – maximální doba trvání transakce je celých 12 sekund. To je zjevně úzké místo a je třeba jej rozšířit.
K tomu použijeme Istio k odstranění volání pomalých kontejnerů. Takto vypadá odpovídající konfigurace pomocí Circuit Breaker:
Poslední řádek s parametrem httpMaxRequestsPerConnection signalizuje, že spojení s by mělo být přerušeno při pokusu o vytvoření dalšího - druhého - připojení k existujícímu. Vzhledem k tomu, že náš kontejner simuluje pomalou službu, k takovým situacím dochází pravidelně a Istio vrátí chybu 503, ale toto obléhání ukáže:
OK, máme Circuit Breaker, co bude dál?
Implementovali jsme tedy automatické vypnutí, aniž bychom se vůbec dotkli zdrojového kódu samotných služeb. Pomocí Circuit Breaker a postupu Pool Ejection popsaného výše můžeme odstraňovat brzdové kontejnery z fondu zdrojů, dokud se nevrátí do normálu, a kontrolovat jejich stav ve stanovené frekvenci – v našem příkladu jsou to dvě minuty (parametr sleepWindow).
Všimněte si, že schopnost aplikace reagovat na chybu 503 je stále nastavena na úrovni zdrojového kódu. Existuje mnoho strategií pro použití jističe v závislosti na situaci.
V dalším příspěvku: Budeme mluvit o sledování a monitorování, které je již vestavěno nebo snadno přidáno do Istio, a také o tom, jak záměrně zavádět chyby do systému.
Zdroj: www.habr.com