Identificare il servizio di messaggistica più appropriato

Scopri le considerazioni relative alla selezione di un servizio di messaggistica e utilizza quindi la tabella della matrice decisionale per esaminare le diverse opzioni e limitazioni dei servizi OCI in base alle tue esigenze aziendali.

Considerazioni per la selezione di un servizio di messaggistica

Prendere in considerazione i seguenti fattori di valutazione per prendere una decisione.

Coreografia o orchestrazione

La coreografia e l'orchestrazione sono due approcci architettonici al modo in cui diversi componenti disaccoppiati sono organizzati per lavorare insieme. La coreografia adotta il principio che ogni componente esegue in modo indipendente, ma ascolta e guarda i segnali per quando eseguire la loro azione successiva. Un broker di messaggi trasmette i messaggi al componente successivo. I componenti possono essere molto autonomi e facili da scalare. Il lato negativo è che ogni componente richiede una maggiore comprensione del suo ruolo nella soluzione complessiva e aggiunge maggiore complessità. Un broker di messaggi è un elemento essenziale che riduce il carico di lavoro e garantisce maggiore throughput.

L'orchestrazione si riferisce all'idea di componenti assemblati come un'orchestrazione. Ogni componente deve conoscere solo il proprio task e quindi attendere che il direttore o l'orchestratore chieda loro di eseguire l'azione. Così il conduttore deve comprendere e avere l'intelligenza per dirigere tutti i componenti. Il ruolo di conduttore è la chiave e la sua resilienza e capacità di ridimensionarsi, influenzano direttamente la scalabilità e la resilienza della soluzione complessiva.

Alcuni prodotti di orchestrazione includono la capacità di coreografia (ad esempio l'inclusione di un broker) o di creare servizi che utilizzano componenti per ottenere l'effetto della comunicazione con broker.

Pagamento per messaggio o eventi rispetto a. Acquisto di massa

Considera i diversi modelli di pagamento in base all'impatto sui costi della tua soluzione. È possibile scegliere di pagare per messaggio se si avrà un volume di messaggi potenzialmente inutilizzato da un acquisto in blocco. Considera che il pagamento per messaggio o evento può costare di più a volume perché il costo minimo dell'impronta per un servizio deve essere distribuito su un numero inferiore di utilizzi.

Consumatori di messaggi singoli o multipli

La differenza tra una coda e un argomento consiste nel fatto che un messaggio può essere utilizzato una sola volta con una coda. Un argomento può avere molti consumatori diversi. Le code e gli argomenti possono avere molte istanze di un tipo di consumer. Più istanze dello stesso tipo di consumer collegate a un singolo argomento o coda sono spesso descritte come una condizione di razza in cui il successivo consumer disponibile utilizza il messaggio successivo disponibile.

Conservazione messaggio dopo la lettura

Alcuni broker di messaggi elimineranno un messaggio una volta letto (o dopo che tutti i consumer hanno letto il messaggio) per gestire le risorse. Apache Kafka registra fino a che punto un consumatore ha attraversato i messaggi ma non li elimina una volta letti. In questo modo è possibile riprodurre i messaggi in caso di problemi. Pertanto Kafka funge da data store, nonché da broker di messaggi e supporta la creazione di analisi dei dati nel data store dei messaggi.

Ordine garantito

Garantire che i messaggi vengano consegnati nell'ordine in cui vengono ricevuti, anziché nell'ordine in cui vengono memorizzati, introduce complessità e impatti sulle prestazioni. I problemi di latenza possono essere introdotti quando si lavora tramite un broker perché potrebbe attendere prima di consentire ai consumatori di ottenere un messaggio per assicurarsi che non ci siano messaggi ritardati che devono essere inseriti nell'ordine giusto prima che vengano consumati.

Ad esempio, l'ordinamento dei messaggi è essenziale per gli eventi che rappresentano un ordine in fase di annullamento. Il messaggio per la creazione dell'ordine può causare problemi di applicazione se i messaggi non seguono l'ordine.

Esistono schemi e strategie a livello di applicazione che possono contribuire a ridurre i problemi legati agli ordini e i vincoli del broker di offset.

Operazione asincrona

Il vantaggio di utilizzare un meccanismo broker è che il provider di messaggi non ha bisogno di conoscere il consumatore e non rallenta il provider. Il broker sa chi è il consumatore, che sia disponibile o meno, e gestisce la trasmissione se ci sono problemi con il consumatore (come le prestazioni). L'uso del broker consente la comunicazione asincrona e il provider e il consumer non devono essere sincronizzati.

Frequenza massima di messaggi, periodo di conservazione messaggi e volume massimo di conservazione messaggi

Questi fattori sono tutti influencer sul costo di fornire una soluzione serverless e richiederanno spesso limiti difficili da impostare. Il software non sempre offre prestazioni uniformi in quanto scala le aspettative. È possibile impostare limiti per controllare le aspettative e fornire comportamenti prevedibili. Devi comprendere questi limiti per stabilire se possono influire sulla soluzione che stai creando.

Ad esempio, un sistema di trading azionario riceverà messaggi quando i prezzi azionari cambiano. Ogni messaggio sarà di piccole dimensioni, ma il volume dei messaggi sarà elevato a causa dell'elevata frequenza di aggiornamenti. Un broker con throughput basso ma con grandi dimensioni di messaggi non può supportare questo requisito.

Supporto input standard del settore e supporto output standard del settore

L'uso di formati e protocolli standard del settore per inviare e ricevere messaggi aumenta la capacità del meccanismo di messaggistica di essere riconfigurato e utilizzato con distribuzioni e provider di implementazione diversi. È possibile utilizzare librerie comuni per gestire i meccanismi di comunicazione di basso livello e ridurre il collegamento tra fornitori.

Supporto per adattatori di terze parti

Per aiutare i fornitori di messaggi e i consumatori, avere supporto attraverso adattatori di terze parti può essere vantaggioso in quanto aumenta le opzioni di sviluppo.

Distribuzioni singole per compartimento

Puoi distribuire singoli canali o flussi di messaggistica a compartimenti specifici e consentire ai servizi presenti in una soluzione di potenzialmente disporre di controlli di sicurezza collettivi specifici tramite una superficie di controllo comune. Questo approccio si basa sul presupposto che tutti gli elementi possano essere controllati a livello di compartimento. Le soluzioni che non possono accogliere controlli a livello di compartimento per canale possono offrire alternative. Per approcci alternativi potrebbero essere necessarie ulteriori considerazioni sulla configurazione.

Usa autenticazione IAM OCI

Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) offre un solido livello di sicurezza di classe enterprise nei casi in cui la sicurezza può essere federata ad altri provider. L'utilizzo di un singolo provider IAM (con o senza federazione) rende più gestibile il controllo di sicurezza dell'accesso al flusso di dati.

