Apigee hybrid ti consente di gestire le API on-premise, su Google Cloud o in una combinazione di entrambi:
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 di programma delle API coerente. |
Risolvi i problemi di sicurezza e conformità |
Se le tue esigenze di conformità e sicurezza rendono il deployment on-premise obbligatorio per le tue applicazioni, con un gateway ibrido di livello aziendale, puoi ospitare e gestire il piano di runtime ibrido Apigee on-premise. Gestisci e controlli il runtime, sfruttando la tua 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. Sia che tu stia esplorando diversi cloud provider o che tu abbia già scelto una strategia ibrida, la tua piattaforma di gestione delle API dovrebbe offrirti la flessibilità necessaria. Ospita e gestisci gateway ibridi di livello aziendale nel tuo data center, in Google Cloud o in entrambi gli ambienti. |
|
Se vuoi scoprire di più su un approccio ibrido:
|
Se sei pronto all'installazione 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 in Kubernetes on-premise o su Google Cloud. Entrambi i piani utilizzano i servizi Google Cloud Platform, come mostra la seguente immagine:
Come puoi vedere, l'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 l'interfaccia utente, l'API di gestione e l'analisi.
Piano di runtime gestito dal cliente: un insieme di servizi di runtime containerizzati che hai configurato e gestito nel tuo cluster Kubernetes. Tutto il traffico API passa e 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 su ibrido è che tutto il traffico API viene elaborato all'interno della 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 maggiori 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. Tutto il traffico 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 di tua proprietà e 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 file 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. Configura un controller Istio Ingress per esporre i MP alle richieste provenienti dall'esterno del cluster.
Sincronizzatore
Lo strumento di sincronizzazione recupera i dati di configurazione relativi a un ambiente API dal piano di gestione e li propaga sul piano di runtime. Questi dati scaricati sono anche denominati contratti e vengono memorizzati nel file system locale.
Il Sincronizzatore 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 dei 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 il piano di runtime viene interrotta, i servizi sul piano di runtime continuano a funzionare.
I dati di configurazione scaricati dallo strumento di sincronizzazione includono:
- Bundle proxy e deployment dei flussi condivisi
- Hook flusso
- Informazioni sull'ambiente
- Risorse API condivise
- Definizioni dei server di destinazione
- Impostazioni TLS
- Nomi delle mappe di coppie chiave-valore (KVM)
- Maschere dati
Datastore Datastore
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 localizzazione di queste entità vicino ai servizi di elaborazione di runtime consente di supportare i requisiti di sicurezza e di elevata scalabilità.
Il database di Cassandra archivia le informazioni sulle seguenti entità:
- Key Management System (KMS)
- Chiave valore mappa (KVM)
- Cache delle risposte
- OAuth
- Quote
API di gestione per dati di runtime (MART)
I dati appartenenti alla tua organizzazione e a cui si accede durante le chiamate API runtime sono archiviati da Cassandra nel piano di runtime.
Questi dati includono:
- Configurazioni dell'applicazione
- Dati del sistema di gestione delle chiavi (KMS)
- Cache
- Coppie chiave-valore (KVM)
- Prodotti API
- App per sviluppatori
Per accedere ai dati e aggiornarli, ad esempio per aggiungere una nuova KVM o 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 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 Management Server (MS) sul piano di gestione. MS autentica e autorizza la richiesta, quindi inoltra la richiesta a MART sul piano di runtime. In allegato a tale richiesta è presente un token che MS ha generato utilizzando un account di servizio preconfigurato. MART riceve la richiesta, la autentica e la autorizza, quindi esegue la convalida dell'attività commerciale sulla richiesta. Ad esempio, se l'app fa parte di un prodotto API, MART garantisce che sia una richiesta valida. Dopo aver stabilito che una richiesta è valida, MART la elabora. Cassandra archivia i dati di runtime elaborati da MART (dopo tutto si tratta di 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: non conserva il proprio stato in fase di runtime. |
| Che cos'è MART | Anche se MART espone una porta al cloud pubblico, non chiami direttamente MART. La porta deve essere esposta in modo che MART possa ricevere chiamate dal server tramite un account di servizio. Inoltre, MART non riceve le chiamate di runtime dai tuoi clienti ai rispettivi proxy API; queste chiamate vengono gestite dal controller in entrata e vengono instradate ai processori di messaggi del cluster. |
È bene sottolineare che sia MART che i processori di messaggi hanno accesso allo stesso datastore di runtime (Cassandra), che è il modo in cui vengono condivisi i 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 del piano di runtime che estrae i dati di analisi, debug e stato del deployment e li invia all'UAP.
Per ulteriori informazioni, consulta la sezione 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:
- Interfaccia utente ibrida di Apigee: 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 di 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 dello 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
Nella tabella seguente vengono descritti i servizi Google Cloud principali utilizzati da un ambiente ibrido:
| Servizio Google Cloud | Descrizione |
|---|---|
| Identità | L'autenticazione degli account utente utilizza account Google Cloud. L'autorizzazione utilizza gli account di servizio Google Cloud. |
| Ruoli | La gestione degli accessi per l'ibrido utilizza il motore dei ruoli di Google, IAM e supporta i ruoli predefiniti di Apigee. |
| Gerarchia delle risorse | Le risorse sono organizzate in progetti Google Cloud (collegati alle organizzazioni Apigee). |
| Stackdriver | 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é 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 ibrida sono asincrone e non avvengono nell'ambito delle richieste dell'API client di elaborazione.
- Maggiore adozione di API
- Sebbene sia 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 un'opzione ibrida 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 ibrido.
- Maggiore controllo
- Molte aziende stanno adottando una strategia ibrida. La possibilità di gestire i runtime 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.