A fenti kép a Tencent szürkeárnyalatos kiadása, a hétköznapi felhasználók hozzáférhetnek, az Alibaba Cloud szerver nem érhető el, a ping normális, és a felbontás IP is normális
Egyszerűen elérhetetlen, látható, hogy a Tencent is szeret játszani szürkeárnyalatos kiadással...
1. Miért a Grayscale Release
- Az internetes szolgáltatások gyakran változnak, és a kiadási ciklusok rövidek. A sebesség és a minőség mindig nehezen kombinálható.
- A szürkeárnyalatos kiadás csökkentheti a kiadás kockázatát és a hatás mértékét.
- Csökkentse a teszteléstől való függőséget, és csökkentse az adatépítés költségét az offline önteszteléshez.
- Kényelmes központilag figyelni a naplókat és teljes egészében közzétenni A terheléselosztás minden rétegben fontos szerepe miatt nehéz egy teljes hívási kapcsolatot nyomon követni.
- Használhatsz Grayscale tesztfiókokat, majd a tesztfiók áthaladása után szürkeárnyalatos valódi felhasználói fiókokat, hogy tovább csökkentsd a kiadás kockázatát és hatását.
- Könnyű visszahúzás.
Olyan problémák, amelyeket szürkeárnyalatos kiadásokkal nem lehet megoldani
Hangsúlyozni kell, hogy a fent említett "elviselhető hatás" helyreállíthatónak kell lennie, például az API-t nem lehet egy ideig hívni, de javítás után sikeresen meg lehet hívni. A felhasználói adatok (például termékinformációk, rendelési információk stb.) tartós elvesztése vagy megsemmisítése elviselhetetlen. Ezért az internetes vállalatok építészeinek felelőssége, hogy a felhasználói adatokat egy friss állapotba (például egy órával ezelőtt, akár egy héttel ezelőtt) manuális beavatkozással javítsák el a felhasználói adatok elvesztése esetén a gyártási rendszerzavarok miatt (például rendszeres felhasználói adatok mentése, műveleti naplók írása stb.).
TIPPEK Először teszteld a fiókod szürkeárnyalatos szabályzatát, hogy csökkentsd a valódi felhasználók adatainak károsodásának vagy elvesztésének kockázatát.
2. Milyen hatás várható?
A változástól függetlenül szeretnénk, ha konkrét kéréseket a mi verziónkhoz (szürkeárnyalatos verzióhoz) irányítanának megfigyelés és validáció céljából.
3. Szürkeárnyalatos stratégia
Valójában ez az, amit a kéréseket a szürkeárnyalatos verziónkhoz (szürkeárnyalatos gépünkhöz) kell irányítani. Ez gyakran szorosan kapcsolódik az üzleti élethez. Például az API-k esetében általában a következő követelmények vonatkoznak:
Konkrét felhasználók (pl. tesztfiókok)
Konkrét alkalmazások (pl. tesztalkalmazások vagy partneralkalmazások)
Specifikus modulok és interfészek (csak néhány interfész igényel szürkeárnyalatot, ami általában az API konténerek módosítása, és néhány kevésbé fontos API-t szürkeárnyalatos tesztelésre használnak.) ）
Specifikus gép (néhány kérés IP-jét továbbítják a szürkeárnyalatos gépre)
4. Szürkeárnyalatos sémák megbeszélése
1. megoldás: A kódszintet a megegyezett zászló alapján ítélik meg, és a régi és új dinamikusan váltanak – az Amazon megközelítése
Megvalósítás:
Temd el a kapcsolót a kódban, hozz if-else ítéletet, és állítsd be a kapcsolót bekapcsolva azoknál a gépeken, amelyeknél szürkeárnyalatot igényelnek, különben kikapcsol. Minden kiadáshoz két verzió létezik.
érdem
Gyors visszaállítás, nincs szükség újrapublikálásra és újraindításra a rendszert.
Hiány
Hajlamos a kódolásra.
Az elágazó logika összetettséget hoz.
Ezt a módszert a szerző használta, amikor Alibaba-ban voltam, amikor az áruk adatbázisát Oracle-ról MySql-re váltottam, és állapotváltozót használtunk vezérléshez. Így a sima migráció hatását éri el.
2. lehetőség: Előzetes kiadási gép – az Alibaba gyakorlata
Valójában ez nem szürkeárnyalat az igazi értelemben. Mert ez a pre-release gép belső IP, és nincs külső szolgáltatása. Domain kötés szükséges az ellenőrzéshez. De az adatok teljesen online vannak. Tehát ez lényegében egy egyszerű megközelítés néhány specifikus Grayscale felhasználó számára (azoknak, akiknek hozzáférésük van a szürkeárnyalatos géphez, belső tesztfelhasználók). Valójában hasonló megközelítés van az API oldalon is, ami a Gamma környezetünk, és megadjuk a Gamma gép domain nevét is, hogy a külső együttműködő felhasználók együttműködhessenek a tesztelésben.
érdem
Egyszerű
Hiány
Gép pazarlása (ezt a gyártási környezetbe lehet tenni az előzetes kiadás befejezése után, és az nginx-ről az előkiadás alatt eltávolítható, de O&M támogatás szükséges.) ）
Nem elég rugalmas
Az IDL szolgáltatásokat csak hozzáférési rétegű gépek használhatják, az IDL szolgáltatásokat pedig külön kell figyelembe venni.
3. lehetőség: SET telepítés
1. Szolgálatok szerint elszigetelt, bevetendő
Például a jelenlegi API-konténerek gyakorlatában a telepítés részletessége elérhető az API szintig, és a front-end előrehaladások a nginx szerint. Például:
Micro Shopping API Container: api.weigou.qq.com
Pat API Container:api.paipai.com
Yixun API Container: api.yixun.com
Online vásárlási API Container:api.buy.qq.com
A fentiek egy elszigetelt telepítést jelentenek nagyvállalati szinten. Ez tovább finomítható modul szintre is, például a virtuális szolgáltatás e-commerce API-ja, amely egy al-üzleti modul, amely a Paipai alatt függ, de mivel ezek a WeChathez kapcsolódnak, a látogatások száma jelentősen megnőtt, hogy elkerüljék a Paipai többi vállalkozását érinteni, és hogy elkerüljék a többi üzletág hatását, az API itt két gépet külön telepít számukra, a nginx konfigurálható úgy, hogy kihasználja a virtuális API hozzáférést:
Virtuális API konténer: http://api.paipai.com/v2/virbiz
Így, amikor kiadunk egy verziót, először kiválaszthatjuk a Yixun szolgáltatást, amely a legkisebb üzleti volumenben publikál, majd megfigyelhetjük, hogy nincs probléma, mielőtt minden más platformot használnánk.
2. Felhasználói izolációval történő telepítés
Ez nem túl alkalmas nyílt platformokra, de olyan alkalmazási helyzetekhez, mint az SNS. Például a QQ rendszer felhasználói számszegmensek szerint több halmazra van osztva, és minden halmaz 100 millió egymást követő számot tartalmaz. Ha feltételezzük, hogy a legutóbbi negyedszám közel 1 milliárd, összesen 10 halmaz létezik (1-től 10-ig terjedő halmaz). Így minden alkalommal kiválaszthatsz egy SET-et, amit közzéteszsz, és a magas szintű QQ gyakran nem túl fontos felhasználó, így először a SET10 jelenik meg.
érdem
Izolált telepítés, minimális hatással az üzleti területekre. Automatikusan támogatja a szürkeárnyalatos kiadást.
Hiány
A szürkeárnyalat granularitása az izolált kiosztás granularitásától függ, amely általában nagy.
Gépek pazarlása a központosított telepítéshez képest.
Az egyes üzleti vonalak verziói eltérhetnek egymástól, ami nem kedvező az egységes menedzsment szempontjából.
Vannak bizonyos megvalósítási és telepítési költségek
4. séma: Dinamikus útvonalvezetés
Módszer: Használjunk egy szürkeárnyalatos szabályzatot, amely rugalmasan konfigurálható úgy, hogy befolyásolja a terheléselosztás viselkedését, és lehetővé teszi a szürkeárnyalatos szolgáltatás IP-címének és portjának visszaküldését a szürkeárnyalatos politika szerint.
Alkalmas szürkeárnyalatos szolgáltatásra back-office IDL-lel.
érdem
Rugalmas, irányítható.
Hiány
A jelenlegi konfigurációs központ és maga az L5 nem veszi figyelembe a meghatározott útvonalválasztási szabályzatokat, és nem skálázhatók, ezért ezeket a határokon kívül kell fejleszteni.
Az API-k metaadat-forrásai viszonylag szétszórtak, jelenleg az API és IDL metaadatok, API szintek és frekvenciahatárok különböző adatforrások között oszlanak meg, ezért most szükség van egy szürkeárnyalatos útvonal-forrás hozzáadására.
Általában háromféleképpen lehet szürkeárnyalatos nginx+lua közzététele: a nginx sütikek szerint kerül terjesztésre, a nginx pedig súly szerint van hozzárendelve:
A nginx+lua látogató IP-címe alapján megkülönbözteti, mivel a cég exportál egy IP-címet, és a weboldal vagy a régi, vagy az új verzió érhető el, amely nem alkalmas erre a módszerre
A nginx súlyok alapján oszt ki súlyokat, ami egyszerű megvalósítható és kipróbálható
A nginx sütik alapján oszt szét, a szürkeárnyalatos pedig a felhasználók alapján publikál
|
Közzétéve 2017. 03. 09. 15:48:27
|
|
|
|