I dati vengono cifrati in volo e a riposo

Se i dati che passano attraverso il servizio sono sensibili, devono essere protetti sia durante la trasmissione che mentre sono detenuti dal broker fino alla consegna. I messaggi riservati devono essere cifrati dal meccanismo di cifratura del broker per garantire l'assenza di perdita di messaggi.

Trasformazioni messaggi

A seconda dei principi architettonici adottati, il broker potrebbe avere la capacità di tradurre la formattazione dei messaggi. Il provider di messaggi o i consumatori non devono comprendere la semantica comune dei dati o sapere come il provider o i consumatori desiderano formattare i dati. Questa considerazione può anche estendersi alle modifiche dei protocolli utilizzati. Ad esempio, la conversione da REST a STOMP.

Audit trail

Per risolvere i problemi relativi alle applicazioni distribuite, un audit trail consente di tenere traccia della posizione di trasmissione e ricezione di un messaggio. Avere un audit trail può essere utile quando è necessario rispettare i requisiti legislativi. Pertanto, potrebbe essere necessario apprendere come il servizio può supportare questo requisito.

Esaminare la matrice decisionale

Utilizza la matrice decisionale riportata di seguito per scoprire le scelte disponibili dei servizi OCI e le considerazioni o i fattori di valutazione per scegliere un servizio particolare.

