Ülalolev pilt on Tencenti halltoonide versioon, tavalised kasutajad pääsevad sellele ligi, Alibaba pilveserverit ei saa kasutada, ping on normaalne ja resolutsioon IP samuti normaalne
See on lihtsalt kättesaamatu, on näha, et Tencentile meeldib mängida halltoonide väljalaskega...
1. Miks halltoonide väljaandmine
- Internetiteenused muutuvad sageli ja väljalasketsüklid on lühikesed. Kiirust ja kvaliteeti on alati raske kombineerida.
- Halltoonide avaldamine võib vähendada avaldamise riski ja vähendada mõju ulatust.
- Vähendada testimisest sõltuvust ja vähendada andmete koostamise kulusid offline-enesetestimiseks.
- Logide tsentraalne jälgimine ja täielik avaldamine on mugav. Koormuse tasakaalustamise rolli tõttu igal kihil on keeruline jälgida täielikku kõnelingi.
- Saad kasutada Grayscale'i testkontosid ja seejärel halltooniga päris kasutajakontosid pärast testikonto läbimist, et veelgi vähendada avaldamise riski ja mõju.
- Lihtne tagasipööramine.
Probleemid, mida halltoonide väljalaskega lahendada ei saa
Tuleb rõhutada, et ülalmainitud "talutav mõju" peab olema taastatav, näiteks API-d ei saa teatud aja jooksul kutsuda, kuid pärast parandamist saab selle edukalt kutsuda. Kasutajaandmete (näiteks tooteinfo, tellimusteave jne) püsiv kadumine või hävitamine on talumatu. Seetõttu on internetiettevõtete arhitektide vastutus taastada kadunud kasutajaandmed hiljutisesse seisu (näiteks tund kuni nädal tagasi) käsitsi sekkumise kaudu, kui kasutajaandmed kaovad tootmissüsteemi rikete tõttu (näiteks kasutajaandmete regulaarne varundamine, operatsioonilogide kirjutamine jne).
NÕUANDED: Testige esmalt oma konto halltoonide poliitikat, et vähendada riski kahjustada või kaotada päris kasutajate andmeid.
2. Millist mõju oodatakse?
Sõltumata muudatusest soovime, et konkreetsed päringud suunataks meie versiooni (halltoonide versioon) jälgimiseks ja valideerimiseks.
3. Halltoonide strateegia
Tegelikult on see see, millise päringu tuleks suunata meie halltoonide versioonile (halltoonide masin). See on sageli tugevalt seotud äriga. Näiteks API-de puhul on üldiselt järgmised nõuded:
Spetsiifilised kasutajad (nt testkontod)
Spetsiifilised rakendused (nt testrakendused või partnerrakendused)
Spetsiifilised moodulid ja liidesed (ainult mõned liidesed vajavad halltooni, mis on üldiselt API konteinerite modifikatsioon, ning mõned API-d, mis pole väga olulised, kasutatakse halltoonide testimiseks.) ）
Spetsiifiline masin (mõned päringu IP-d edastatakse halltoonimasinale)
4. Halltoonide skeemide arutelu
Lahendus 1: Kooditaset hinnatakse kokkulepitud lipu järgi ning vana ja uus vahetatakse dünaamiliselt – Amazoni lähenemine
Rakendamine:
Peida lüliti koodi, tee if-else otsus ja lülita lüliti sisse masinatele, mis vajavad halltooni, muidu on see välja lülitatud. Iga väljaande jaoks on kaks versiooni.
Merit
Kiire tagasikerimine, pole vaja süsteemi uuesti avaldada ega taaskäivitada.
Puudus
Ole kaldu koodi järgi.
Harunenud loogika toob kaasa keerukust.
Seda meetodit kasutas autor siis, kui olin Alibabas, vahetades kaupade andmebaasi Oracle'ilt MySQL-ile ja kasutades olekumuutujat kontrollimiseks. Nii saavutatakse sujuva migratsiooni efekt.
Variant 2: Eelväljalaskemasin – Alibaba praktika
Tegelikult ei ole see halltoonid tõelises mõttes. Sest see eelväljalase masin on sisemine IP ja sellel puudub väline teenus. Verifitseerimiseks on vajalik domeeni sidumine. Aga andmed on täielikult veebis. Seega on see põhimõtteliselt lihtne lähenemine mõnele konkreetsele Grayscale'i kasutajale (kasutajatele, kellel on juurdepääs halltoonimasinale, sisemistele testikasutajatele). Tegelikult on API poolel sarnane lähenemine, mis on meie Gamma keskkond, ning pakume ka Gamma masina domeeninime, et välised koostööpartnerid saaksid testimisega koostööd teha.
Merit
Lihtne
Puudus
Masina raiskamine (selle saab panna tootmiskeskkonda pärast eelväljalaske lõpetamist ja eemaldada nginxist eelväljalaske ajal, kuid O&M tugi on vajalik.) ）
Ei ole piisavalt paindlik
IDL-teenuseid saab kasutada ainult juurdepääsukihi masinatele ning IDL-teenuseid tuleb käsitleda eraldi.
Variant 3: SET juurutamine
1. Paigutada isolatsioonis vastavalt teenustele
Näiteks praeguses API konteinerite praktikas saab juurutamise detailsuse saavutada API tasemele ja front-end forward'id vastavalt nginx-ile. Nagu mida:
Mikro ostlemise API konteiner: api.weigou.qq.com
Pat API Container:api.paipai.com
Yixun API konteiner: api.yixun.com
Veebipõhine ostlemise API Container:api.buy.qq.com
Ülaltoodud on isoleeritud juurutus suurte ettevõtete tasandil. Seda saab veelgi täiustada mooduli tasemele, näiteks virtuaalse teenuse e-kaubanduse API, mis on Paipai all, kuid kuna need on ühendatud WeChatiga, on külastuste arv märkimisväärselt kasvanud, et vältida Paipai teiste ettevõtete mõjutamist ning et vältida teiste ettevõtete mõju all, on API siin, et paigaldada neile eraldi kaks masinat, nginx saab seadistada virtuaalse API ligipääsu tühjendamiseks:
Virtuaalne API konteiner: http://api.paipai.com/v2/virbiz
Nii saame versiooni avaldamisel esmalt valida Yixuni, mille ärimaht on väikseim, ja seejärel märgata, et probleeme pole, enne kui kasutame kõiki teisi platvorme.
2. Juurutamine kasutaja isolatsiooni kaudu
See ei sobi väga avatud platvormidele, kuid sobib väga rakendusolukordadeks nagu SNS. Näiteks on QQ süsteem jagatud mitmeks komplektiks vastavalt kasutajanumbri segmentidele ning iga komplekt sisaldab 100 miljonit järjestikust numbrit. Eeldades, et viimane QQ arv on ligikaudu 1 miljard, on kokku 10 hulka (komplekt 1 kuni komplekt 10). Nii saad iga kord valida ühe SET-idest, mida avaldada, ja kõrgetasemeline QQ ei ole sageli väga oluline kasutaja, seega avaldatakse esmalt SET10.
Merit
Isoleeritud juurutamine, mille mõju ärivaldkondade vahel on minimaalne. Toetab automaatselt halltoonide avaldamist.
Puudus
Halltoonide granulaarsus sõltub isoleeritud paigutuse granulaarsusest, mis on tavaliselt suur.
Masinate raiskamine võrreldes tsentraliseeritud juurutusega.
Iga äriliini versioonid võivad olla ebajärjekindlad, mis ei soodusta ühtset juhtimist.
On teatud juurutamise ja juurutamise kulud
Skeem 4: Dünaamiline marsruutimine
Meetod: Kasuta halltoonide poliitikat, mida saab paindlikult konfigureerida, et mõjutada koormustasakaalu käitumist ja võimaldada halltooni teenuse IP ja pordi tagastada vastavalt halltoonide poliitikale.
Sobib teenindushalltoonideks koos tagakontori IDL-iga.
Merit
Paindlik, kontrollitav.
Puudus
Praegune konfiguratsioonikeskus ja L5 ise ei arvesta kindlate marsruutimispoliitikatega ega ole skaleeritavad, seega tuleb neid arendada väljaspool neid.
API-de metaandmeallikad on suhteliselt hajutatud ning praegu on API ja IDL metaandmed, API tasemed ja sageduspiirangud jaotatud erinevate andmeallikate vahel ning nüüd on vaja lisada halltoonides marsruutimisandmeallikas.
Üldiselt on halltoonides nginx+lua avaldamiseks kolm viisi: nginx jaotatakse küpsiste järgi ja nginx määratakse kaalu järgi:
nginx+lua eristab külastaja IP-aadressi järgi, kuna ettevõte ekspordib IP-aadressi ja veebilehele pääseb ligi kas vana või uus versioon, mis ei sobi selle meetodi jaoks
nginx määrab kaalud kaalude alusel, mida on lihtne rakendada ja mida saab proovida
Nginx jagab küpsiste põhjal ja Grayscale avaldab kasutajate põhjal
|
Postitatud 09.03.2017 15:48:27
|
|
|
|
