Billedet ovenfor viser Tencents gråtoneudgivelse, almindelige brugere kan få adgang til den, Alibaba Cloud-serveren kan ikke tilgås, ping er normal, og opløsnings-IP'en er også normal
Det er bare utilgængeligt, det kan ses, at Tencent også kan lide at lege med gråtoneudgivelser...
1. Hvorfor gråtoneudgivelse
- Internettjenester ændrer sig ofte, og udgivelsescyklusserne er korte. Hastighed og kvalitet er altid svære at kombinere.
- Gråtoneudgivelse kan reducere risikoen ved udgivelse og mindske omfanget af påvirkningen.
- Reducer afhængigheden af testning og reducer omkostningerne ved dataopbygning til offline selvtestning.
- Det er praktisk at overvåge logs centralt og offentliggøre dem i sin helhed. På grund af load balancing-rollen på hvert lag er det vanskeligt at spore et komplet opkaldslink.
- Du kan bruge gråtonede testkonti og derefter gråtonede rigtige brugerkonti efter testkontoen er bestået for yderligere at reducere risikoen og påvirkningen ved publicering.
- Nem tilbagerulning.
Problemer, der ikke kan løses med gråtoneudgivelser
Det skal understreges, at den ovenfor nævnte "tolerable impact" skal kunne gendannes, for eksempel kan API'et ikke kaldes i en periode, men efter reparation kan det kaldes med succes. Det permanente tab eller ødelæggelse af brugerdata (såsom produktinformation, ordreinformation osv.) er uacceptabelt. Derfor er det arkitekterne bag internetvirksomheders ansvar at reparere de tabte brugerdata til en nylig tilstand (for eksempel for en time siden til for en uge siden) gennem manuel indgriben i tilfælde af tab af brugerdata på grund af produktionssystemforstyrrelser (såsom regelmæssig backup af brugerdata, skrivning af operationslogs osv.).
TIPS Test din kontos gråtonepolitik først for at mindske risikoen for at beskadige eller miste rigtige brugeres data.
2. Hvilken effekt forventes?
Uanset ændringen ønsker vi, at specifikke anmodninger bliver videresendt til vores version af ændringen (gråtoneversionen) til observation og validering.
3. Gråtonestrategi
Faktisk er det det, som forespørgsler bør dirigeres til vores gråtoneversion (gråtonemaskine). Dette er ofte stærkt relateret til forretning. For eksempel er der for API'er generelt følgende krav:
Specifikke brugere (f.eks. testkonti)
Specifikke apps (f.eks. testapps eller partnerapps)
Specifikke moduler og grænseflader (kun nogle grænseflader kræver gråtoner, hvilket generelt er en ændring af API-containere, og nogle API'er, der ikke er særlig vigtige, bruges til gråtonetestning.) ）
Specifik maskine (nogle anmodnings-IP'er videresendes til gråtonemaskinen)
4. Diskussion af gråtoneskemaer
Løsning 1: Kodeniveauet bedømmes ud fra det aftalte flag, og det gamle og nye byttes dynamisk om – Amazons tilgang
Implementering:
Begrav kontakten i koden, lav en if-andet-vurdering, og sæt kontakten til at være tændt for maskiner, der kræver gråtoner, ellers er den slukket. Der findes to versioner for hver udgivelse.
Fortjeneste
Hurtig tilbagerulning, ingen grund til at genudgive og genstarte systemet.
mangel
Vær tilbøjelig til at følge reglerne.
Forgreningslogik bringer kompleksitet.
Denne metode blev brugt af forfatteren, da jeg var i Alibaba, hvor jeg skiftede databasen over varer fra Oracle til MySQL og brugte en tilstandsvariabel til kontrol. Dermed opnås effekten af en glidende migration.
Mulighed 2: Pre-release maskine - Alibabas praksis
Faktisk er dette ikke gråtoner i sande forstand. Fordi denne pre-release maskine er en intern IP og ikke har nogen ekstern service. Domænebinding er påkrævet for verifikation. Men dataene er helt online. Så det er i bund og grund en simpel tilgang for nogle specifikke brugere af gråtoner (brugere med adgang til gråtonsmaskinen, interne testbrugere). Faktisk findes der en lignende tilgang på API-siden, som er vores Gamma-miljø, og vi tilbyder også domænenavnet på Gamma-maskinen for at lette eksterne samarbejdsvillige brugere i at samarbejde om testning.
Fortjeneste
Simpelt
mangel
Waste a machine (dette kan sættes ind i produktionsmiljøet efter pre-release er afsluttet og fjernes fra nginx under pre-release, men O&M-support er påkrævet.) ）
Ikke fleksibel nok
IDL-tjenester kan kun bruges til adgangslagsmaskiner, og IDL-tjenester skal betragtes separat.
Mulighed 3: SET-udrulning
1. Udsendelse i isolation efter tjenestegrene
For eksempel kan granulariteten af implementering i den nuværende praksis med API-containere nås til API-niveau, og front-end forwards ifølge nginx. Som hvad:
Mikroshopping-API-container: api.weigou.qq.com
Pat API Container:api.paipai.com
Yixun API Container: api.yixun.com
Online shopping-API Container:api.buy.qq.com
Ovenstående er en isoleret implementering på det store virksomhedsniveau. Det kan også yderligere forfines til modulniveau, såsom API'en for virtuel service e-handel, som er et underforretningsmodul, der hænger under Paipai, men fordi de er forbundet til WeChat, er antallet af besøg steget betydeligt for at undgå at påvirke Paipais andre virksomheder, og for at undgå at blive påvirket af andre virksomheder, er API'et her at deployere to maskiner separat til dem, nginx kan konfigureres til at dræne den virtuelle API-adgang:
Virtuel API-container: http://api.paipai.com/v2/virbiz
På denne måde kan vi, når vi udgiver en version, først vælge Yixun med det mindste forretningsvolumen at udgive, og derefter observere, at der ikke er noget problem, før vi bruger alle andre platforme.
2. Udrul ved brugerisolation
Dette er ikke særlig velegnet til åbne platforme, men det er meget velegnet til applikationsscenarier som SNS. For eksempel er QQ-systemet opdelt i flere sæt efter brugernummersegmenter, og hvert sæt indeholder 100 millioner på hinanden følgende tal. Hvis vi antager, at det seneste QQ-tal er tæt på 1 milliard, er der i alt 10 sæt (sæt 1 til sæt 10). På denne måde kan du vælge et af SETS at publicere hver gang, og højniveau QQ er ofte ikke en særlig vigtig bruger, så SET10 vil blive udgivet først.
Fortjeneste
Isoleret implementering med minimal påvirkning på tværs af forretningslinjer. Understøttelse af gråtoneudgivelse automatisk.
mangel
Granulariteten af gråtoner afhænger af granulariteten i den isolerede udrulning, som generelt er stor.
Spild af maskiner sammenlignet med centraliseret implementering.
Versionerne af hver forretningslinje kan være inkonsistente, hvilket ikke fremmer en samlet ledelse.
Der er visse implementerings- og implementeringsomkostninger
Skema 4: Dynamisk routing
Metode: Brug en gråtonepolitik, der fleksibelt kan konfigureres til at påvirke belastningsbalancens adfærd og tillade den at returnere IP og port af gråtonetjenesten i henhold til gråtonepolitikken.
Velegnet til servicegråtoner med back-office IDL.
Fortjeneste
Fleksibel, kontrollerbar.
mangel
Det nuværende konfigurationscenter og L5 selv tager ikke hensyn til specifikke routingpolitikker og er ikke skalerbare, så de skal udvikles uden for dem.
Metadatakilderne for API'er er relativt spredte, og i øjeblikket er API- og IDL-metadata, API-niveauer og frekvensgrænser fordelt på forskellige datakilder, og nu er det nødvendigt at tilføje en gråtone-routing-datakilde.
Der er generelt tre måder at offentliggøre gråtonede nginx+lua på, nginx fordeles efter cookies, og nginx tildeles efter vægt:
nginx+lua skelner ud fra besøgendes IP-adresse, fordi virksomheden eksporterer en IP-adresse, og hjemmesiden vil blive tilgået enten den gamle version eller den nye version, som ikke egner sig til denne metode
nginx tildeler vægte baseret på vægte, hvilket er nemt at implementere og kan prøves
nginx opdeles baseret på cookies, og grayscale publicerer baseret på brugere
|
Opslået på 09/03/2017 15.48.27
|
|
|
|
