Yllä oleva kuva on Tencentin harmaasävyjulkaisu, tavalliset käyttäjät pääsevät siihen käsiksi, Alibaba Cloud -palvelinta ei ole käytettävissä, ping on normaali ja myös resoluutio IP on normaali
Se on vain vaikeasti saavutettavissa, ja näkyy, että Tencent tykkää leikkiä harmaasävyisellä julkaisulla...
1. Miksi harmaasävyjulkaisu
- Internet-palvelut vaihtuvat usein ja julkaisusyklit ovat lyhyitä. Nopeutta ja laatua on aina vaikea yhdistää.
- Harmaasävyjulkaisu voi vähentää julkaisemisen riskiä ja vähentää vaikutusten laajuutta.
- Vähennä riippuvuutta testauksesta ja alenna datan rakentamisen kustannuksia offline-itsetestauksessa.
- On kätevää seurata lokkeja keskitetysti ja julkaista ne kokonaisuudessaan. Koska kuormituksen tasapainotus jokaisella kerroksella on tärkeää, on vaikea seurata täydellistä kutsuyhteyttä.
- Voit käyttää Grayscale-testitilejä ja sitten harmaasävyisiä oikeita käyttäjätilejä testitilin päätyttyä, jotta julkaisemisen riski ja vaikutus vähenevät entisestään.
- Helppo peruutus.
Ongelmia, joita harmaasävyjulkaisuilla ei voi ratkaista
On korostettava, että edellä mainittu "siedettävä vaikutus" on oltava palautettavissa, esimerkiksi API:a ei voi kutsua tietyn ajan, mutta korjauksen jälkeen se voidaan kutsua onnistuneesti. Käyttäjätietojen (kuten tuotetiedot, tilaustiedot jne.) pysyvä katoaminen tai tuhoaminen on sietämätöntä. Siksi Internet-yritysten arkkitehtien vastuulla on korjata kadonneet käyttäjätiedot viimeisimpään tilaan (esimerkiksi tunti tai viikko sitten) manuaalisella puuttumisella, jos käyttäjätietoja menetetään tuotantojärjestelmän häiriöiden vuoksi (kuten käyttäjätietojen säännöllinen varmuuskopiointi, toimintalokien kirjoittaminen jne.).
VINKKEJÄ Testaa ensin tilisi harmaasävypolitiikka vähentääksesi oikeiden käyttäjien tietojen vahingoittamisen tai menettämisen riskiä.
2. Millaista vaikutusta odotetaan?
Muutoksesta riippumatta haluamme, että tietyt pyynnöt ohjataan meidän versiollemme muutoksesta (harmaasävyversio) havainnointia ja validointia varten.
3. Harmaasävystrategia
Itse asiassa juuri se on se, mitä pyynnöt tulisi ohjata harmaasävyversiollemme (harmaasävykoneelle). Tämä liittyy usein vahvasti liiketoimintaan. Esimerkiksi API:lle on yleensä seuraavat vaatimukset:
Tietyt käyttäjät (esim. testitilit)
Tietyt sovellukset (esim. testisovellukset tai kumppanisovellukset)
Erityiset moduulit ja rajapinnat (vain jotkut rajapinnat tarvitsevat harmaasävyn, joka on yleensä API-konttien muokkaus, ja joitakin API-rajapintoja, jotka eivät ole kovin tärkeitä, käytetään harmaasävytestaukseen.) ）
Tietty kone (jotkut pyyntö-IP:t välitetään harmaasävykoneelle)
4. Harmaasävyjärjestelmien käsittely
Ratkaisu 1: Kooditaso arvioidaan sovitun lipun mukaan, ja vanha sekä uusi vaihtuvat dynaamisesti – Amazonin lähestymistapa
Toteutus:
Upota kytkin koodiin, tee if-else -arvio ja aseta kytkin päälle koneille, jotka vaativat harmaasävyä, muuten se on pois päältä. Jokaiselle julkaisulle on kaksi versiota.
ansio
Nopea palautus, ei tarvitse julkaista ja käynnistää järjestelmää uudelleen.
puute
Ole taipuvainen koodiin.
Haarautuva logiikka tuo mukanaan monimutkaisuutta.
Tätä menetelmää käytti kirjoittaja, kun olin Alibabassa, vaihtaen tavaratietokannan Oraclesta MySQL:ään ja käyttäen tilamuuttujaa ohjaukseen. Näin saavutetaan sujuva muuttoliike.
Vaihtoehto 2: Ennakkojulkaisukone – Alibaban käytäntö
Itse asiassa tämä ei ole harmaasävy varsinaisessa merkityksessä. Koska tämä pre-release -kone on sisäinen IP-osoite eikä sillä ole ulkoista palvelua. Verkkotunnuksen sitominen vaaditaan varmennukseen. Mutta data on täysin verkossa. Eli se on käytännössä yksinkertainen lähestymistapa joillekin tietyille Grayscale-käyttäjille (käyttäjille, joilla on pääsy harmaasävykoneeseen, sisäisille testikäyttäjille). Itse asiassa API-puolella on samankaltainen lähestymistapa, joka on Gamma-ympäristömme, ja tarjoamme myös Gamma-koneen verkkotunnuksen, jotta ulkoiset yhteistyökäyttäjät voivat tehdä yhteistyötä testauksessa.
ansio
Yksinkertaista
puute
Hukkaa kone (tämä voidaan laittaa tuotantoympäristöön esijulkaisun jälkeen ja poistaa nginxistä esijulkaisun aikana, mutta O&M-tuki on pakollinen.) ）
Ei tarpeeksi joustava
IDL-palveluita voidaan käyttää vain pääsykerroksen koneille, ja IDL-palvelut on tarkasteltava erikseen.
Vaihtoehto 3: SET-käyttöönotto
1. Lähetä eristyksissä palveluiden mukaan
Esimerkiksi nykyisessä API-konttien käytännössä käyttöönoton tarkkuus voidaan saavuttaa API-tasolle asti, ja front-end forward-suuntaus nginxin mukaan. Kuten mitä:
Micro Shopping API Container: api.weigou.qq.com
Pat API Container:api.paipai.com
Yixun API Container: api.yixun.com
Verkkokaupan API Container:api.buy.qq.com
Edellä mainittu on erillinen käyttöönotto suuryritysten tasolla. Sitä voidaan myös tarkentaa moduulitasolle, kuten virtuaalipalvelun verkkokaupan API, joka on Paipain alaisuudessa toimiva alaliiketoimintamoduuli, mutta koska ne ovat yhteydessä WeChatiin, käyntien määrä on kasvanut merkittävästi, jotta Paipain muihin yrityksiin ei vaikuttaisi, ja jotta muut yritykset eivät vaikuttaisi, API tässä on ottaa käyttöön kaksi konetta erikseen niille, nginx voidaan konfiguroida tyhjentämään virtuaalisen API-pääsyn:
Virtuaalinen API-kontti: http://api.paipai.com/v2/virbiz
Näin ollen, kun julkaisemme version, voimme ensin valita Yixunin, jolla on pienimmän liiketoimintavolyymin, julkaistavaksi, ja sitten havaita, ettei ongelmaa ole ennen kuin käytämme kaikkia muita alustoja.
2. Käyttöönotto käyttäjän eristämällä
Tämä ei sovi kovin hyvin avoimille alustoille, mutta sopii hyvin sovellustilanteisiin, kuten SNS:ään. Esimerkiksi QQ-järjestelmä on jaettu useisiin joukkoihin käyttäjänumerosegmenttien mukaan, ja jokainen joukko sisältää 100 miljoonaa peräkkäistä lukua. Oletetaan, että viimeisin QQ-luku on lähellä 1 miljardia, joukkoja on yhteensä 10 (joukko 1–joukko 10). Näin voit valita yhden SET-tiedostoista julkaistavaksi joka kerta, ja korkean tason QQ ei usein ole kovin tärkeä käyttäjä, joten SET10 julkaistaan ensin.
ansio
Eristetty käyttöönotto, jolla on vähäinen vaikutus eri liiketoiminta-alueille. Tukee automaattisesti harmaasävyjulkaisua.
puute
Harmaasävyjen rakeisuus riippuu erillisen levityksen rakeisuudesta, joka on yleensä suuri.
Koneiden hukkaa verrattuna keskitettyyn käyttöönottoon.
Kunkin liiketoimintalinjan versiot voivat olla ristiriitaisia, mikä ei edistä yhtenäistä hallintaa.
Toteutus- ja käyttöönottokustannuksia on
Kaavio 4: Dynaaminen reititys
Menetelmä: Käytä harmaasävypolitiikkaa, joka voidaan joustavasti konfiguroida vaikuttamaan kuormatasapainon käyttäytymiseen ja sallimaan sen palauttaa harmaasävypalvelun IP-osoitteen ja portin harmaasävypolitiikan mukaisesti.
Sopii palveluun harmaasävyissä, jossa on back-office IDL.
ansio
Joustavia, hallittavissa.
puute
Nykyinen konfiguraatiokeskus ja L5 itse eivät ota huomioon määriteltyjä reitityskäytäntöjä, eivätkä ole skaalautuvia, joten ne täytyy kehittää niiden ulkopuolella.
API-rajapintojen metatietolähteet ovat melko hajanaisia, ja tällä hetkellä API- ja IDL-metatiedot, API-tasot ja taajuusrajat ovat hajautuneet eri tietolähteiden kesken, joten nyt on tarpeen lisätä harmaasävyinen reititystietolähde.
Yleisesti on kolme tapaa julkaista harmaasävy nginx+lua: nginx jaetaan evästeiden mukaan ja nginx määritellään painon mukaan:
nginx+lua erottaa kävijän IP-osoitteen perusteella, koska yritys vie IP-osoitteen, ja verkkosivustolle pääsee joko vanhan tai uuden version kautta, mikä ei sovellu tähän menetelmään
nginx määrittää painot painojen perusteella, mikä on helppoa toteuttaa ja sitä voi kokeilla
nginx jakaa evästeiden perusteella, ja harmaasävy julkaisee käyttäjien perusteella
|
Julkaistu 9.3.2017 15.48.27
|
|
|
|
