Výše uvedený obrázek je Tencentova verze v odstínech šedi, běžní uživatelé k ní mají přístup, server Alibaba Cloud není přístupný, ping je normální a IP rozlišení je také normální
Je to prostě nedostupné, je vidět, že Tencent si také rád hraje s šedotónovým uvolněním...
1. Proč vydání v odstínech šedi
- Internetové služby se často mění a cykly vydávání jsou krátké. Rychlost a kvalita se vždy těžko kombinují.
- Šedobílé vydávání může snížit riziko publikování a rozsah dopadu.
- Snížit závislost na testování a snížit náklady na tvorbu dat pro offline samotestování.
- Je pohodlné centrálně monitorovat logy a zveřejňovat je v plném rozsahu Díky roli vyvažování zátěže na každé vrstvě je obtížné sledovat kompletní spojení hovoru.
- Můžete použít testovací účty v odstínech šedé a poté skutečné uživatelské účty v odstínech šedé po úspěšném testovacím účtu, abyste dále snížili riziko a dopad publikování.
- Snadné vrácení zpět.
Problémy, které nelze vyřešit vydáním v odstínech šedi
Je třeba zdůraznit, že výše zmíněný "tolerovatelný dopad" musí být obnovitelný, například API nelze volat po určitou dobu, ale po opravě jej lze úspěšně vyvolat. Trvalá ztráta nebo zničení uživatelských dat (například informací o produktech, objednávkách atd.) je nesnesitelná. Proto je odpovědností architektů internetových podniků opravit ztracená uživatelská data do nedávného stavu (například před hodinou až týdnem) ručním zásahem v případě ztráty uživatelských dat v důsledku poruch výrobního systému (například pravidelným zálohováním uživatelských dat, psaním provozních logů atd.).
TIPY: Nejprve otestujte politiku odstínů šedi na svém účtu, abyste snížili riziko poškození nebo ztráty dat skutečných uživatelů.
2. Jaký efekt se očekává?
Bez ohledu na změnu chceme, aby konkrétní požadavky byly směrovány do naší verze změny (verze v odstínech šedi) k pozorování a ověření.
3. Strategie odstínů šedi
Ve skutečnosti je to o tom, jaké požadavky by měly být směrovány do naší šedobílé verze (šedé stroje). To často úzce souvisí s podnikáním. Například u API platí obecně následující požadavky:
Konkrétní uživatelé (např. testovací účty)
Specifické aplikace (např. testovací nebo partnerské aplikace)
Specifické moduly a rozhraní (pouze některá rozhraní potřebují odstíny šedi, což je obecně modifikace API kontejnerů, a některá API, která nejsou příliš důležitá, se používají pro testování v odstínech šedi.) ）
Konkrétní stroj (některé IP žádosti jsou přeposílány na šedý stroj)
4. Diskuse o schématech v odstínech šedi
Řešení 1: Úroveň kódu je hodnocena podle dohodnuté vlajky a staré a nové jsou dynamicky přepínány – přístup Amazonu
Implementace:
Zakopněte spínač do kódu, udělejte if-else hodnocení a nastavte přepínač na zapnuté pro stroje, které vyžadují odstíny šedi, jinak je vypnutý. Každé vydání má dvě verze.
zásluha
Rychlý návrat zpět, není potřeba systém znovu publikovat a restartovat.
nedostatek
Buďte nakloněni dodržování předpisů.
Větvená logika přináší složitost.
Tuto metodu použil autor, když jsem byl v Alibabě, kdy jsem přepínal databázi zboží z Oracle na MySQL a používal stavovou proměnnou pro řízení. Tím se dosahuje efektu hladké migrace.
Možnost 2: Předpremiérový stroj - Alibabova praxe
Ve skutečnosti to není pravá šedá barva. Protože tento stroj před vydáním je interní IP a nemá žádnou externí službu. Pro ověření je vyžadováno doménové vázání. Ale data jsou zcela online. Takže je to v podstatě jednoduchý přístup pro některé konkrétní uživatele Grayscale (uživatele, kteří mají přístup k Grayscale stroji, interní testovací uživatele). Ve skutečnosti existuje podobný přístup i na straně API, což je naše prostředí Gamma, a také poskytujeme doménové jméno Gamma stroje, abychom usnadnili spolupráci externím kooperativním uživatelům při testování.
zásluha
Jednoduché
nedostatek
Plýtvání strojem (tento může být vložen do produkčního prostředí po dokončení předběžného vydání a odstraněn z nginx během předběžného vydání, ale je vyžadována podpora provozu a údržby.) ）
Není dostatečně flexibilní
IDL služby lze použít pouze pro přístupové vrstvy a IDL služby je třeba posuzovat samostatně.
Možnost 3: Nasazení SET
1. Nasazení izolovaně podle služeb
Například v současné praxi API kontejnerů lze granularitu nasazení dosáhnout až na úrovni API a front-end přesměruje podle nginx. Jako co:
Kontejner pro mikro nákupní API: api.weigou.qq.com
Pat API Container:api.paipai.com
Yixun API Container: api.yixun.com
Online nákupní API Container:api.buy.qq.com
Výše uvedené je izolované nasazení na úrovni velkých podniků. Lze jej dále zdokonalit na úrovni modulu, například API virtuálního e-commerce, což je podobchodní modul pod Paipai, ale protože jsou připojeny k WeChatu, počet návštěv se výrazně zvýšil, aby se zabránilo ovlivnění ostatních podniků Paipai a aby se zabránilo ovlivnění jinými podniky, API zde umožňuje samostatné nasazení dvou strojů, nginx lze nakonfigurovat tak, aby odčerpával přístup z virtuálního API:
Virtuální API kontejner: http://api.paipai.com/v2/virbiz
Tímto způsobem, když vydáváme verzi, můžeme nejprve vybrat Yixun s nejmenším obchodním objemem k publikaci a poté zjistit, že není problém, než použijeme všechny ostatní platformy.
2. Nasazení pomocí izolace uživatele
To není příliš vhodné pro otevřené platformy, ale je to velmi vhodné pro aplikační scénáře, jako je SNS. Například systém QQ je rozdělen do několika sad podle segmentů uživatelských čísel a každá sada obsahuje 100 milionů po sobě jdoucích čísel. Za předpokladu, že poslední QQ číslo je blízko 1 miliardy, je celkem 10 sad (Set 1 až Set 10). Tímto způsobem si můžete pokaždé vybrat jeden z SET, který chcete publikovat, a vysoce kvalitní QQ často není příliš důležitým uživatelem, takže SET10 bude vydáván jako první.
zásluha
Izolované nasazení s minimálním dopadem napříč obchodními liniemi. Automaticky podporujte publikování v odstínech šedi.
nedostatek
Granularita odstínů šedi závisí na granularitě izolovaného nasazení, která je obecně velká.
Plýtvání stroji ve srovnání s centralizovaným nasazením.
Verze jednotlivých obchodních linií mohou být nekonzistentní, což není vhodné pro jednotné řízení.
Existují určité náklady na implementaci a nasazení
Schéma 4: Dynamické směrování
Metoda: Použijte šedobarevnou politiku, kterou lze flexibilně nastavit tak, aby ovlivňovala chování load balance a umožnila vracet IP a port šedé služby podle této politiky.
Vhodné pro servis v odstínech šedi s back-office IDL.
zásluha
Flexibilní, ovladatelné.
nedostatek
Současné konfigurační centrum a samotné L5 nezohledňují specifikované směrovací politiky a nejsou škálovatelné, takže je třeba je vyvíjet mimo ně.
Metadata API jsou poměrně rozptýlená a v současnosti jsou metadata API a IDL, úrovně API a frekvenční limity rozmístěny mezi různými zdroji dat, a nyní je nutné přidat zdroj dat o směrování v odstínech šedi.
Obecně existují tři způsoby, jak publikovat šedé odstíny nginx+lua, nginx se distribuuje podle cookies a nginx podle váhy:
nginx+lua rozlišuje podle IP adresy návštěvníka, protože společnost exportuje IP adresu a webová stránka bude přístupná buď ve staré, nebo nové verzi, která pro tuto metodu není vhodná
nginx přiřazuje váhy na základě vah, což je snadné na implementaci a lze to vyzkoušet
NGINX se dělí podle cookies a GrayScale publikuje podle uživatelů
|
Zveřejněno 09.03.2017 15:48:27
|
|
|
|
