Apigee hybrid è una piattaforma per lo sviluppo e la gestione di proxy API che presentano un modello di deployment ibrido. Il modello ibrido include un piano di gestione ospitato da Apigee nel cloud e un piano di runtime che puoi installare e gestire 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 del programma API. |
Risolvi i problemi di sicurezza e conformità |
Se le tue considerazioni in materia di conformità e sicurezza rendono il deployment on-premise indispensabile per le tue applicazioni, con un gateway ibrido di livello enterprise, puoi ospitare e gestire il piano di runtime ibrido Apigee on-premise. Puoi gestire e controllare il runtime e sfruttare l'infrastruttura di conformità, governance e sicurezza esistente. |
Supporta la tua strategia multi-cloud |
Trovare il giusto equilibrio tra costi e rendimento può portare a una strategia ibrida. Che tu stia semplicemente esplorando diversi cloud provider o che abbia già scelto una strategia ibrida, la tua piattaforma di gestione delle API dovrebbe darti la flessibilità di cui hai bisogno. Host e gestisci gateway ibridi di livello enterprise in tutto il data center, Google Cloud o entrambi. |
|
Per scoprire di più sull'ibrido:
|
Per installare un dispositivo ibrido:
|
Programmi API in un mondo ibrido
Apigee hybrid è composta 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 mostra la seguente immagine:
Come vedi, "ibrido" è costituito dai seguenti componenti principali:
- Piano di gestione gestito da Apigee: un insieme di servizi ospitati nel cloud e gestiti da Google. Questi servizi includono la UI, l'API di gestione e l'analisi.
Piano gestito runtime del cliente: un set di servizi di runtime containerizzati che hai configurato e mantenuto nel tuo cluster Kubernetes. Tutto il traffico API passa ed viene 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 ospitata da Google.
Una cosa fondamentale da sapere sull'ibrido è che tutto il traffico API viene elaborato all'interno dei confini della tua rete e sotto il tuo controllo, mentre i servizi di gestione, come l'interfaccia utente e l'analisi delle API, vengono eseguiti nel cloud e sono gestiti da Google. Per ulteriori informazioni, consulta la sezione Dove sono archiviati i tuoi 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 hai configurato e gestito nel tuo cluster Kubernetes in esecuzione su una piattaforma Kubernetes supportata. Tutto il traffico API passa ed 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 che gestisci.
L'immagine seguente mostra i servizi principali che vengono eseguiti sul piano di runtime:
Per informazioni generali sui componenti di runtime, consulta le sezioni seguenti. Inoltre, consulta la panoramica della configurazione del servizio runtime.
Le seguenti sezioni descrivono in modo più dettagliato ciascuno di questi servizi del piano di runtime principale.
processore di messaggi
I processori di messaggi ibridi (MP) offrono elaborazione delle richieste API ed 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 distribuiti dalla memoria locale. Configura un controller Istio Ingress per esporre gli MP alle richieste provenienti dall'esterno del cluster.
Sincronizzatore
Il Syncr recupera i dati di configurazione relativi a un ambiente API dal piano di gestione e li propaga al piano di runtime. Questi dati scaricati sono detti anche contratti 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 gli elaboratori dei messaggi possono accedervi.
I dati di configurazione scaricati consentono al piano di runtime di funzionare indipendentemente dal piano di gestione. Con il contratto, gli elaboratori di messaggi sul piano di runtime utilizzano i dati archiviati localmente come configurazione. Se la connessione tra il piano di gestione e quello di runtime viene interrotta, i servizi sul piano di runtime continuano a funzionare.
I dati di configurazione scaricati dal Syncr includono:
- Bundle proxy e deployment di flussi condivisi
- Ganci per flusso
- Informazioni sull'ambiente
- Risorse API condivise
- Definizioni di server di destinazione
- Impostazioni TLS
- Nomi di KVM (Key Value Map)
- Maschere 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 persistenza dei dati sul piano di runtime. Esegui il deployment del database Cassandra come pool di nodi StatefulSet sul tuo cluster Kubernetes. La localizzazione di queste entità vicino ai servizi di elaborazione in runtime consente di supportare i requisiti di sicurezza e di alta scalabilità.
Il database di Cassandra archivia le informazioni sulle seguenti entità:
- Sistema di gestione delle chiavi (KMS)
- Mappa chiave-valore (KVM)
- OAuth
- API di gestione per i dati RunTime (MART)
- Dati sulla monetizzazione
- Quote
- Cache risposta
API di gestione per dati di runtime (MART)
I dati che appartengono alla tua organizzazione e a cui si accede durante le chiamate all'API di runtime sono archiviati da Cassandra nel piano di runtime.
Questi dati includono:
- Configurazioni delle applicazioni
- Dati di Key Management System (KMS)
- Cache
- Mappa chiave-valore (KVM)
- Prodotti basati su API
- App per sviluppatori
Per accedere ai dati e aggiornarli, ad esempio per aggiungere una nuova KVM o per rimuovere un ambiente, puoi utilizzare l'interfaccia utente ibrida di Apigee o le API Apigee. Il server MART (API di gestione per dati di runtime) elabora le chiamate API rispetto al datastore di runtime.
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, invia una richiesta autenticata al server di gestione (MS) sul piano di gestione. Il file MS autentica e autorizza la richiesta, quindi la inoltra a MART sul piano di runtime. A questa richiesta è allegato un token generato dal sistema MS utilizzando un account di servizio preconfigurato. MART riceve la richiesta, la autentica e la autorizza, quindi esegue la convalida dell'attività commerciale. 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 (dopotutto, è un datastore di runtime). MART potrebbe leggere i dati da Cassandra oppure aggiornarli, a seconda del tipo di richiesta. Come per la maggior parte dei servizi ibridi, MART è stateless: non viene mantenuto il proprio stato in fase di esecuzione. |
| Che cos'è MART | Il piano di gestione comunica con MART tramite l'agente Apigee Connect, che utilizza un account di servizio con il ruolo Agente di connessione Apigee (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 Ingress in runtime e vengono indirizzate ai processori di messaggi del tuo cluster. |
È bene sottolineare che sia MART sia gli elaboratori di messaggi hanno accesso allo stesso datastore di runtime (Cassandra), che permette la condivisione di 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 di analisi, debug e stato del deployment e li invia all'UAP.
Per ulteriori informazioni, consulta Debug, analisi e raccolta dei dati dello stato del deployment.
Informazioni sul piano di gestione
Il piano di gestione viene eseguito su Google Cloud. Include servizi amministrativi come:
- UI ibrida Apigee:fornisce un'interfaccia utente 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 l'UI ibrida Apigee per monitorare lo stato del deployment.
- API Apigee: fornisci un'interfaccia programmatica per la gestione della tua organizzazione e degli ambienti.
- Unified Analytics Platform (UAP): riceve ed elabora i dati di analisi e di stato del deployment dal piano di runtime.
L'immagine seguente mostra i servizi principali che vengono eseguiti sul piano di gestione:
Informazioni sui servizi Google Cloud
La seguente tabella descrive i servizi Google Cloud principali che sfruttano in modo ibrido:
| Servizio Google Cloud | Descrizione |
|---|---|
| Identità | L'autenticazione degli account utente utilizza un account Google Cloud. L'autorizzazione utilizza gli account di servizio Google Cloud. |
| Ruoli | Access Management for hybrid 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 il logging e l'analisi dei dati di metrica. |
Tipi di utenti
Apigee ha identificato i seguenti tipi principali di utenti ibridi:
| Ruolo | Responsabilità/attività tipiche | Aree di interesse |
|---|---|---|
| Amministratori/operatori di sistema |
|
|
| Sviluppatori |
|
|
Vantaggi
Apigee hybrid ha i seguenti vantaggi:
- Maggiore agilità
- Dato che l'ibrido viene fornito ed eseguito nei 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 ibrida sono asincrone e non avvengono nell'ambito dell'elaborazione delle richieste API del client.
- Maggiore adozione delle API
- Sebbene sia possibile elaborare le API interne utilizzando Apigee, la ridotta latenza ed efficienza che puoi ottenere con l'ibrido rende l'elaborazione delle API interne con un'opzione attraente. Parte di questa efficienza è ottenuta perché il gateway API viene eseguito on-premise, in prossimità dei tuoi servizi di backend. Inoltre, se utilizzi Apigee, puoi aumentare l'adozione di Apigee elaborando le API interne tramite ibrido.
- Maggiore controllo
- Molte aziende stanno intraprendendo una strategia ibrida. La capacità di gestire i runtime delle API di cui è stato eseguito il deployment nei 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.