Questo documento mostra un'architettura che utilizza un mesh di servizi Istio per eseguire la migrazione da un ambiente legacy, come un data center on-premise che esegue applicazioni in macchine virtuali, a 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 implementazione allegato ti guida tramite 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, pertanto il documento presuppone che tu abbia familiarità con le tecnologie cloud, i container e i microservizi.
Come descritto in Eseguire la migrazione a Google Cloud: inizia, esistono diversi pattern per la migrazione al cloud. L'architettura descritta in questo documento utilizza uno schema di refactoring (a volte chiamato sposta e migliora), in cui lo schema viene applicato a ogni funzionalità dell'applicazione anziché all' applicazione nel suo complesso.
Durante la migrazione, l'applicazione ha un'architettura ibrida in cui alcune funzionalità sono su Google Cloud e altre sono ancora nell'ambiente precedente. 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 in Google Cloud:
L'architettura include i seguenti componenti:
Un ambiente di origine, in questo caso un'istanza Compute Engine che ospita il carico di lavoro di esempio di cui eseguire la migrazione. L'ambiente di origine può anche essere on-premise o ospitato in altre piattaforme cloud.
Un mesh di servizi, in questo caso Istio Gateway, che collega diversi servizi. Il mesh di servizi fornisce funzionalità di networking di alto valore come il discovery dei servizi, le comunicazioni sicure, il bilanciamento del carico, la gestione del traffico e l'osservabilità.
Un'implementazione tipica di un'architettura mesh di servizi associa ogni servizio a un proxy che fornisce queste funzionalità. Il proxy del servizio viene spesso definito sidecar. Il ruolo del sidecar è potenziare e migliorare l'applicazione a cui è associato, spesso a sua insaputa. Nella guida all'implementazione in dotazione, utilizzi 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 è composta da diversi microservizi indistinguibili per gli utenti. Ad esempio, un componente che gestisce le recensioni dei libri è un microservizio.
Nel pattern a microservizi, l'applicazione è l'insieme di più microservizi, ciascuno con un obiettivo specifico. Ad esempio, un microservizio che gestisce le valutazioni dei libri e un altro gestisce le recensioni dei libri. Questi microservizi devono essere accoppiati in modo lasco e dialogare tra loro tramite API ben definite. Possono essere scritti in linguaggi e framework diversi (come nelle applicazioni poliglotte) e possono avere cicli di vita diversi.
Un contenitore che serve a definire ulteriormente i confini di ciascun 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 container.
- Kubernetes è la principale soluzione di orchestrazione per i carichi di lavoro containerizzati. Fornisce funzionalità come il rilevamento dei servizi, il bilanciamento del carico, i pod e i nodi di riparazione automatica e la gestione di segreti e configurazioni.
- GKE è un ambiente Kubernetes gestito e pronto per la produzione, in Google Cloud.
Per eseguire una migrazione utilizzando un service mesh, completa le seguenti fasi:
- Valuta l'ambiente precedente: raccogli informazioni e stabilisci un insieme di requisiti per l'ambiente di destinazione e una base di riferimento per i test e la 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 precedente: aggiorna i record DNS in modo che rimandino al bilanciatore del carico configurato durante la fase di provisioning dell'ambiente di destinazione.
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à del 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 vincoli di tempo e budget, concentrarti su una migrazione con una sola operazione non lascia molto spazio per lavorare sulle 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 prima la migrazione e su come eseguire la migrazione delle funzionalità con stato, consulta Scegliere le app di cui eseguire prima la migrazione in "Esegui la 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 su un ambiente 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.
Per una convalida manuale, puoi iniziare con gli strumenti di monitoraggio, tracciamento e visualizzazione del mesh di servizi. 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à: puoi 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 tue suite di test dovrebbero 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, configurale in base alle esigenze della tua applicazione. Avere una suite di test di configurazione garantisce che l'ambiente sia pronto per ospitare la tua applicazione.
- Logica di business: dopo aver convalidato il provisioning e 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 delle eventuali differenze tra l'ambiente precedente e quello di destinazione, ad esempio l'hardware e la topologia di rete. 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 dai servizi esposti dal service mesh. Puoi mantenere il percorso originale come opzione di backup nel caso in cui sia necessario eseguire il rollback delle modifiche e ripristinare l'ambiente precedente. Indirizzando una piccola parte del traffico di produzione alle istanze dei microservizi in esecuzione nell'ambiente di destinazione, puoi acquisire 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à, ti consigliamo di perfezionare le regole di routing per non consentire le richieste tra ambienti, in modo che quando una richiesta client raggiunge un ambiente, legacy o di destinazione, rimanga 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 neghi queste richieste, un test potrebbe segnalare il successo nell'ambiente di origine anziché nell'ambiente di destinazione senza che tu lo sappia.
Ritira l'ambiente precedente
Prima di ritirare l'ambiente precedente, verifica che tutte le condizioni riportate di seguito siano soddisfatte:
- Nessun traffico viene instradato verso istanze di microservizi in esecuzione in nell'ambiente legacy.
- Nessun traffico passa attraverso le interfacce dell'ambiente precedente.
- L'ambiente di destinazione è stato completamente convalidato.
Quando queste condizioni sono soddisfatte, puoi aggiornare i record DNS in modo che rimandino al bilanciatore del carico configurato durante la fase di provisioning dell'ambiente di destinazione. Non ritirare l'ambiente precedente, a meno che tu non sia sicuro che l'ambiente di destinazione sia stato convalidato. Non limitare la convalida solo alla logica di business, prendi in considerazione altri requisiti non funzionali, come prestazioni e scalabilità.
Efficienza operativa
Le sezioni seguenti descrivono le considerazioni per l'efficienza operativa della migrazione.
Valutare l'ambiente precedente
Prima di progettare o implementare un piano di migrazione, devi valutare l'ambiente precedente per raccogliere informazioni e stabilire un insieme di requisiti per l'ambiente di destinazione e una linea di base 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 elenco 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 funzionalità può prevedere una finestra di transizione?
Per ulteriori informazioni, vedi Esegui la migrazione a Google Cloud: valuta e individua i tuoi carichi di lavoro.
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. Un servizio mesh riduce anche la complessità operativa della rete perché fornisce canali di comunicazione sicuri, bilanciamento del carico, gestione del traffico e funzionalità di osservabilità che non richiedono alcuna configurazione.
Se esegui il deployment e la configurazione di un service mesh, puoi instradare dinamicamente il traffico all'ambiente precedente 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à:
- Con stato: quando esegui la migrazione di funzionalità con stato, devi eseguire la migrazione anche dei dati per ridurre al minimo i tempi di inattività e attenuare i problemi di sincronizzazione e integrità durante la migrazione. Puoi scoprire di più sulle strategie di migrazione dei dati nella sezione Valutare gli approcci di migrazione dei dati di "Migrazione a Google Cloud: trasferimento dei tuoi 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. Per mitigare questa sensibilità, vengono comunemente utilizzati proxy che possono eseguire il pre-caricamento dei dati o i livelli di memorizzazione nella cache.
- Elevato accoppiamento ad altre funzionalità: se due o più funzionalità sono altamente associate potrebbe essere necessario eseguirne la migrazione contemporaneamente. Sebbene questo approccio sia più semplice della migrazione di un'intera applicazione, potrebbe essere più difficile della 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 utilizzando l'integrazione integrata con le API di service mesh.
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, in quanto accedono alle interfacce dei due ambienti tramite un livello di bilanciamento del carico. Routing del traffico all'interno di mesh di servizi è trasparente per i client, quindi i clienti 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 il 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 in esecuzione in Compute Engine e quelli in esecuzione in 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, consulta Eseguire il deployment della migrazione con l'espansione del mesh Istio.
Passaggi successivi
- Scopri di più su GKE.
- Scopri di più su Istio.
- Per altre architetture di riferimento, diagrammi e best practice, visita il Centro architetture di Google Cloud.