Questo documento mostra un'architettura che utilizza un Mesh di servizi Istio di eseguire la migrazione da un ambiente legacy, come un data center on-premise che delle applicazioni nelle macchine virtuali, Google Kubernetes Engine (GKE) L'utilizzo di un mesh di servizi può ridurre la complessità della migrazione e del refactoring perché disaccoppia le funzioni di rete dalle funzioni di servizio.
Questo documento spiega la logica della migrazione e ne delinea le fasi generali. Puoi utilizzare questa architettura per eseguire una migrazione in un dell'operazione (a volte chiamata migrazione big-bang) o di eseguire una la migrazione di ciascuna caratteristica. Il documento di deployment allegato ti guiderà attraverso un esempio di migrazione.
Questa architettura e la relativa guida all'implementazione sono rivolte ai professionisti IT che gestiscono un'infrastruttura complessa di cui vogliono eseguire la migrazione graduale modernizzare, riducendo al minimo quanto segue:
- Inattività
- Impegno di refactoring
- Complessità operativa della rete
I concetti spiegati si applicano a qualsiasi cloud, quindi il documento presuppone che hai familiarità con tecnologie cloud, container e microservizi.
Come descritto nella sezione Eseguire la migrazione a Google Cloud: inizia, esistono diversi pattern per la migrazione al cloud. L'architettura in questo utilizza un pattern di refactoring (a volte chiamato sposta e migliora), in cui il pattern viene applicato a ogni funzionalità dell'applicazione, anziché dell'applicazione nel suo insieme.
Durante la migrazione, l'applicazione ha un'architettura ibrida in cui sono disponibili su Google Cloud e alcune sono ancora nell'ambiente legacy. Al termine della migrazione, l'applicazione completa viene ospitata in Google Cloud.
Architettura
Il seguente diagramma mostra come utilizzare un mesh di servizi per instradare il traffico ai microservizi in esecuzione nell'ambiente di origine o Google Cloud:
L'architettura include i seguenti componenti:
Un ambiente di origine, in questo caso un'istanza Compute Engine che ospita del carico di lavoro di esempio di cui eseguire la migrazione. L'ambiente di origine può essere on-premise o in hosting su altre piattaforme cloud.
Un mesh di servizi, in questo caso Istio Gateway, che collega diversi servizi insieme. Il mesh di servizi fornisce funzionalità di networking di alto valore come Service Discovery, comunicazioni sicure, bilanciamento del carico, traffico la gestione e l'osservabilità.
Una tipica implementazione di un mesh di servizi accoppia ciascun servizio un proxy che fornisce queste funzionalità. Il proxy di servizio è molto spesso noto come sidecar. Il ruolo del file collaterale è aumentare e migliorare l'applicazione a cui sono associati, spesso senza la consapevolezza per l'applicazione. Nella guida al deployment fornita, utilizzerai Envoy come proxy sidecar.
Un carico di lavoro che contiene un'applicazione composta di microservizi. Un microservizio è un componente autonomo creato per una funzionalità dell'applicazione. In questa architettura, l'applicazione è composto da vari microservizi che non sono distinguibili dagli utenti. Ad esempio, un componente che gestisce le recensioni dei libri è un microservizio.
Nel pattern a microservizi, l'applicazione è l'aggregazione più microservizi, ognuno con un obiettivo specifico. Ad esempio, un microservizio che gestisce le valutazioni dei libri e un altro gestisce le recensioni dei libri. Questi microservizi dovrebbero essere a basso accoppiamento devono interfacciarsi tra loro tramite API ben definite. Possono essere scritte in linguaggi e framework diversi (come applicazioni poliglotta), e possono avere cicli di vita diversi.
Un container che serve a definire ulteriormente i confini di ogni microservizio. Poiché l'ambiente di destinazione in questa architettura orchestrato con Kubernetes, ti consigliamo di containerizzare di microservizi mediante i seguenti strumenti:
- Docker è uno strumento per isolare i programmi a livello di spazio utente a livello di sistema operativo. Esegue pacchetti chiamati containers.
- Kubernetes è la principale soluzione di orchestrazione per i carichi di lavoro containerizzati. it offre funzionalità come Service Discovery, bilanciamento del carico di pod e nodi con riparazione automatica, nonché la gestione di secret e configurazioni.
- GKE è un ambiente Kubernetes gestito e pronto per la produzione, in Google Cloud.
Per eseguire una migrazione utilizzando un mesh di servizi, devi completare quanto segue fasi:
- Valutare l'ambiente precedente: raccogli informazioni e stabilisci una insieme di requisiti per l'ambiente di destinazione e di base per i test e convalida.
- Crea le basi nell'ambiente di destinazione: esegui il provisioning della destinazione dell'ambiente di lavoro e applicare Metodologia Infrastructure as Code per rendere la tua infrastruttura verificabile, ripetibile e provvisorio.
- Esegui il deployment dei servizi e avvia il routing del traffico all'ambiente di destinazione: Completa una singola operazione per eseguire il deployment di tutte le istanze dei microservizi contemporaneamente o completare un deployment graduale per eseguire il deployment di un microservizio nel tempo.
- Interrompere il routing del traffico verso l'ambiente precedente: configura le regole di routing per instradare il traffico ai servizi in esecuzione nell'ambiente di destinazione .
- Ritira l'ambiente legacy: aggiorna i record DNS in modo che puntino a il bilanciatore del carico che configuri durante il provisioning dell'ambiente di destinazione durante la fase di sviluppo.
Questo documento descrive alcune considerazioni sulla progettazione per questo tipo di migrazione, e la relativa guida all'implementazione fornisce i passaggi dettagliati per completare migrazione.
Note sul layout
Questa sezione fornisce indicazioni per aiutarti a sviluppare un'architettura che soddisfi le i tuoi requisiti specifici in termini di affidabilità, efficienza operativa, dell'ottimizzazione del rendimento.
Affidabilità
Le seguenti sezioni descrivono considerazioni sull'affidabilità migrazione.
Utilizza una strategia di migrazione graduale
Sebbene questa architettura possa essere utilizzata per una migrazione con una sola operazione, ti consigliamo di usare una strategia di migrazione graduale. Il completamento di una migrazione in un'operazione è difficile a causa delle sfide e dei rischi connessi nella migrazione di una o più applicazioni contemporaneamente. Quando hai dei vincoli in termini di tempo e budget, concentrandosi su una migrazione con una sola operazione non lascia molto per lavorare su nuove funzionalità dell'applicazione.
Al contrario, una migrazione graduale di ciascuna funzionalità ha un tempo di complessità dovuta alle dimensioni ridotte del carico di lavoro di cui eseguire la migrazione: una singola funzionalità ha un impatto minimo rispetto a un'intera applicazione. Una migrazione graduale consente di distribuire il rischio su eventi di migrazione più piccoli, anziché su una singolo esercizio ad alto rischio. Una migrazione graduale consente anche al team addetto alla migrazione pianificare, progettare e sviluppare più strategie di migrazione per soddisfare tipi di funzionalità.
Per indicazioni su come scegliere le funzionalità di cui eseguire la migrazione per prime e come eseguire la migrazione delle funzionalità stateful, Scegliere le app di cui eseguire la migrazione per prime in "Migrazione a Google Cloud: valuta e scopri i tuoi carichi di lavoro".
Utilizza una suite di test di conformità
Per facilitare la migrazione, ti consigliamo di utilizzare un test di conformità Google Cloud. Una suite di test di conformità è un insieme di test che puoi eseguire rispetto a una per verificare se soddisfa un determinato insieme di requisiti. Se se l'ambiente è valido, ne soddisfa i requisiti. Ad esempio, puoi convalidare la risposta a una richiesta di test oppure controllare se le dipendenze le applicazioni in esecuzione.
Puoi iniziare con gli strumenti di monitoraggio, tracciamento e visualizzazione del mesh di servizi per una convalida manuale. Poi puoi implementare la suite di test ed evolverla nel tempo nei seguenti modi:
- Test di carico: puoi far evolvere la suite di test inviando automaticamente per testare il traffico nell'ambiente e valutare i risultati.
- Strumento di test di conformità: consente di progettare e sviluppare una suite di test utilizzando uno strumento dedicato.
Esegui la suite di test di conformità sull'ambiente legacy come riferimento e anche nell'ambiente di destinazione durante e dopo la migrazione.
Le suite di test devono concentrarsi sui seguenti aspetti per la convalida durante migrazione:
- Provisioning: esegui il provisioning delle risorse di cui hai bisogno nel tuo dell'ambiente di rete prima di configurarli.
- Configurazione: dopo aver eseguito il provisioning delle risorse nell'ambiente, e configurarle in base alle esigenze della tua applicazione. Disporre di una suite di test di configurazione assicura che l'ambiente sia pronto per ospitare la tua applicazione.
- Logica di business: dopo aver convalidato il provisioning e configurazione dell'ambiente, convalidare la logica di business un'applicazione. Ad esempio, puoi convalidare le risposte alle richieste.
Chef InSpec, RSpec, e Serverspec strumenti per lo sviluppo di suite di test di conformità automatizzate. Funzionano su qualsiasi ed è espandibile per consentirti di implementare i tuoi controlli, a partire dai controlli integrati.
Quando esegui il provisioning dell'ambiente di destinazione, puoi utilizzare il test di conformità per convalidarla. Potresti dover aggiornare la suite di test per tenere conto le differenze finali tra l'ambiente legacy e quello di destinazione, come di rete e hardware. Ricorda che stai passando da una da un ambiente on-premise, dal quale hai il controllo completo, su un cloud pubblico nel quale di solito non hai accesso completo all'intero stack.
Prima di instradare il traffico dal livello di bilanciamento del carico dell'infrastruttura legacy all'ambiente di destinazione, ti consigliamo di eseguire suite di test di conformità logica rispetto ai microservizi esposti nell'ambiente di destinazione. La suite di test può aiutare a garantire che i microservizi siano funziona come previsto. Ad esempio, puoi convalidare le risposte restituite e i servizi esposti dal mesh di servizi. Puoi conservare il percorso originale come opzione di backup nel caso in cui sia necessario eseguire il rollback delle modifiche nell'ambiente legacy. Instradando una piccola parte del traffico di produzione verso di microservizi in esecuzione nell'ambiente di destinazione, possono creare fiducia nell'ambiente di destinazione e aumentare il traffico totale nel tempo.
Non consentire le richieste cross-environment
Durante la fase di test di conformità, è consigliabile perfezionare il routing regole per non consentire le richieste cross-environment, in modo che quando arriva una richiesta del client un ambiente, legacy o di destinazione, rimane in quell'ambiente. Non consentire le richieste cross-environment contribuisce a garantire che i test vengano eseguiti correttamente convalidare l'ambiente di destinazione. Se non consenti queste richieste, viene eseguito un test potrebbe segnalare l'esito positivo nell'ambiente di origine anziché nell'ambiente di destinazione a tua insaputa.
Ritira l'ambiente legacy
Prima di ritirare l'ambiente legacy, verifica che tutte le seguenti condizioni siano vero:
- Nessun traffico viene instradato verso istanze di microservizi in esecuzione in nell'ambiente legacy.
- Nessun traffico passa attraverso le interfacce dell'ambiente legacy.
- L'ambiente di destinazione è stato completamente convalidato.
Quando queste condizioni sono soddisfatte, puoi aggiornare i record DNS in modo che puntino allo che configuri durante la fase di provisioning dell'ambiente di destinazione. Azioni sconsigliate ritira l'ambiente legacy, a meno che tu non sia sicuro che l'ambiente di destinazione convalidato. Non limitare la convalida solo alla logica di business, prendi in considerazione altri requisiti non funzionali, come prestazioni e scalabilità.
Efficienza operativa
Le seguenti sezioni descrivono considerazioni sull'efficienza operativa la migrazione.
Valuta l'ambiente legacy
Prima di progettare o implementare un piano di migrazione, è necessario valutare dell'ambiente per raccogliere informazioni e stabilire una serie di requisiti dell'ambiente target e una base di riferimento per i test e la convalida. Inizierai con creando un catalogo di tutte le funzionalità dell'applicazione di cui eseguire la migrazione. Per ogni funzionalità, dovresti essere in grado di rispondere a questo insieme non esaustivo di domande:
- Quali sono l'ambiente di runtime e i requisiti delle prestazioni?
- Ci sono dipendenze da altre funzionalità?
- Questa funzionalità è fondamentale per l'attività?
- Questa funzionalità è stateless o stateful?
- Quanto refactoring è previsto per eseguirne la migrazione?
- Questa caratteristica può offrire una finestra di cut-over?
Per ulteriori informazioni, vedi Esegui la migrazione a Google Cloud: valuta e individua i tuoi carichi di lavoro.
Confronto tra risorse stateless e stateful
L'architettura utilizza un mesh di servizi perché disaccoppia le funzioni di servizio. (come viene implementata la logica di business) dalle funzioni di rete (come e quando indirizzare il traffico alle funzioni di servizio). Nel deployment associato, utilizzerai Istio come mesh di servizi.
Nell'ambiente legacy, la maggior parte delle chiamate di servizio non riguarda la rete, su una piattaforma monolitica. In un'architettura di microservizi, le comunicazioni tra i servizi avvengono su una rete e i servizi devono a questo modello diverso. Un mesh di servizi astrae le funzioni per gestire la rete delle comunicazioni, così non dovrai implementarle in ogni applicazione. R mesh di servizi riduce anche la complessità operativa della rete fornisce canali di comunicazione sicuri, bilanciamento del carico, gestione del traffico e di osservabilità che non richiedono alcuna configurazione.
Eseguendo il deployment e configurando un mesh di servizi, puoi instradare il traffico in modo dinamico. all'ambiente legacy o a quello di destinazione. Non è necessario modificare la configurazione dell'applicazione per supportare la migrazione, la gestione del traffico sia trasparente per i servizi nella rete mesh.
Sebbene questo approccio funzioni bene per le funzionalità stateless, devi di pianificazione e refactoring aggiuntivi per eseguire la migrazione di funzionalità stateful, sensibili alla latenza o altamente accoppiati ad altre funzionalità:
- Stateful: quando esegui la migrazione delle funzionalità stateful, devi farlo. per ridurre al minimo i tempi di inattività e la sincronizzazione e problemi di integrità e integrità durante la migrazione. Puoi scoprire di più sui dati strategie di migrazione nella sezione Valutazione degli approcci alla migrazione dei dati di "Migrazione a Google Cloud: trasferimento di set di dati di grandi dimensioni."
- Sensibile alla latenza: se una caratteristica è sensibile alla latenza quando per comunicare con altre funzionalità, potresti dover implementare durante il processo di migrazione. Proxy che possono precaricare i dati gli strati di memorizzazione nella cache sono comunemente usati per mitigare questa sensibilità.
- Elevato accoppiamento ad altre funzionalità: se due o più funzionalità sono altamente associate potrebbe essere necessario eseguirne la migrazione contemporaneamente. Anche se questo è più semplice della migrazione di un'intera applicazione, ma rispetto alla migrazione di una singola funzionalità.
Registra i servizi con il mesh di servizi
Perché il tuo ambiente legacy non è direttamente integrato con il servizio mesh, quando configuri la migrazione, devi registrare manualmente tutti in esecuzione nell'ambiente legacy con il mesh di servizi. Se il tuo ambiente è già in esecuzione in Kubernetes, puoi automatizzare la registrazione tramite l'integrazione incorporata con le API mesh di servizi.
Dopo aver registrato l'ambiente legacy, utilizzerai il mesh di servizi per esporre i microservizi in esecuzione nell'ambiente legacy. Puoi quindi instradare gradualmente il traffico ai microservizi dalle interfacce alle interfacce dell'ambiente di destinazione.
I client non noteranno alcuna interruzione del servizio, perché accedono alle interfacce di attraverso un livello di bilanciamento del carico. Routing del traffico all'interno di mesh di servizi è trasparente per i client, quindi i client non sanno che è stata modificata.
Ottimizzazione dei costi
Questa architettura utilizza i seguenti componenti fatturabili di Google Cloud:
Quando esegui il deployment dell'architettura, puoi utilizzare Calcolatore prezzi per generare una stima dei costi in base all'utilizzo previsto.
Ottimizzazione delle prestazioni
In questa architettura, il traffico è suddiviso quasi equamente tra i servizi sono in esecuzione in Compute Engine e i servizi in esecuzione con GKE. Il mesh di servizi bilancia il traffico tra le istanze di un servizio che seleziona, indipendentemente dal fatto che siano in esecuzione nel cluster GKE o nelle istanze Compute Engine. Se tutto il traffico passi attraverso il mesh di servizi, devi riconfigurare carichi di lavoro in esecuzione su Compute Engine per puntare ai servizi mesh di servizi, invece di connettervi direttamente. Puoi configurare criterio di bilanciamento del carico per le revisioni di ciascun servizio DestinationRule risorsa.
Deployment
Per eseguire il deployment di questa architettura, Esegui il deployment della migrazione con l'espansione del mesh Istio.
Passaggi successivi
- Informazioni GKE
- Informazioni Istio.
- Per altre architetture di riferimento, diagrammi e best practice, esplora il Centro architetture cloud.