Apigee Hybrid è una piattaforma per lo sviluppo e la gestione di proxy API che presenta un modello di deployment ibrido. Il modello ibrido include un piano di gestione ospitato da Apigee nel cloud e un piano di runtime che installi e gestirli 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 ai tuoi sviluppatori, partner ai clienti un'esperienza coerente con il programma API. |
Risolvi i problemi di sicurezza e conformità |
Se le considerazioni sulla conformità e sulla sicurezza rendono il deployment on-premise un must le tue applicazioni, con un gateway ibrido di livello enterprise, puoi ospitare e gestire Piano di runtime ibrido Apigee on-premise. Puoi gestire e controllare il runtime, sfruttando l'infrastruttura di conformità, governance e sicurezza esistente. |
Sostieni la tua strategia multi-cloud |
La necessità di trovare un equilibrio tra costi e prestazioni può spingerti verso una strategia ibrida. Sia che tu stia solo esplorando diversi cloud provider o che tu abbia già scelto un 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ù sull'approccio ibrido:
|
Per installare la versione ibrida:
|
Programmi API in un mondo ibrido
Apigee Hybrid è costituito da un piano di gestione gestito da Google e da un piano di runtime che puoi installare su una piattaforma Kubernetes supportata. Entrambi i piani utilizzano i servizi Google Cloud Platform, come mostrato nella seguente immagine:
Come puoi vedere, l'ibrido è costituito dai seguenti componenti principali:
- Piano di gestione eseguito da Apigee: un insieme di servizi ospitati nel cloud e gestiti da Google. Questi servizi includono l'interfaccia utente, l'API di gestione e l'analisi.
Piano di runtime gestito dal cliente: un di servizi di runtime containerizzati che configuri e gestisci nel tuo ambiente Kubernetes in un cluster Kubernetes. Tutto il traffico API passa ed è elaborato all'interno del piano di runtime.
Gestisci 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 ospitati da Google.
Una cosa fondamentale da sapere sugli ambienti ibridi è che tutto il traffico delle API viene elaborato entro i limiti del della rete e sotto il tuo controllo, mentre i servizi di gestione come l'interfaccia utente e l'analisi delle API eseguono nel cloud e sono gestiti da Google. Per ulteriori informazioni, vedi Dove vengono archiviati i tuoi dati?
Il seguente video fornisce un'analisi approfondita dell'architettura ibrida:
Informazioni sul piano di runtime
Il piano di runtime è un insieme di servizi di runtime containerizzati che configuri e gestisci nel tuo cluster Kubernetes in esecuzione su una piattaforma Kubernetes supportata. Tutto il traffico dell'API passa attraverso e viene elaborato all'interno del runtime aereo. Il piano di runtime include i seguenti componenti principali:
Il piano di runtime viene eseguito in un cluster Kubernetes in esecuzione su piattaforma Kubernetes supportata da te gestita.
L'immagine seguente mostra i servizi principali che vengono eseguiti nel piano di runtime:
Per informazioni generali sui componenti di runtime, consulta le sezioni seguenti. Inoltre, consulta la Panoramica della configurazione dei servizi 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 nel piano di runtime. I file MP caricano tutti i proxy, le risorse, i server di destinazione, i certificati gli archivi chiavi dallo spazio di archiviazione locale. Configuri un gateway in entrata Apigee per esporre gli MP ai che provengono dall'esterno del cluster.
Sincronizzatore
Il sincronizzatore recupera i dati di configurazione relativi a un ambiente API dal piano di gestione e lo propaga al piano di runtime. Questi 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 cambia e scarica una nuova configurazione ogni volta che vengono rilevato. I dati di configurazione vengono recuperati e archiviati localmente come file JSON nel file system locale, dove i Message Processor possono accedervi.
I dati di configurazione scaricati consentono al piano di runtime di funzionare indipendentemente dal piano di gestione. Con il contratto, I processori di messaggi sul piano di runtime utilizzano e archiviare i dati come configurazione. Se la connessione tra di gestione e runtime smette di funzionare, i servizi continuano a funzionare.
I dati di configurazione scaricati dal Sincronizzatore includono:
- Pacchetti di proxy e deployment di flussi condivisi
- Hook di flusso
- Informazioni sull'ambiente
- Risorse API condivise
- Definizioni del server di destinazione
- Impostazioni TLS
- Nomi delle mappe KVM (Key Value Map)
- Maschere di dati
Datastore Cassandra
Apache Cassandra è il data store di runtime che fornisce la persistenza dei dati per il piano di runtime.
Cassandra è un sistema di dati distribuito che garantisce la persistenza dei dati nel 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 per garantire sicurezza e un'elevata scalabilità.
Il database Cassandra archivia informazioni sulle seguenti entità:
- Sistema di gestione delle chiavi (KMS)
- Mappa valori chiave (KVM)
- OAuth
- API di gestione per i dati RunTime (MART)
- Dati sulla monetizzazione
- Quote
- Cache delle risposte
API di gestione per i dati di runtime (MART)
I dati che appartengono all'organizzazione a cui si accede durante le chiamate API di runtime e archiviato da Cassandra nel piano di runtime.
Questi dati includono:
- Configurazioni delle applicazioni
- Dati del sistema di gestione delle chiavi (KMS)
- Cache
- Mappe chiave-valore (KVM)
- Prodotti basati su API
- App per sviluppatori
Per accedere e aggiornare questi dati, ad esempio per aggiungere un nuovo KVM o rimuovere un ambiente, puoi utilizzare l'interfaccia utente ibrida di Apigee o le API Apigee. MART (API di gestione per i dati di runtime) elabora le chiamate API rispetto al runtime datastore.
Questa sezione descrive il ruolo svolto da MART 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 server Microsoft autentica e autorizza la richiesta e poi inoltra la richiesta a MART sul piano di runtime. Alla richiesta è associato un token generato da MS utilizzando un account di servizio preconfigurato. MART riceve la richiesta, la autentica e la autorizza, quindi esegue la convalida dell'attività. Ad esempio, se l'app fa parte di un prodotto API, MART garantisce che si tratti di un una richiesta valida). Dopo aver stabilito che una richiesta è valida, MART la elabora. Cassandra archivia i dati di runtime elaborati da MART (dopo tutto, datastore di runtime). MART potrebbe leggere i dati di Cassandra o aggiornarsi dei dati, a seconda del tipo di richiesta. Come la maggior parte dei servizi ibridi, MART è senza stato: 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 di Google). Non chiami direttamente MART. Inoltre, MART non riceve richieste proxy API; queste chiamate vengono gestite Controller in entrata runtime e vengono instradati al tuo fino ai processori di messaggi del cluster. |
Vale la pena notare che sia i processori MART che i processori di messaggi hanno accesso lo stesso datastore di runtime (Cassandra), che è il modo in cui vengono condiviso.
L'immagine seguente mostra il flusso di una chiamata all'API Apigee:
UDCA
L'Universal Data Collection Agent (UDCA) è un servizio in esecuzione nel pod di raccolta dei dati nel piano di runtime che estrae i dati di analisi, debug e stato di implementazione e li invia all'UAP.
Per ulteriori informazioni, consulta la sezione relativa alla raccolta dei dati di debug, analisi e stato di implementazione.
Informazioni sul piano di gestione
Il piano di gestione viene eseguito su Google Cloud. Sono inclusi servizi amministrativi come:
- Interfaccia utente di Apigee hybrid: fornisce un'interfaccia utente per consentire agli sviluppatori di creare ed eseguire il deployment di proxy API, configurare criteri, creare prodotti API e creare app per sviluppatori. Amministratori puoi usare 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 analisi e i dati sullo stato del deployment dal piano di runtime.
L'immagine seguente mostra i servizi principali in esecuzione sul piano di gestione:
Dati del piano di gestione e residenza dei dati
Se l'installazione utilizza la residente dei dati, puoi specificare la regione in cui sono archiviati i dati. Consulta Utilizzare la residenza dei dati con Apigee hybrid.
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 gli account Google Cloud. L'autorizzazione utilizza gli account di servizio Google Cloud. |
| Ruoli | La gestione dell'accesso per l'architettura ibrida 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). |
| Suite operativa di Google Cloud | Fornisce analisi dei dati di logging e delle metriche. |
Tipi di utenti
Apigee ha identificato i seguenti tipi principali di utenti ibride:
| 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 realizzare implementazioni graduali, scalabilità automatica e altri vantaggi operativi di un sistema containerizzato.
- Latenza ridotta
- Tutte le comunicazioni con il piano di gestione ibrida sono asincrone e non avvengono nell'ambito dell'elaborazione delle richieste dell'API client.
- Maggiore adozione delle API
- Sebbene sia possibile elaborare le API interne Con Apigee, la latenza e l'efficienza ridotte che si possono ottenere con il cloud ibrido rendono l'elaborazione interna le API con approccio ibrido sono un'opzione interessante. Parte di questa efficienza è ottenuta perché il gateway API viene eseguito on-premise, vicino ai tuoi servizi di backend. Inoltre, se usi Apigee, puoi aumentare l'adozione di Apigee e l'elaborazione delle API interne tramite un approccio ibrido.
- Maggiore controllo
- Molte aziende stanno adottando una strategia ibrida. La possibilità di gestisci i runtime API di cui è stato eseguito il deployment in privato data center è un requisito fondamentale per le grandi imprese. Attualmente, il piano di runtime ibrido può essere implementato su Google Cloud o nel tuo data center.
Passaggio successivo
Guarda il quadro generale: una panoramica dell'installazione ibrida. e il processo di sviluppo.