- v1.12 (più recente)
- Versione 1.11
- Versione 1.10
- Elenco delle versioni supportate
- Versione 1.9
- Versione 1.8
- Versione 1.7
- Versione 1.6
- Versione 1.5
- Versione 1.4
- Versione 1.3
- Versione 1.2
- Versione 1.1
Versioni supportate:
Versioni non supportate:
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 installi 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 garantire a sviluppatori, partner e clienti un'esperienza coerente del programma API. |
Risolvi i problemi di sicurezza e conformità |
Se le tue considerazioni 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 di Apigee on-premise. Gestisci e controlla il runtime, sfruttando l'infrastruttura di conformità, governance e sicurezza esistente. |
Supporta la tua strategia multi-cloud |
Trovare il giusto equilibrio tra costi e prestazioni può portare a una strategia ibrida. Che tu stia semplicemente esplorando diversi cloud provider o che tu 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 in tutto il data center, Google Cloud o in entrambi gli ambienti. |
|
Per scoprire di più sulla modalità ibrida:
|
Per installare la soluzione ibrida:
|
Programmi API in un mondo ibrido
Apigee ibrida è 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 mostra la seguente immagine:
Come vedi, il lavoro 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 UI, API di gestione e analisi.
Piano runtime gestito dal cliente: un set di servizi di runtime containerizzati che hai configurato e gestito nel tuo cluster Kubernetes. Tutto il traffico API passa ed viene elaborato nel 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 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 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 cluster Kubernetes in esecuzione su una piattaforma Kubernetes supportata. Tutto il traffico API passa attraverso ed è 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 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 sezioni seguenti descrivono in modo più dettagliato ciascuno di questi servizi principali del piano di runtime.
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 dall'archiviazione locale. Configura un controller Istio Ingress per esporre i MP alle richieste provenienti dall'esterno del cluster.
Sincronizzatore
Il programma di sincronizzazione recupera i dati di configurazione di un ambiente API dal piano di gestione e li propaga all'interno del piano di runtime. Questi dati scaricati sono anche denominati 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, a cui i processori di messaggi 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 i dati archiviati localmente come configurazione. Se la connessione tra il piano di gestione e il piano di runtime viene interrotta, i servizi sul piano di runtime continuano a funzionare.
I dati di configurazione scaricati da Syncer includono:
- Bundle con proxy e deployment dei flussi condivisi
- Ganci per il flusso
- Informazioni sull'ambiente
- Risorse API condivise
- Definizioni di server di destinazione
- Impostazioni TLS
- Nomi delle mappe dei valori chiave (KVM)
- Maschere di 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 distribuiti 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 localizzazione di queste entità vicino ai servizi di elaborazione di runtime aiuta a supportare i requisiti di sicurezza e scalabilità elevata.
Il database di Cassandra archivia le informazioni sulle seguenti entità:
- Key Management System (KMS)
- Mappa chiave-valore (KVM)
- OAuth
- API Management for RunTime data (MART)
- Dati sulla monetizzazione
- Quote
- Cache di risposte
API di gestione per i dati di runtime (MART)
I dati che appartengono all'organizzazione e a cui si accede durante le chiamate API di runtime sono archiviati da Cassandra nel piano di runtime.
Questi dati includono:
- Configurazioni delle applicazioni
- Dati di Key Management System (KMS)
- Cache
- Mappe 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 i dati di runtime) elabora le chiamate API in base al datastore di runtime.
Questa sezione descrive il ruolo svolto da MART quando chiami le API Apigee per accedere al datastore di runtime.
| Cos'è MART | Per chiamare un'API Apigee, invia una richiesta autenticata al server di gestione (MS) sul piano di gestione. MS autentica e autorizza la richiesta, quindi la inoltra a MART sul piano di runtime. Allegato alla richiesta è presente 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à sulla richiesta. Ad esempio, se l'app fa parte di un prodotto API, MART garantisce che si tratti di una richiesta valida. Dopo aver stabilito che la richiesta è valida, MART la elabora. Cassandra archivia i dati di runtime elaborati da MART (dopotutto, è un datastore di runtime). MART potrebbe leggere i dati dalla Cassandra o aggiornarli, a seconda del tipo di richiesta. Come la maggior parte dei servizi ibridi, MART è stateless, ovvero non mantiene il proprio stato al runtime. |
| Cosa non è l'arte 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 Connect (l'account di servizio MART nella maggior parte delle installazioni). Non chiami direttamente MART. Inoltre, MART non riceve richieste proxy API; tali chiamate vengono gestite dal controller Ingress in runtime e vengono indirizzate ai processori di messaggi del tuo cluster. |
È bene sottolineare che sia MART sia i processori di messaggi hanno accesso allo stesso datastore di runtime (Cassandra), ossia come vengono condivisi dati come KMS, KVM e cache.
L'immagine seguente mostra il flusso di una chiamata API Apigee:
UDCA
L'agente universale per la raccolta dei dati (UDCA) è un servizio in esecuzione all'interno del pod di raccolta dati nel piano di runtime che estrae i dati di analisi, di debug e di deployment e li invia all'UAP.
Per ulteriori informazioni, consulta Debug, analisi e raccolta dei dati di 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 agli sviluppatori un'interfaccia utente per creare ed eseguire il deployment di proxy API, configurare criteri, creare prodotti API e creare app di sviluppo. Gli amministratori possono utilizzare l'interfaccia utente ibrida di Apigee per monitorare lo stato del deployment.
- API Apigee: fornisci un'interfaccia di pubblicità programmatica per la gestione della tua organizzazione e dei tuoi ambienti.
- Unified Analytics Platform (UAP): riceve ed elabora dati di analisi e di stato del deployment dal piano di runtime.
L'immagine seguente mostra i servizi principali eseguiti sul piano di gestione:
Informazioni sui servizi Google Cloud
La tabella seguente descrive i servizi Google Cloud principali che vengono utilizzati dalla piattaforma ibrida:
| Servizio Google Cloud | Descrizione |
|---|---|
| Identità | L'autenticazione dell'account utente utilizza account Google Cloud. L'autorizzazione utilizza gli account di servizio Google Cloud. |
| Ruoli | Access Management per il cloud ibrido utilizza il motore dei ruoli Google, IAM e supporta i ruoli Apigee predefiniti. |
| Gerarchia delle risorse | Le risorse sono organizzate in progetti Google Cloud (collegati a organizzazioni Apigee). |
| Suite operativa di Google Cloud | Fornisce l'analisi dei dati di logging e 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 offre i seguenti vantaggi:
- Maggiore agilità
- Poiché la distribuzione ibrida viene eseguita e eseguita 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 ibrida sono asincrone e non avvengono nell'ambito dell'elaborazione delle richieste dell'API client.
- Maggiore adozione dell'API
- Anche se è possibile elaborare le API interne utilizzando Apigee, la minore latenza ed efficienza che puoi ottenere con l'ibrido rende l'elaborazione delle API interne con ibrido un'opzione allettante. Parte di questa efficienza è dovuta al fatto che il gateway API viene eseguito on-premise, in prossimità dei tuoi servizi di backend. Inoltre, se utilizzi Apigee, puoi aumentarne l'adozione elaborando le API interne tramite ibrido.
- Maggiore controllo
- Molte aziende stanno attuando una strategia ibrida. La possibilità 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 su Google Cloud o nel tuo data center.
Passaggio successivo
Guarda il quadro generale: una panoramica del processo di installazione ibrida.