Iepriekš minētais attēls ir Tencent pelēktoņu izlaidums, parastie lietotāji tam var piekļūt, Alibaba Cloud serverim nevar piekļūt, ping ir normāls, un izšķirtspējas IP ir arī normāls
Tas ir vienkārši nepieejams, var redzēt, ka Tencent patīk spēlēt arī ar pelēktoņu izlaišanu ...
1. Kāpēc pelēktoņu izlaišana
- Interneta pakalpojumi bieži mainās, un izlaišanas cikli ir īsi. Ātrumu un kvalitāti vienmēr ir grūti apvienot.
- Pelēktoņu publicēšana var samazināt publicēšanas risku un samazināt ietekmes apjomu.
- Samaziniet atkarību no testēšanas un samaziniet datu veidošanas izmaksas bezsaistes paštestēšanai.
- Ir ērti centralizēti uzraudzīt žurnālus un publicēt tos pilnībā Slodzes līdzsvarošanas lomas dēļ katrā slānī ir grūti izsekot pilnīgu zvana saiti.
- Varat izmantot pelēktoņu testa kontus un pēc tam pelēktoņu reālos lietotāju kontus pēc testa konta nokārtošanas, lai vēl vairāk samazinātu publicēšanas risku un ietekmi.
- Viegla atcelšana.
Problēmas, kuras nevar atrisināt ar pelēktoņu izlaidumiem
Jāuzsver, ka iepriekš minētajai "pieļaujamajai ietekmei" jābūt atgūstamai, piemēram, API nevar izsaukt uz noteiktu laiku, bet pēc remonta to var veiksmīgi izsaukt. Lietotāja datu (piemēram, informācija par produktu, informācija par pasūtījumu utt.) neatgriezeniska zudums vai iznīcināšana nav pieļaujama. Tāpēc interneta uzņēmumu arhitektu pienākums ir labot zaudētos lietotāja datus nesenā stāvoklī (piemēram, pirms stundas līdz nedēļai), manuāli iejaucoties lietotāja datu zuduma gadījumā ražošanas sistēmas traucējumu dēļ (piemēram, regulāra lietotāja datu dublēšana, operāciju žurnālu rakstīšana utt.).
PADOMI Vispirms pārbaudiet sava konta pelēktoņu politiku, lai samazinātu risku sabojāt vai zaudēt reālu lietotāju datus.
2. Kāds efekts ir sagaidāms?
Neatkarīgi no izmaiņām, mēs vēlamies, lai konkrēti pieprasījumi tiktu novirzīti uz mūsu izmaiņu versiju (pelēktoņu versiju) novērošanai un apstiprināšanai.
3. Pelēktoņu stratēģija
Patiesībā pieprasījumi ir jānovirza uz mūsu pelēktoņu versiju (pelēktoņu mašīnu). Tas bieži ir cieši saistīts ar uzņēmējdarbību. Piemēram, API parasti ir šādas prasības:
Konkrēti lietotāji (piemēram, testa konti)
Konkrētas lietotnes (piemēram, testa lietotnes vai partneru lietotnes)
Specifiski moduļi un saskarnes (tikai dažām saskarnēm ir nepieciešamas pelēktoņas, kas parasti ir API konteineru modifikācija, un dažas API, kas nav ļoti svarīgas, tiek izmantotas pelēktoņu testēšanai.) ）
Specifiska ierīce (daži pieprasījuma IP tiek pārsūtīti uz pelēktoņu ierīci)
4. Pelēktoņu shēmu apspriešana
1. risinājums: koda līmenis tiek vērtēts pēc saskaņotā karoga, un vecais un jaunais tiek dinamiski pārslēgti - Amazon pieeja
Ieviešana:
Apglabājiet slēdzi kodā, izdariet spriedumu "if-else" un iestatiet slēdzi uz ieslēgtu mašīnām, kurām nepieciešama pelēktoņa, pretējā gadījumā tas ir izslēgts. Katram laidienam ir divas versijas.
Nopelniem
Ātra atcelšana, nav nepieciešams atkārtoti publicēt un pārstartēt sistēmu.
Trūkums
Esiet tendēts uz kodēšanu.
Sazarotā loģika rada sarežģītību.
Šo metodi autors izmantoja, kad es biju Alibaba, pārslēdzot preču datu bāzi no Oracle uz MySQL un izmantojot stāvokļa mainīgo kontrolei. Tādējādi panākot vienmērīgas migrācijas efektu.
2. variants: pirmsizlaides mašīna - Alibaba prakse
Patiesībā tas nav pelēktoņi patiesajā nozīmē. Tā kā šī pirmsizlaides mašīna ir iekšēja IP adrese, un tai nav ārēja pakalpojuma. Verifikācijai ir nepieciešama domēna saistīšana. Bet dati ir pilnīgi tiešsaistē. Tātad tā būtībā ir vienkārša pieeja dažiem konkrētiem pelēktoņu lietotājiem (lietotājiem, kuriem ir piekļuve pelēktoņu mašīnai, iekšējās pārbaudes lietotājiem). Patiesībā līdzīga pieeja ir arī API pusē, kas ir mūsu Gamma vide, un mēs arī nodrošinām Gamma mašīnas domēna nosaukumu, lai atvieglotu ārējo sadarbības lietotāju sadarbību ar testēšanu.
Nopelniem
Vienkārši
Trūkums
Izšķērdēt mašīnu (to var ievietot ražošanas vidē pēc pirmsizlaides pabeigšanas un noņemt no nginx pirmsizlaides laikā, bet ir nepieciešams O&M atbalsts.) ）
Nav pietiekami elastīgs
IDL pakalpojumus var izmantot tikai piekļuves slāņa mašīnām, un IDL pakalpojumi ir jāaplūko atsevišķi.
3. iespēja: SET izvietošana
1. Izvietojiet izolēti atbilstoši pakalpojumiem
Piemēram, pašreizējā API konteineru praksē izvietošanas detalizāciju var sasniegt līdz API līmenim, bet priekšgala uz priekšu - saskaņā ar nginx. Piemēram, kas:
Mikro iepirkšanās API konteiners: api.weigou.qq.com
Pat API Container:api.paipai.com
Yixun API konteiners: api.yixun.com
Tiešsaistes iepirkšanās API Container:api.buy.qq.com
Iepriekš minētais ir izolēts izvietojums lielā biznesa līmenī. To var arī vēl vairāk uzlabot līdz moduļa līmenim, piemēram, virtuālā pakalpojuma e-komercijas API, kas ir apakšbiznesa modulis, kas karājas zem Paipai, bet, tā kā tie ir savienoti ar WeChat, apmeklējumu skaits ir ievērojami palielinājies, lai izvairītos no citu Paipai uzņēmumu ietekmes, un, lai izvairītos no citu uzņēmumu ietekmes, API šeit ir izvietot divas mašīnas atsevišķi, nginx var konfigurēt, lai iztukšotu virtuālo API piekļuvi:
Virtuālais API konteiners: http://api.paipai.com/v2/virbiz
Tādā veidā, izlaižot versiju, mēs vispirms varam izvēlēties Yixun ar mazāko publicējamo biznesa apjomu un pēc tam novērot, ka pirms visu pārējo platformu izmantošanas nav problēmu.
2. Izvietošana, izmantojot lietotāju izolāciju
Tas nav ļoti piemērots atvērtām platformām, bet tas ir ļoti piemērots tādiem lietojumprogrammu scenārijiem kā SNS. Piemēram, QQ sistēma ir sadalīta vairākās kopās atbilstoši lietotāju numuru segmentiem, un katrā komplektā ir 100 miljoni secīgu skaitļu. Pieņemot, ka jaunākais QQ skaitlis ir tuvu 1 miljardam, kopumā ir 10 komplekti (no 1. līdz 10. kopai). Tādā veidā jūs varat izvēlēties vienu no SETS, ko publicēt katru reizi, un augsta līmeņa QQ bieži vien nav ļoti svarīgs lietotājs, tāpēc SET10 tiks izlaists vispirms.
Nopelniem
Izolēta izvietošana ar minimālu ietekmi uz visām biznesa līnijām. Automātiski atbalstīt pelēktoņu publicēšanu.
Trūkums
Pelēktoņu granularitāte ir atkarīga no izolētās izvietošanas detalizācijas, kas parasti ir liela.
Mašīnu izšķērdēšana salīdzinājumā ar centralizēto izvietošanu.
Katras biznesa līnijas versijas var būt nekonsekventas, kas neveicina vienotu pārvaldību.
Ir noteiktas ieviešanas un ieviešanas izmaksas
4. shēma: dinamiskā maršrutēšana
Metode: izmantojiet pelēktoņu politiku, kuru var elastīgi konfigurēt, lai ietekmētu slodzes bilances darbību un ļautu tai atgriezt pelēktoņu pakalpojuma IP un portu saskaņā ar pelēktoņu politiku.
Piemērots pelēktoņu apkalpošanai ar back-office IDL.
Nopelniem
Elastīgs, kontrolējams.
Trūkums
Pašreizējais konfigurācijas centrs un pats L5 neņem vērā norādītās maršrutēšanas politikas un nav mērogojamas, tāpēc tās ir jāizstrādā ārpus tām.
API metadatu avoti ir salīdzinoši izkliedēti, un pašlaik API un IDL metadati, API līmeņi un biežuma ierobežojumi ir sadalīti dažādos datu avotos, un tagad ir nepieciešams pievienot pelēktoņu maršrutēšanas datu avotu.
Parasti ir trīs veidi, kā publicēt pelēktoņus nginx+lua, nginx tiek sadalīts saskaņā ar sīkdatnēm, un nginx tiek piešķirts pēc svara:
nginx+lua atšķiras pēc apmeklētāja IP adreses, jo uzņēmums eksportē IP adresi, un vietnei tiks piekļūta vai nu vecā versija, vai jaunā versija, kas nav piemērota šai metodei
Nginx piešķir svarus, pamatojoties uz svariem, kas ir vienkārši īstenojami un kurus var izmēģināt
Nginx sadalās, pamatojoties uz sīkfailiem, un pelēktoņu publikācijas, pamatojoties uz lietotājiem
|
Publicēts 09.03.2017 15:48:27
|
|
|
|
