Apigee hybrid è una piattaforma per lo sviluppo e la gestione dei proxy API che utilizza un modello di deployment ibrido. Il modello ibrido include un piano di gestione ospitato da Apigee nel cloud e un piano di runtime che installerai e gestisci su una delle piattaforme Kubernetes supportate.
Gestisci tutte le tue API in un unico posto |
Apigee hybrid ti aiuta a gestire le API interne ed esterne con Google Cloud. Con la gestione unificata delle API, puoi fornire a sviluppatori, partner e clienti un'esperienza coerente con il programma API. |
Risolvi i problemi di sicurezza e conformità |
Se le tue considerazioni di conformità e sicurezza rendono il deployment on-premise un must per le tue applicazioni, con un gateway ibrido di livello aziendale, puoi ospitare e gestire il piano di runtime ibrido Apigee on-premise. Puoi gestire e controllare il runtime, sfruttando l'infrastruttura esistente per conformità, governance e sicurezza. |
Supporta la tua strategia multi-cloud |
Trovare il giusto equilibrio tra costo e rendimento può portarti a una strategia ibrida. Che tu stia solo esplorando diversi cloud provider o abbia già scelto una strategia ibrida, la tua piattaforma di gestione delle API dovrebbe darti la flessibilità di cui hai bisogno. Ospita e gestisci gateway ibridi di livello enterprise nel tuo data center, in Google Cloud o in entrambi. |
|
Per scoprire di più sul modello ibrido:
|
Per installare un modello ibrido:
|
Programmi API in un mondo ibrido
Apigee hybrid è costituito da un piano di gestione gestito da Google e un piano di runtime che installerai su una piattaforma Kubernetes supportata. Entrambi i piani utilizzano i servizi della piattaforma Google Cloud, come mostrato nell'immagine seguente:
Come puoi vedere, il modello ibrido è costituito dai seguenti componenti principali:
- Piano di gestione Apigee-run: un insieme di servizi ospitati nel cloud e gestiti da Google. Questi servizi includono UI, API di gestione e analisi.
Piano di runtime gestito dal cliente: un set di servizi di runtime containerizzati che configuri e gestisci nel tuo cluster Kubernetes. Tutto il traffico API passa e viene elaborato all'interno del piano di runtime.
Puoi gestire il runtime containerizzato sul tuo cluster Kubernetes per una maggiore agilità con implementazioni graduali, scalabilità automatica e altri vantaggi operativi dei container.
- Google Cloud: una suite di servizi cloud ospitata da Google.
Una cosa chiave da sapere sugli ambienti ibridi è che tutto il traffico delle API viene elaborato entro i confini della tua rete e sotto il tuo controllo, mentre i servizi di gestione come l'analisi di UI e API vengono eseguiti nel cloud e sono gestiti da Google. Per ulteriori informazioni, vedi Dove vengono archiviati i dati?
Il seguente video fornisce un approfondimento sull'architettura ibrida:
Informazioni sul piano di runtime
Il piano di runtime è un insieme di servizi di runtime containerizzati che puoi configurare e gestire nel tuo cluster Kubernetes in esecuzione su una piattaforma Kubernetes supportata. Tutto il traffico delle API passa e viene elaborato all'interno del piano di runtime. Il piano di runtime include i seguenti componenti principali:
Il piano di runtime viene eseguito in un cluster Kubernetes in esecuzione su una piattaforma Kubernetes supportata da te gestita.
L'immagine seguente mostra i servizi principali in esecuzione sul piano di runtime:
Per informazioni generali sui componenti di runtime, consulta le sezioni seguenti. Inoltre, consulta Panoramica della configurazione del servizio di runtime.
Le sezioni seguenti descrivono in maggiore dettaglio ciascuno di questi servizi del piano di runtime principale.
processore di messaggi
I processori di messaggi ibridi (MP) forniscono l'elaborazione delle richieste API e l'esecuzione dei criteri sul piano di runtime. I MP caricano tutti i proxy, le risorse, i server di destinazione, i certificati e gli archivi chiavi di cui è stato eseguito il deployment dallo spazio di archiviazione locale. Puoi configurare un controller Istio Ingress per esporre gli MP alle richieste che provengono dall'esterno del cluster.
Sincronizzatore
Il sincronizzatore recupera i dati di configurazione relativi a un ambiente API dal piano di gestione e li propaga al piano di runtime. I dati scaricati sono chiamati anche contratto e vengono archiviati nel file system locale.
Il programma di sincronizzazione esegue periodicamente il polling del server di gestione per rilevare eventuali modifiche e scarica una nuova configurazione ogni volta che vengono rilevate modifiche. I dati di configurazione vengono recuperati e archiviati localmente come file JSON nel file system locale, dove i processori di messaggi possono accedervi.
I dati di configurazione scaricati consentono al piano di runtime di funzionare in modo indipendente dal piano di gestione. Con il contratto, i processori di messaggi sul piano di runtime utilizzano i dati archiviati localmente come configurazione. Se la connessione tra il piano di gestione e di runtime si interrompe, i servizi sul piano di runtime continuano a funzionare.
I dati di configurazione scaricati dal sincronizzatore includono:
- Bundle proxy e deployment di flussi condivisi
- Hook di flusso
- Informazioni sull'ambiente
- Risorse API condivise
- Definizioni dei server di destinazione
- Impostazioni TLS
- Nomi delle mappe KVM (Key Value Map)
- Mascherine dei dati
Datastore Cassandra
Apache Cassandra è il datastore di runtime che fornisce la persistenza dei dati per il piano di runtime.
Cassandra è un sistema di dati distribuito che fornisce la persistenza dei dati sul piano di runtime. Esegui il deployment del database Cassandra come pool di nodi StatefulSet sul tuo cluster Kubernetes. La posizione di queste entità vicino ai servizi di elaborazione del runtime consente di supportare i requisiti di sicurezza e di elevata scalabilità.
Il database Cassandra archivia informazioni sulle seguenti entità:
- Sistema di gestione delle chiavi (KMS)
- Mappa valori chiave (KVM)
- Cache delle risposte
- OAuth
- Quote
API di gestione per i dati di runtime (MART)
I dati che appartengono alla tua organizzazione a cui si accede durante le chiamate API di runtime vengono archiviati da Cassandra nel piano di runtime.
Questi dati includono:
- Configurazioni dell'applicazione
- Dati del sistema di gestione delle chiavi (KMS)
- Cache
- Mappe chiave-valore (KVM)
- Prodotti basati su API
- App per sviluppatori
Per accedere a questi dati e aggiornarli, ad esempio per aggiungere una nuova KVM o rimuovere un ambiente, puoi utilizzare la UI ibrida Apigee o le API Apigee. Il server MART (API di gestione per i dati di runtime) elabora le chiamate API rispetto all'archivio dati di runtime.
Questa sezione descrive il ruolo che MART svolge quando chiami le API Apigee per accedere al datastore di runtime.
| Che cos'è MART | Per chiamare un'API Apigee, devi inviare una richiesta autenticata al server di gestione (MS) sul piano di gestione. Il servizio Microsoft autentica e autorizza la richiesta, quindi la inoltra a MART sul piano di runtime. Alla richiesta è associato un token generato dal server Microsoft utilizzando un account di servizio preconfigurato. MART riceve la richiesta, la autentica e la autorizza e quindi esegue la convalida aziendale. Ad esempio, se l'app fa parte di un prodotto API, MART garantisce che si tratti di una richiesta valida. Dopo aver stabilito che una richiesta è valida, MART la elabora. Cassandra archivia i dati di runtime elaborati da MART (è, dopo tutto, un data di runtime di runtime). MART può leggere i dati da Cassandra o aggiornarli, a seconda del tipo di richiesta. Come la maggior parte dei servizi ibridi, MART è stateless: non mantiene il proprio stato in fase di runtime. |
| Cosa non è MART | Il piano di gestione comunica con MART tramite l'agente Apigee Connect, che utilizza un account di servizio con il ruolo Agente Apigee Connect (l'account di servizio MART nella maggior parte delle installazioni). Non chiami direttamente MART. Inoltre, MART non riceve richieste proxy API; queste chiamate vengono gestite dal controller in entrata Runtime e vengono instradate ai processori di messaggi del cluster. |
Vale la pena notare che sia i processori MART sia i processori di messaggi hanno accesso allo stesso datastore di runtime (Cassandra), che è il modo in cui vengono condivisi dati come KMS, KVM e cache.
L'immagine seguente mostra il flusso di una chiamata API Apigee:
UDCA
L'agente di raccolta dati universale (UDCA) è un servizio in esecuzione all'interno del pod di raccolta dati nel piano di runtime che estrae i dati sullo stato di analisi, debug e deployment e li invia alla campagna universale per app.
Per ulteriori informazioni, consulta Raccolta di dati sullo stato di debug, analisi e deployment.
Informazioni sul piano di gestione
Il piano di gestione viene eseguito su Google Cloud. Include servizi amministrativi come:
- UI ibrida Apigee: fornisce una UI che consente agli sviluppatori di creare ed eseguire il deployment di proxy API, configurare criteri, creare prodotti API e creare app per sviluppatori. Gli amministratori possono utilizzare la UI ibrida di Apigee per monitorare lo stato del deployment.
- API Apigee:forniscono un'interfaccia programmatica per la gestione della tua organizzazione e dei tuoi ambienti.
- Unified Analytics Platform (UAP): riceve ed elabora i dati di analisi e sullo stato del deployment dal piano di runtime.
L'immagine seguente mostra i servizi principali in esecuzione sul piano di gestione:
Informazioni sui servizi Google Cloud
La tabella seguente descrive i servizi principali di Google Cloud sfruttati da ibrido:
| Servizio Google Cloud | Descrizione |
|---|---|
| Identità | L'autenticazione dell'account utente utilizza account Google Cloud. L'autorizzazione utilizza account di servizio Google Cloud. |
| Ruoli | La gestione degli accessi per ambienti ibridi utilizza il motore dei ruoli di Google, IAM e supporta i ruoli Apigee predefiniti. |
| Gerarchia delle risorse | Le risorse sono organizzate in progetti Google Cloud (collegati alle organizzazioni Apigee). |
| Operazioni di Google Cloud | Fornisce analisi dei dati di logging e delle metriche. |
Tipi di utenti
Apigee ha identificato i seguenti tipi principali di utenti ibridi:
| Ruolo | Responsabilità/attività tipiche | Aree di interesse |
|---|---|---|
| Amministratori di sistema/operatori |
|
|
| Sviluppatori |
|
|
Vantaggi
Apigee hybrid offre i seguenti vantaggi:
- Maggiore agilità
- Poiché il modello ibrido viene distribuito ed eseguito in container, puoi ottenere implementazioni graduali, scalabilità automatica e altri vantaggi operativi di un sistema containerizzato.
- Latenza ridotta
- Tutte le comunicazioni con il piano di gestione ibrido sono asincrone e non avvengono nell'ambito dell'elaborazione delle richieste API del client.
- Maggiore adozione dell'API
- Sebbene sia possibile elaborare le API interne con Apigee, la latenza e l'efficienza ridotte che puoi ottenere con il modello ibrido rendono l'elaborazione delle API interne con approccio ibrido un'opzione allettante. Parte di questa efficienza è ottenuta perché il gateway API viene eseguito on-premise, in prossimità dei tuoi servizi di backend. Inoltre, se usi Apigee, puoi aumentare l'adozione di Apigee elaborando le API interne tramite ibride.
- Maggiore controllo
- Molte aziende stanno adottando una strategia ibrida. La capacità di gestire i runtime delle API di cui è stato eseguito il deployment in data center privati è un requisito chiave per le grandi aziende. Attualmente, è possibile eseguire il deployment del piano di runtime ibrido in Google Cloud o nel tuo data center.
Passaggio successivo
Guarda il quadro generale: una panoramica del processo di installazione ibrida.