Bildet over viser Tencents gråtoneutgivelse, vanlige brukere kan få tilgang til den, Alibaba Cloud-serveren kan ikke nås, ping er normal, og oppløsnings-IP er også normal
Det er bare utilgjengelig, det kan sees at Tencent også liker å leke med gråtoneutgivelser...
1. Hvorfor gråtoneutgivelse
- Internett-tjenester endres ofte, og utgivelsessyklusene er korte. Fart og kvalitet er alltid vanskelig å kombinere.
- Gråtonepublisering kan redusere risikoen ved publisering og redusere omfanget av påvirkningen.
- Reduser avhengigheten av testing og reduser kostnadene ved datakonstruksjon for offline selvtesting.
- Det er praktisk å sentralt overvåke logger og publisere dem i sin helhet. På grunn av lastbalanseringens rolle på hvert lag er det vanskelig å spore en komplett samtalelink.
- Du kan bruke gråtonetestkontoer, og deretter gråtonede ekte brukerkontoer etter at testkontoen har bestått for å ytterligere redusere risikoen og påvirkningen av publisering.
- Enkel tilbakerulling.
Problemer som ikke kan løses med gråtoneutgivelser
Det bør understrekes at den «tolerable impact» nevnt ovenfor må kunne gjenopprettes, for eksempel kan API-et ikke kalles i en periode, men etter reparasjon kan det vellykkes kalle det. Permanent tap eller ødeleggelse av brukerdata (som produktinformasjon, ordreinformasjon osv.) er uakseptabelt. Derfor er det arkitektene bak internettbedrifters ansvar å reparere tapte brukerdata til en nylig tilstand (for eksempel for en time siden til en uke siden) gjennom manuell intervensjon ved tap av brukerdata på grunn av produksjonssystemforstyrrelser (som regelmessig sikkerhetskopiering av brukerdata, skriving av operasjonslogger osv.).
TIPS: Test kontoen din sin gråtonepolicy først for å redusere risikoen for å skade eller miste data fra ekte brukere.
2. Hvilken effekt forventes?
Uansett endring ønsker vi at spesifikke forespørsler skal rutes til vår versjon av endringen (gråtoneversjonen) for observasjon og validering.
3. Gråtonestrategi
Faktisk er det hva forespørsler bør rutes til vår gråtoneversjon (gråtonemaskinen). Dette er ofte sterkt knyttet til næringslivet. For eksempel er det vanligvis følgende krav for API-er:
Spesifikke brukere (f.eks. testkontoer)
Spesifikke apper (f.eks. testapper eller partnerapper)
Spesifikke moduler og grensesnitt (bare noen grensesnitt trenger gråtoner, som vanligvis er en modifikasjon av API-containere, og noen API-er som ikke er så viktige brukes til gråtonetesting). ）
Spesifikk maskin (noen forespørsels-IP-adresser videresendes til gråtonemaskinen)
4. Diskusjon av gråtoneskjemaer
Løsning 1: Kodenivået vurderes ut fra det avtalte flagget, og gammelt og nytt byttes dynamisk – Amazons tilnærming
Implementering:
Begrav bryteren i koden, gjør en om-ellers-vurdering, og sett bryteren på for maskiner som krever gråtoner, ellers er den av. Det finnes to versjoner for hver utgivelse.
fortjeneste
Rask tilbakerulling, ingen behov for å publisere og starte systemet på nytt.
brist
Vær tilbøyelig til å følge regler.
Forgrenet logikk bringer kompleksitet.
Denne metoden ble brukt av forfatteren da jeg var i Alibaba, hvor jeg byttet databasen med varer fra Oracle til MySql, og brukte en tilstandsvariabel for kontroll. Dermed oppnås effekten av jevn migrasjon.
Alternativ 2: Forhåndslanseringsmaskin – Alibabas praksis
Faktisk er dette ikke gråtoner i egentlig forstand. Fordi denne pre-release-maskinen er en intern IP og har ingen ekstern tjeneste. Domenebinding kreves for verifisering. Men dataene er helt på nett. Så det er i bunn og grunn en enkel tilnærming for noen spesifikke brukere av Grayscale (brukere som har tilgang til grayscale-maskinen, interne testbrukere). Faktisk finnes det en lignende tilnærming på API-siden, som er vårt Gamma-miljø, og vi oppgir også domenenavnet til Gamma-maskinen for å gjøre det mulig for eksterne samarbeidende brukere å samarbeide med testing.
fortjeneste
Enkelt
brist
Waste a machine (dette kan settes inn i produksjonsmiljøet etter at pre-release er fullført, og fjernes fra nginx under pre-release, men O&M-støtte er nødvendig.) ）
Ikke fleksibel nok
IDL-tjenester kan kun brukes for access layer-maskiner, og IDL-tjenester må vurderes separat.
Alternativ 3: SET-utrulling
1. Deployeres isolert i henhold til tjenestegrener
For eksempel, i dagens praksis med API-containere, kan granulariteten i distribusjonen nås til API-nivå, og front-end forwards i henhold til nginx. Som hva:
Micro Shopping API-container: api.weigou.qq.com
Pat API Container:api.paipai.com
Yixun API Container: api.yixun.com
Netthandels-API Container:api.buy.qq.com
Ovenstående er en isolert implementering på storbedriftsnivå. Det kan også videreutvikles til modulnivå, som API-et for virtuell e-handel, som er en underforretningsmodul som henger under Paipai, men fordi de er koblet til WeChat, har antall besøk økt betydelig, for å unngå å påvirke Paipais andre virksomheter, og for å unngå å bli påvirket av andre virksomheter, er API-et her å distribuere to maskiner separat for dem, nginx kan konfigureres til å tømme tilgang til det virtuelle API-et:
Virtuell API-beholder: http://api.paipai.com/v2/virbiz
På denne måten, når vi slipper en versjon, kan vi først velge Yixun med det minste forretningsvolumet å publisere, og deretter observere at det ikke er noe problem før vi bruker alle andre plattformer.
2. Distribuer ved brukerisolasjon
Dette er ikke særlig egnet for åpne plattformer, men det er svært egnet for applikasjonsscenarier som SNS. For eksempel er QQ-systemet delt inn i flere sett etter brukernummersegmenter, og hvert sett inneholder 100 millioner sammenhengende tall. Forutsatt at det siste QQ-tallet er nær 1 milliard, finnes det totalt 10 sett (sett 1 til sett 10). På denne måten kan du velge ett av SETS å publisere hver gang, og høynivå QQ er ofte ikke en veldig viktig bruker, så SET10 vil bli lansert først.
fortjeneste
Isolert utrulling med minimal påvirkning på tvers av forretningsområder. Støtter automatisk gråskalapublisering.
brist
Granulariteten til gråtoner avhenger av granulariteten i den isolerte utrullingen, som vanligvis er stor.
Sløsing med maskiner sammenlignet med sentralisert utrulling.
Versjonene av hver forretningslinje kan være inkonsistente, noe som ikke er gunstig for enhetlig ledelse.
Det er visse implementerings- og utrullingskostnader
Skjema 4: Dynamisk ruting
Metode: Bruk en gråtonepolicy som kan konfigureres fleksibelt for å påvirke oppførselen til lastbalansen og la den returnere IP-adressen og porten til gråtonetjenesten i henhold til gråtonepolicyen.
Egnet for tjenestegråtoner med back-office IDL.
fortjeneste
Fleksibelt, kontrollerbart.
brist
Det nåværende konfigurasjonssenteret og L5 selv tar ikke hensyn til spesifiserte rutingspolicyer, og er ikke skalerbare, så de må utvikles utenfor dem.
Metadatakildene til API-er er relativt spredte, og for øyeblikket er API- og IDL-metadata, API-nivåer og frekvensgrenser fordelt på ulike datakilder, og nå er det nødvendig å legge til en gråskala-rutingsdatakilde.
Det finnes vanligvis tre måter å publisere gråskala nginx+lua på, nginx fordeles etter informasjonskapsler, og nginx tildeles etter vekt:
nginx+lua skiller ut fra besøkendes IP-adresse, fordi selskapet eksporterer en IP-adresse, og nettsiden vil bli brukt enten den gamle versjonen eller den nye versjonen, som ikke egner seg for denne metoden
nginx tildeler vekter basert på vekter, noe som er enkelt å implementere og kan prøves ut
nginx deles basert på informasjonskapsler, og grayscale publiserer basert på brukere
|
Publisert på 09.03.2017 15:48:27
|
|
|
|