Servizio/fattore	Coda	Streaming	Notifiche	Oracle Integration (Gen2, Gen3)	Autonomous Database (TEQ e AQ)
Coreografia e orchestrazione	Coreografia	Coreografia	Coreografia	Coreografia e orchestrazione (dipende dalla configurazione dell'integrazione)	Coreografia e orchestrazione (dipende dalla configurazione dell'integrazione)
Pagamento per messaggio o evento rispetto all'acquisto in blocco	`Per API call + multiplier for messages > 64 KB`	`Per GB data transfer + Storage`	Dipende dal canale di comunicazione. Determinazione dei prezzi in base alla quantità inviata.	Prezzo in blocchi di 5000 chiamate di integrazione all'ora	No, prezzi del database
Singolo o più consumer per un messaggio	Consumatore singolo. (Condizioni di percorso consentite, ma solo un consumatore per messaggio).	Singolo e multiplo	Singolo e multiplo	Singolo e multiplo (dipende dalla definizione dell'integrazione)	Singolo e multiplo
Conservazione dei messaggi dopo la lettura	No	Sì	No	Sì (dipende dalla definizione dell'integrazione)	Sì
Ordine garantito	Miglior tentativo	Sì, all'interno di una partizione	No	Sì (dipende dalla definizione dell'integrazione)	Parziale (è possibile impostare regole sulle priorità, che possono dettare l'ordine di consumo)
Operazione asincrona	Sì	Sì	Sì	Sì (dipende dalla definizione dell'integrazione)	Sì
Standard di settore supportati per gli input	API REST, STOMP	Kafka Connect	Eventi cloud da eventi OCI, allarmi	Più schede	JMS e SQL Offri un'ulteriore esposizione con le implementazioni ORDS personalizzate fornendo API REST
Supporto per adattatori di terze parti	Implementazioni STOMP open source	Qualsiasi strumento, libreria o SDK conforme a Kafka	No	Ampia gamma di adattatori per il settore. È possibile generare dall'interfaccia REST o da un client JMS standard	Uso della libreria standard JMS SQL ampiamente supportato
Standard di settore supportati per gli output	STOMP, API REST	Kafka Connect	E-mail, Slack, PagerDuty, HTTP/S	Più schede	JMS e SQL
Frequenza massima messaggi	10 MBPS	1 MB al secondo per partizione Fino a 250 richieste `GET` al secondo	60 al minuto per HTTP/S 10 al minuto per e-mail 60 al minuto per gli argomenti di notifica	Non specificato	Dipende dal dimensionamento del database
Periodo di conservazione dei messaggi	7 giorni (o più breve se configurato)	7 giorni	Fino a tentativi di consegna esauriti	Nessun elemento definito	Configurabile
Volume massimo di conservazione	2 GB per coda (20 GB per tenancy)	La conservazione è determinata dalla velocità di scrittura massima di 1 MB al secondo per partizione per 7 giorni.	Funzione della frequenza dei messaggi e della durata dei nuovi tentativi di consegna.	Non applicabile	Dipende dalla configurazione del database
Supportato dall'SDK OCI o dall'interfaccia CLI per inviare messaggi	Sì	Sì	Sì	No	No
Distribuzioni singole per compartimento	Sì	Sì	Sì	N. Istanze di Oracle Integration separate a livello di compartimento e non di singole integrazioni	N. Le istanze di database sono allineate ai compartimenti e non alle singole code
Utilizza l'autenticazione IAM (RBAC e così via)	Sì	Sì	Sì	Sì	Sì
I dati sono criptati in volo e in archivio	Sì	Sì	Sì	Sì	Dipende dalla configurazione del database
Trasformazioni messaggi	No	No	Limitato. Formattazione amichevole per e-mail e così via. Se l'endpoint utilizza Oracle Functions, Functions può trasformare il messaggio.	Sì	Sì (procedure SQL memorizzate)
Audit trail	Sì (mediante log)	Sì (mediante log)	Sì (mediante log)	Sì (include Oracle Integration con log)	Sì

È possibile interpretare la matrice utilizzando le seguenti informazioni:

Modello di pagamento: si riferisce a ciascun messaggio o all'acquisto di massa di capacità.
Condizione di scadenza: quando una coda contiene più consumer, i consumer vengono descritti come "condizione di ricezione" perché i messaggi successivi vengono elaborati dal consumer che è pronto per un altro messaggio.
Endpoint basati su REST: alcuni servizi offrono endpoint basati su REST. Se il payload REST viene modellato mediante una specifica Open API, potrebbe non fornire un SDK specifico del payload. In questi casi, puoi utilizzare i servizi gateway API per generare gli SDK. Per ulteriori informazioni, consulta la documentazione OCI sulla generazione degli SDK per una risorsa API.

Oltre ai servizi OCI, la matrice fa riferimento a queste tecnologie:

STOMP: Simple (o Streaming) Text Orientated Messaging Protocol. Fornisce un formato wire interoperabile in modo che i client STOMP possano comunicare con qualsiasi broker di messaggi STOMP per fornire un'interoperabilità di messaggistica semplice e diffusa tra molte lingue, piattaforme e broker.
Implementazioni STOMP: fa riferimento ai server di messaggi noti conformi a STOMP.
Kafka Connect: questo strumento consente lo streaming e la scalabilità dei dati tra Apache Kafka e altri sistemi. Consente di definire rapidamente i connettori che spostano le raccolte di dati di grandi dimensioni all'interno e all'esterno di Kafka.

È possibile leggere informazioni aggiuntive sulle tecnologie nella sezione Esplora.