Apigee Hybrid è una piattaforma per lo sviluppo e la gestione di proxy API che offre 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 API in un unico posto |
Apigee hybrid ti aiuta a gestire le API interne ed esterne con Google Cloud. Grazie alla gestione unificata delle API, puoi fornire agli sviluppatori, ai partner e ai clienti un'esperienza coerente del programma relativo alle API. |
Risolvi i problemi di sicurezza e conformità |
Se le tue strategie di conformità e sicurezza richiedono il deployment on-premise per le tue applicazioni, con un gateway ibrido di livello aziendale potrai ospitare e gestire il piano di runtime Apigee hybrid nel tuo ambiente on-premise. Potrai gestire e controllare il runtime, sfruttando l'infrastruttura di conformità, governance e sicurezza esistente. |
Supportare la tua strategia multi-cloud |
La necessità di trovare un equilibrio tra costi e prestazioni può spingerti verso una strategia ibrida. Che tu stia solo esplorando diversi provider cloud o che abbia già scelto una strategia ibrida, la piattaforma di gestione delle API dovrebbe fornirti la flessibilità di cui hai bisogno. Ospita e gestisci gateway ibridi di livello aziendale nel tuo data center, in Google Cloud o in entrambi. |
|
Per scoprire di più su Hybrid:
|
Per installare hybrid:
|
Programmi API in un mondo ibrido
Apigee Hybrid è costituito da un piano di gestione gestito da Google e da un piano di runtime che installi su una piattaforma Kubernetes supportata. Entrambi i piani utilizzano i servizi Google Cloud Platform, come mostrato nell'immagine seguente:
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 insieme di servizi di runtime containerizzati che configuri e gestisci nel tuo cluster Kubernetes. Tutto il traffico API passa attraverso il piano di runtime e viene elaborato al suo interno.
Gestisci il runtime containerizzato sul tuo cluster Kubernetes per una maggiore agilità con implementazioni graduali, scalabilità automatica e gli altri vantaggi operativi dei container.
- Google Cloud: una suite di servizi cloud ospitati da Google.
Una cosa fondamentale da sapere sull'ibrido è che tutto il traffico API viene elaborato entro i 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 saperne di più, consulta 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 API passa attraverso il piano di runtime e viene elaborato al suo interno. Il runtime plane include i seguenti componenti principali:
Il piano di runtime viene eseguito in un cluster Kubernetes in esecuzione su una piattaforma Kubernetes supportata che gestisci.
La seguente immagine mostra i servizi principali eseguiti sul piano di runtime:
Per informazioni generali sui componenti di runtime, consulta le sezioni seguenti. Inoltre, consulta la panoramicaconfigurazione del servizioi di runtime.
Le sezioni seguenti descrivono in dettaglio ciascuno di questi servizi del piano di runtime principale.
processore di messaggi
I processori di messaggi (MP) ibridi forniscono l'elaborazione delle richieste API e l'esecuzione dei criteri sul piano di runtime. I processori di messaggi caricano tutti i proxy, le risorse, i server di destinazione, i certificati e i keystore di cui è stato eseguito il deployment dallo spazio di archiviazione locale. Configura un controller Ingress Istio per esporre i MP alle richieste provenienti dall'esterno del cluster.
Sincronizzatore
Synchronizer recupera i dati di configurazione di un ambiente API dal management plane e li propaga nel runtime plane. Questi dati scaricati vengono chiamati anche contratto e sono archiviati nel file system locale.
Synchronizer esegue periodicamente il polling del server di gestione per rilevare le modifiche e scarica una nuova configurazione ogni volta che vengono rilevate modifiche. I dati di configurazione vengono recuperati e archiviati localmente come un file JSON sul file system locale, a cui possono accedere i processori di messaggi.
I dati di configurazione scaricati consentono al piano di runtime di funzionare indipendentemente dal piano di gestione. Con il contratto, i Message Processor nel piano di runtime utilizzano i dati archiviati localmente come configurazione. Se la connessione tra il piano di gestione e il piano di runtime si interrompe, i servizi sul piano di runtime continuano a funzionare.
I dati di configurazione scaricati da Synchronizer includono:
- Deployment di bundle di proxy e flussi condivisi
- Hook di flusso
- Informazioni sull'ambiente
- Risorse API condivise
- Definizioni del server di destinazione
- Impostazioni TLS
- Nomi delle mappe di coppie chiave-valore (KVM)
- Maschere dei dati
Datastore Cassandra
Apache Cassandra è l'archivio dati 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 cluster Kubernetes. La posizione di queste entità vicino ai servizi di elaborazione runtime contribuisce a supportare i requisiti per la sicurezza e l'elevata scalabilità.
Il database Cassandra archivia informazioni sulle seguenti entità:
- Key Management System (KMS)
- Mappa di coppie chiave-valore (KVM)
- OAuth
- API di gestione per i dati di runtime (MART)
- Dati sulla monetizzazione
- Quote
- Cache delle risposte
API di gestione per i dati di runtime (MART)
I dati appartenenti alla tua organizzazione e a cui si accede durante le chiamate API di runtime vengono memorizzati da Cassandra nel piano di runtime.
Questi dati includono:
- Configurazioni dell'applicazione
- Dati di Key Management System (KMS)
- Cache
- Mappe di coppie 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 per rimuovere un ambiente, puoi utilizzare l'interfaccia utente ibrida Apigee o le API Apigee. Il server MART (Management API for Runtime data) elabora le chiamate API rispetto al datastore di runtime.
Questa sezione descrive il ruolo di MART quando chiami le API Apigee per accedere all'archivio dati di runtime.
| Che cos'è MART | Per chiamare un'API Apigee, invia una richiesta autenticata al Management Server (MS) sul piano di gestione. L'MS autentica e autorizza la richiesta, quindi la inoltra a MART sul piano di runtime. A questa richiesta è allegato un token che il microservizio ha generato 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 si assicura 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 datastore di runtime). MART potrebbe 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. |
| Che 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 (il account di servizio MART nella maggior parte delle installazioni). Non chiami direttamente MART. Inoltre, MART non riceve richieste di proxy API; queste chiamate vengono gestite dal controller Ingress di runtime e vengono indirizzate ai processori di messaggi del cluster. |
È importante sottolineare che sia 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 di analisi, debug e stato di deployment e li invia all'UAP.
Per ulteriori informazioni, vedi Raccolta dei dati di debug, analisi e stato di implementazione.
Informazioni sul management plane
Il management plane viene eseguito su Google Cloud. Include servizi amministrativi come:
- UI 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. Gli amministratori possono utilizzare l'interfaccia utente ibrida 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 lo stato di deployment dal runtime plane.
L'immagine seguente mostra i servizi principali eseguiti sul management plane:
Informazioni sui servizi Google Cloud
La tabella seguente descrive i principali servizi Google Cloud utilizzati dall'ibrido:
| Servizio Google Cloud | Descrizione |
|---|---|
| Identità | L'autenticazione dell'account utente utilizza gli account Google Cloud. L'autorizzazione utilizza service account Google Cloud. |
| Ruoli | La gestione dell'accesso per l'utilizzo ibrido 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). |
| Cloud Operations | Fornisce l'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/operatori di sistema |
|
|
| Sviluppatori |
|
|
Vantaggi
Apigee hybrid presenta i seguenti vantaggi:
- Maggiore agilità
- Poiché hybrid viene fornito ed eseguito in container, puoi ottenere implementazioni graduali, scalabilità automatica e altri vantaggi operativi di un sistema containerizzato.
- Latenza ridotta
- Tutta la comunicazione con il piano di gestione ibrido è asincrona e non avviene durante l'elaborazione delle richieste API client.
- Aumento dell'adozione delle API
- Sebbene sia possibile elaborare le API interne utilizzando Apigee, la latenza e l'efficienza ridotte che puoi ottenere con hybrid rendono l'elaborazione delle API interne con hybrid un'opzione interessante. Parte di questa efficienza è dovuta al fatto che il gateway API viene eseguito on-premise, in prossimità dei servizi di backend. Inoltre, se utilizzi Apigee, puoi aumentare l'adozione di Apigee elaborando le API interne tramite Apigee hybrid.
- Maggiore controllo
- Molte aziende stanno adottando una strategia ibrida. La possibilità di gestire i runtime API di cui è stato eseguito il deployment in data center privati è un requisito fondamentale per le grandi aziende. Al momento, il piano di runtime ibrido può essere implementato su Google Cloud o nel tuo data center.
Passaggio successivo
Consulta il quadro generale, una panoramica della procedura di installazione ibrida.