L'immagine sopra è la versione in scala di grigi di Tencent, gli utenti comuni possono accedervi, il server Alibaba Cloud non può essere accessibile, il ping è normale e anche l'IP di risoluzione è normale
È semplicemente inaccessibile, si vede che anche Tencent ama giocare con il rilascio in scala di grigi...
1. Perché l'uscita in scala di grigi
- I servizi internet cambiano frequentemente e i cicli di rilascio sono brevi. Velocità e qualità sono sempre difficili da combinare.
- La pubblicazione in scala di grigi può ridurre il rischio della pubblicazione e ridurre l'impatto di questa situazione.
- Ridurre la dipendenza dai test e ridurre il costo di costruzione dei dati per l'auto-testing offline.
- È comodo monitorare centralmente i log e pubblicarli per intero A causa del ruolo del bilanciamento del carico in ogni livello, è difficile tracciare un call link completo.
- Puoi usare account di test in scala grigia, e poi account utente reali in scala di grigi dopo che l'account di test è stato superato, per ridurre ulteriormente il rischio e l'impatto della pubblicazione.
- Un rollback facile.
Problemi che non possono essere risolti con le release in scala di grigi
Va sottolineato che l'"impatto tollerabile" menzionato sopra deve essere recuperabile, ad esempio, l'API non può essere chiamata per un certo periodo di tempo, ma dopo la riparazione può essere richiamata con successo. La perdita o distruzione permanente dei dati degli utenti (come informazioni sui prodotti, ordini, ecc.) è intollerabile. Pertanto, è responsabilità degli architetti delle imprese Internet riparare i dati degli utenti persi a uno stato recente (come da un'ora a una settimana fa) tramite un intervento manuale in caso di perdita di dati utente dovuta a disturbi del sistema di produzione (come backup regolari dei dati utente, scrittura di log delle operazioni, ecc.).
CONSIGLI Prova prima la politica in scala di grigi del tuo account per ridurre il rischio di danneggiare o perdere i dati degli utenti reali.
2. Quale effetto è atteso?
Indipendentemente dalla modifica, vogliamo che richieste specifiche vengano instradate alla nostra versione della modifica (versione in scala di grigi) per osservazione e validazione.
3. Strategia in scala di grigi
In effetti, è proprio a quali richieste dovrebbero essere instradate nella nostra versione in scala di grigi (macchina in scala di grigi). Questo è spesso fortemente legato al business. Ad esempio, per le API, generalmente ci sono i seguenti requisiti:
Utenti specifici (ad esempio, account di test)
App specifiche (ad esempio, app di test o app partner)
Moduli e interfacce specifiche (solo alcune interfacce necessitano della scala di grigi, che generalmente è una modifica dei contenitori API, e alcune API poco importanti vengono utilizzate per i test in scala di grigi). ）
Macchina specifica (alcuni IP di richiesta vengono inoltrati alla macchina in scala di grigi)
4. Discussione sugli schemi in scala di grigi
Soluzione 1: Il livello del codice viene giudicato dalla bandiera concordata, e vecchio e nuovo vengono commutati dinamicamente - approccio di Amazon
Implementazione:
Interra l'interruttore nel codice, fai un giudizio if-else e imposta l'interruttore su su attivo per le macchine che richiedono scala di grigi, altrimenti è disattivato. Ci sono due versioni per ogni uscita.
merito
Rollback veloce, non c'è bisogno di ripubblicare e riavviare il sistema.
mancanza
Sii incline a rispettare il codice.
La logica ramificata porta complessità.
Questo metodo è stato usato dall'autore quando ero su Alibaba, passando il database dei beni da Oracle a MySQL e usando una variabile di stato per il controllo. Ottenendo così l'effetto di una migrazione fluida.
Opzione 2: Macchina pre-rilascio - Pratica di Alibaba
In realtà, questo non è una scala di grigi nel vero senso. Perché questa macchina pre-release è un IP interno e non ha un servizio esterno. Il domain binding è necessario per la verifica. Ma i dati sono completamente online. Quindi è essenzialmente un approccio semplice per alcuni utenti specifici di Grayscale (utenti che hanno accesso alla macchina in Grayscale, utenti di test interni). In effetti, c'è un approccio simile sul lato API, che è il nostro ambiente Gamma, e forniamo anche il nome di dominio della macchina Gamma per facilitare la cooperazione con utenti esterni cooperanti con i test.
merito
Semplice
mancanza
Sprecare una macchina (questa può essere inserita nell'ambiente di produzione dopo il completamento del pre-rilascio e rimossa da nginx durante il pre-rilascio, ma è necessario il supporto O&M.) ）
Non abbastanza flessibile
I servizi IDL possono essere utilizzati solo per macchine a livello di accesso, e i servizi IDL devono essere considerati separatamente.
Opzione 3: Distribuzione SET
1. Dispiegare in isolamento secondo i servizi
Ad esempio, nella pratica attuale dei container API, la granularità del deployment può essere raggiunta fino al livello API, e il front-end avanza secondo nginx. Come cosa:
Container API Micro Shopping: api.weigou.qq.com
Pat API Container:api.paipai.com
Yixun API Container: api.yixun.com
Online shopping API Container:api.buy.qq.com
Quanto sopra è un impiego isolato a livello di grande azienda. Può anche essere ulteriormente perfezionata a livello di modulo, come l'API dell'e-commerce di servizi virtuali, che è un sotto-business modulo sotto Paipai, ma poiché sono collegati a WeChat, il numero di visite è aumentato significativamente, per evitare di influenzare le altre attività di Paipai, e per evitare di essere influenzate da altre attività, l'API qui serve a distribuire due macchine separatamente per esse, nginx può essere configurato per drenare l'accesso virtuale all'API:
Container API virtuale: http://api.paipai.com/v2/virbiz
In questo modo, quando rilasciamo una versione, possiamo prima scegliere Yixun con il volume di business più basso da pubblicare, e poi osservare che non ci sono problemi prima di usare tutte le altre piattaforme.
2. Distribuzione tramite isolamento utente
Questo non è molto adatto per piattaforme aperte, ma è molto adatto a scenari applicativi come SNS. Ad esempio, il sistema QQ è suddiviso in diversi insiemi in base ai segmenti di numero utente, e ogni insieme contiene 100 milioni di numeri consecutivi. Assumendo che l'ultimo numero QQ sia vicino a 1 miliardo, ci sono in totale 10 insiemi (dal Set 1 al Set 10). In questo modo, puoi scegliere uno dei SET da pubblicare ogni volta, e QQ di alto livello spesso non è un utente molto importante, quindi SET10 sarà rilasciato per primo.
merito
Distribuzione isolata con un impatto minimo tra le linee di business. Supporta automaticamente la pubblicazione in scala di grigi.
mancanza
La granularità della scala di grigi dipende dalla granularità del dispiegamento isolato, che generalmente è grande.
Spreco di macchine rispetto al deployment centralizzato.
Le versioni di ogni linea di business possono essere incoerenti, il che non favorisce una gestione unificata.
Ci sono alcuni costi di implementazione e implementazione
Schema 4: Instradamento dinamico
Metodo: Utilizzare una policy in scala di grigi che possa essere configurata in modo flessibile per influenzare il comportamento del bilanciamento di carico e permettergli di restituire l'IP e la porta del servizio in scala di grigi secondo la politica in scala di grigi.
Adatto per il servizio in scala di grigi con IDL in back-office.
merito
Flessibile, controllabile.
mancanza
L'attuale centro di configurazione e L5 stesso non considerano politiche di routing specifiche e non sono scalabili, quindi devono essere sviluppati al di fuori di essi.
Le fonti di metadati delle API sono relativamente disperse, e attualmente i metadati API e IDL, i livelli API e i limiti di frequenza sono distribuiti tra diverse fonti dati, ed è ora necessario aggiungere una fonte di dati di routing in scala di grigi.
Generalmente ci sono tre modi per pubblicare nginx+lua in scala di grigi: nginx viene distribuito secondo i cookie, e nginx viene assegnato in base al peso:
nginx+lua distingue in base all'indirizzo IP del visitatore, perché l'azienda esporta un indirizzo IP e il sito web sarà accessibile sia alla versione vecchia che alla nuova, che non è adatta a questo metodo
Nginx assegna i pesi in base ai pesi, cosa semplice da implementare e che può essere provata
Nginx si divide in base ai cookie, e Grayscale pubblica in base agli utenti
|
Pubblicato su 09/03/2017 15:48:27
|
|
|
|
