Bilden ovan visar Tencents gråskaliga version, vanliga användare kan komma åt den, Alibaba Cloud-servern kan inte nås, ping är normal och upplösnings-IP är också normal
Det är helt enkelt otillgängligt, det syns att Tencent också gillar att leka med gråskalesläpp...
1. Varför gråskala släpp
- Internettjänster ändras ofta och releasecyklerna är korta. Hastighet och kvalitet är alltid svåra att kombinera.
- Gråskalepublicering kan minska risken med publicering och minska omfattningen av påverkan.
- Minska beroendet av testning och minska kostnaden för datakonstruktion för offline-självtestning.
- Det är bekvämt att centralt övervaka loggar och publicera dem i sin helhet. På grund av lastbalanseringens roll på varje lager är det svårt att spåra en komplett samtalslänk.
- Du kan använda gråskaliga testkonton och sedan gråskaliga riktiga användarkonton efter att testkontot klarat för att ytterligare minska risken och påverkan av publicering.
- Enkel återställning.
Problem som inte kan lösas med gråskaliga utgåvor
Det bör betonas att den "tolerabla påverkan" som nämnts ovan måste vara återställbar, till exempel kan API:et inte anropas under en viss tid, men efter reparation kan det anropas framgångsrikt. Den permanenta förlusten eller förstörelsen av användardata (såsom produktinformation, orderinformation etc.) är outhärdlig. Därför är det arkitekterna bakom internetföretag som ansvarar för att reparera förlorad användardata till ett nyligen tillstånd (som för en timme sedan till en vecka sedan) genom manuell intervention vid förlust av användardata på grund av produktionssystemstörningar (såsom regelbunden säkerhetskopiering av användardata, skrivande av operationsloggar, etc.).
TIPS Tester ditt kontos gråskalepolicy först för att minska risken för att skada eller förlora riktiga användares data.
2. Vilken effekt förväntas?
Oavsett ändringen vill vi att specifika förfrågningar ska skickas till vår version av ändringen (gråskaleversionen) för observation och validering.
3. Gråskalestrategi
Faktum är att det är vad förfrågningar ska routas till vår gråskaleversion (gråskalemaskin). Detta är ofta starkt relaterat till affärer. Till exempel finns det generellt följande krav för API:er:
Specifika användare (t.ex. testkonton)
Specifika appar (t.ex. testappar eller partnerappar)
Specifika moduler och gränssnitt (endast vissa gränssnitt behöver gråskala, vilket generellt är en modifiering av API-containrar, och vissa API:er som inte är särskilt viktiga används för gråskaletestning). ）
Specifik maskin (vissa begäran-IP-adresser vidarebefordras till gråskalemaskinen)
4. Diskussion om gråskalescheman
Lösning 1: Kodnivån bedöms av den överenskomna flaggan, och den gamla och nya byts dynamiskt – Amazons tillvägagångssätt
Implementering:
Gräv ner strömbrytaren i koden, gör en om-eller-bedömning och ställ in strömbrytaren på för maskiner som kräver gråskala, annars är den avstängd. Det finns två versioner för varje utgåva.
förtjänst
Snabb återställning, ingen anledning att publicera om eller starta om systemet.
brist
Var benägen att följa reglerna.
Förgrenad logik medför komplexitet.
Denna metod användes av författaren när jag var på Alibaba, där jag bytte databasen med varor från Oracle till MySql och använde en tillståndsvariabel för styrning. Därigenom uppnås effekten av smidig migration.
Alternativ 2: Förhandsmaskin – Alibabas praxis
Faktum är att detta inte är gråskala i egentlig mening. Eftersom denna prerelease-maskin är en intern IP och saknar extern tjänst. Domänbindning krävs för verifiering. Men datan är helt online. Så det är i princip en enkel metod för vissa specifika användare av gråskala (användare som har tillgång till gråskalemaskinen, interna testanvändare). Faktum är att det finns en liknande metod på API-sidan, vilket är vår Gamma-miljö, och vi tillhandahåller också domännamnet på Gamma-maskinen för att underlätta för externa samarbetsvilliga användare att samarbeta med testning.
förtjänst
Enkelt
brist
Waste a Machine (detta kan sättas in i produktionsmiljön efter att förhandsutsläppet är klart och tas bort från nginx under förhandsutsläppet, men O&M-stöd krävs.) ）
Inte tillräckligt flexibel
IDL-tjänster kan endast användas för åtkomstlagersmaskiner, och IDL-tjänster måste betraktas separat.
Alternativ 3: SET-utplacering
1. Utplacera i isolering enligt tjänstgrenar
Till exempel, i nuvarande praxis med API-containrar, kan distributionens granularitet nås till API-nivå, och front-end forwards enligt nginx. Som vad:
Mikroshopping-API-behållare: api.weigou.qq.com
Pat API Container:api.paipai.com
Yixun API Container: api.yixun.com
Online shopping API Container:api.buy.qq.com
Ovanstående är en isolerad implementering på storföretagsnivå. Det kan också förfinas vidare till modulnivå, såsom API:et för virtuell tjänst e-handel, som är en underaffärsmodul som hänger under Paipai, men eftersom de är kopplade till WeChat har antalet besök ökat avsevärt, för att undvika att påverka Paipais andra verksamheter och för att undvika att påverkas av andra företag, är API:et här att distribuera två maskiner separat för dem, nginx kan konfigureras för att dränera den virtuella API-åtkomsten:
Virtuell API-behållare: http://api.paipai.com/v2/virbiz
På så sätt, när vi släpper en version, kan vi först välja Yixun med den minsta affärsvolymen att publicera, och sedan observera att det inte finns något problem innan vi använder alla andra plattformar.
2. Distribuera via användarisolering
Detta är inte särskilt lämpligt för öppna plattformar, men mycket lämpligt för applikationsscenarier som SNS. Till exempel är QQ-systemet uppdelat i flera uppsättningar enligt användarnummersegment, och varje uppsättning innehåller 100 miljoner på varandra följande nummer. Om vi antar att det senaste QQ-talet är nära 1 miljard, finns det totalt 10 mängder (Set 1 till Set 10). På så sätt kan du välja en av SETS att publicera varje gång, och högnivå-QQ är ofta inte en särskilt viktig användare, så SET10 släpps först.
förtjänst
Isolerad implementering med minimal påverkan över affärsområden. Stöder automatiskt gråskalig publicering.
brist
Gråskalans granularitet beror på granulariteten i den isolerade utplaceringen, som generellt är stor.
Slöseri med maskiner jämfört med centraliserad installation.
Versionerna av varje affärslinje kan vara inkonsekventa, vilket inte är gynnsamt för enhetlig ledning.
Det finns vissa implementerings- och distributionskostnader
Schema 4: Dynamisk routning
Metod: Använd en gråskalepolicy som flexibelt kan konfigureras för att påverka lastbalansens beteende och tillåta den att returnera IP och porten till gråskaletjänsten enligt gråskalepolicyn.
Lämplig för servicegråskala med backoffice-IDL.
förtjänst
Flexibel, kontrollerbar.
brist
Det nuvarande konfigurationscentret och L5 själv tar inte hänsyn till specificerade routningspolicys och är inte skalbara, så de måste utvecklas utanför dem.
API:ernas metadatakällor är relativt utspridda, och för närvarande är API- och IDL-metadata, API-nivåer och frekvensgränser fördelade över olika datakällor, och nu är det nödvändigt att lägga till en gråskalig routingdatakälla.
Det finns generellt tre sätt att publicera gråskala nginx+lua, nginx fördelas enligt cookies, och nginx tilldelas vikt:
nginx+lua skiljer på besökarens IP-adress, eftersom företaget exporterar en IP-adress, och webbplatsen kommer att nås antingen den gamla versionen eller den nya versionen, som inte är lämplig för denna metod
nginx tilldelar vikter baserat på vikter, vilket är enkelt att implementera och kan testas
nginx delas upp baserat på cookies, och gråskala publicerar baserat på användare
|
Publicerad på 2017-03-09 15:48:27
|
|
|
|
