Identificar o Serviço de Mensagens Mais Adequado

Saiba mais sobre as considerações para selecionar um serviço de mensagens e, em seguida, use a tabela de matriz de decisões para analisar as diferentes opções e limitações dos serviços do OCI com base nas suas necessidades de negócios.

Considerações para Selecionar um Serviço de Mensagens

Considere os seguintes fatores de avaliação para tomar sua decisão.

Coreografia ou Orquestração

A coreografia e a orquestração são duas abordagens arquitetônicas sobre como diferentes componentes dissociados são organizados para funcionarem juntos. A coreografia adota o princípio de que cada componente funciona de forma independente, mas escuta e assiste por dicas para quando executar sua próxima ação. Um message broker transmite as dicas para o próximo componente. Os componentes podem ser muito autônomos e fáceis de dimensionar. A desvantagem é que cada componente requer uma maior compreensão da sua função na solução geral e acrescenta maior complexidade. Um broker de mensagens é um elemento crítico e sua simplicidade reduz a carga de trabalho e permite maior throughput.

Orquestração refere-se à ideia de componentes montados como uma orquestra. Cada componente só precisa saber sua tarefa e, em seguida, esperar que o condutor ou o orquestrador peça para executar a ação. Assim, o condutor deve compreender e ter a inteligência para dirigir todos os componentes. A função de condutor é fundamental e sua resiliência e capacidade de dimensionamento influenciam diretamente a escalabilidade e a resiliência da solução geral.

Alguns produtos de orquestração incluem a capacidade de coreografar (como a inclusão de um corretor) ou criar serviços que usam componentes para atingir o efeito da comunicação com corretagem.

Pagamento por Mensagem ou Eventos versus Compra em lote

Considere os diferentes modelos de pagamento com base no impacto de custo da sua solução. Você pode optar por pagar por mensagem se tiver um volume de mensagens não utilizado de uma compra em lote. Considere o fato de que o pagamento por mensagem ou evento pode custar mais em volume porque o custo mínimo de presença de um serviço deve ser distribuído em menos usos.

Consumidores de Mensagem Única ou Múltipla

A diferença entre uma Fila e um Tópico é que uma mensagem só pode ser consumida uma vez com uma fila. Um tópico pode ter muitos consumidores diferentes. Filas e tópicos podem ter muitas instâncias de um tipo de consumidor. Várias instâncias do mesmo tipo de consumidor conectadas a um único tópico ou fila são frequentemente descritas como uma Condição de Corrida em que o próximo consumidor disponível leva a próxima mensagem disponível.

Retenção de Mensagem Após a Leitura

Alguns corretores de mensagens excluirão uma mensagem uma vez lida (ou depois que todos os consumidores tiverem lido a mensagem) para gerenciar recursos. O Apache Kafka rastreia até que ponto um consumidor passou pelas mensagens, mas não as exclui uma vez lidas. Isso permite reproduzir mensagens se houver um problema. Portanto, o Kafka atua como um armazenamento de dados, bem como um broker de mensagens e suporta a criação de análises de dados no armazenamento de dados da mensagem.

Ordem Garantida

Garantir que as mensagens sejam entregues na ordem em que são recebidas, em vez da ordem em que são armazenadas, introduz complexidade e impacta o desempenho. Os problemas de latência podem ser introduzidos ao trabalhar por meio de um corretor, pois podem esperar antes de permitir que os consumidores recebam uma mensagem para garantir que não haja mensagens atrasadas que devam ser inseridas na ordem correta antes de serem consumidas.

Por exemplo, a ordenação de mensagens é essencial para eventos que representam uma ordem que está sendo cancelada. A mensagem para a criação da ordem poderá causar problemas no aplicativo se as mensagens não seguirem a ordem.

Existem padrões e estratégias no nível do aplicativo que podem ajudar a mitigar problemas de ordenação e compensar restrições de corretores.

Operação Assíncrona

O benefício de usar um mecanismo de corretagem é que o provedor de mensagens não precisa saber sobre o consumidor e não diminui o provedor. O corretor sabe quem é o consumidor, se ele está disponível ou não, e gerencia a transmissão se houver problemas com o consumidor (como desempenho). O uso do corretor permite comunicação assíncrona, e o provedor e o consumidor não precisam estar sincronizados.

Taxa Máxima de Mensagens, Período de Retenção de Mensagens e Volume Máximo de Retenção

Esses fatores são todos influenciadores no custo de fornecer uma solução sem servidor e muitas vezes exigirão limites difíceis para serem definidos. O software nem sempre oferece um desempenho uniforme à medida que aumenta as expectativas. Você pode definir limites para controlar expectativas e fornecer comportamentos previsíveis. Você deve entender esses limites para determinar se eles podem afetar a solução que está criando.

Por exemplo, um sistema de negociação de ações receberá mensagens quando os preços de compartilhamento mudarem. Cada mensagem será pequena, mas o volume de mensagens será alto devido à alta frequência de atualizações. Um corretor com um baixo throughput, mas um tamanho de mensagem grande não pode suportar este requisito.

Suporte de Entrada de Padrões do Setor e Suporte de Saída de Padrões do Setor

O uso de formatos e protocolos padrão do setor para enviar e receber mensagens aumenta a capacidade de o mecanismo de mensagens ser reconfigurado e usado com diferentes implantações e provedores de implementação. Você pode aproveitar bibliotecas comuns para lidar com a mecânica de comunicação de baixo nível e também reduzir o vínculo do fornecedor.

Suporte a Adaptador de Terceiros

Para ajudar a desenvolver provedores de mensagens e consumidores, ter suporte por meio de adaptadores de terceiros pode ser vantajoso à medida que aumenta as opções de desenvolvimento.

Implantações Individuais por Compartimento

Você pode implantar canais ou fluxos de mensagens individuais em compartimentos específicos e permitir que os serviços de uma solução tenham potencialmente controles de segurança selecionados por meio de uma superfície de controle comum. Essa abordagem pressupõe que todos os elementos possam ser controlados no nível do compartimento. As soluções que não podem acomodar controles no nível do compartimento por canal podem oferecer alternativas. As abordagens alternativas podem exigir considerações adicionais sobre configuração.

Usar Autenticação do OCI IAM

O Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) fornece um nível de segurança de classe empresarial robusto nos casos em que a segurança pode ser federada a outros provedores. Trabalhar por meio de um único provedor de IAM (com ou sem federação) torna o controle de segurança do acesso ao fluxo de dados mais gerenciável.

Os dados são criptografados em voo e em repouso

Se os dados que passam pelo serviço forem sensíveis, eles deverão ser protegidos durante a transmissão e durante a permanência do corretor até a entrega. As mensagens confidenciais devem ser criptografadas pelo mecanismo de criptografia do corretor para garantir que não haja perda de mensagem.

Transformação de Mensagem

Dependendo dos princípios arquitetônicos adotados, o corretor pode precisar ter a capacidade de traduzir a formatação de mensagens. O provedor de mensagens ou os consumidores não precisam entender a semântica de dados comum ou saber como o provedor ou os consumidores querem que os dados sejam formatados. Essa consideração também pode se estender a alterações nos protocolos que estão sendo usados. Por exemplo, traduzir de REST para STOMP.

Trilha de Auditoria

Para ajudar a remediar problemas com aplicativos distribuídos, uma trilha de auditoria permite o rastreamento de onde uma mensagem foi transmitida e recebida. Ter uma trilha de auditoria pode ser útil quando você deve cumprir os requisitos legais. Portanto, pode ser necessário aprender como o serviço pode suportar esse requisito.

Analisar a Matriz de Decisão

Use a matriz de decisão a seguir para conhecer as opções disponíveis dos serviços OCI e as considerações ou fatores de avaliação para escolher um serviço específico.

Serviço/Fator	Fila	Streaming	Notificações	Oracle Integration (Gen2, Gen3)	Autonomous Database (TEQ e AQ)
Coreografia versus Orquestração	Coreografia	Coreografia	Coreografia	Coreografia e Orquestração (Depende da configuração de integração)	Coreografia e Orquestração (Depende da configuração de integração)
Pagamento por mensagem ou evento versus compra em massa	`Per API call + multiplier for messages > 64 KB`	`Per GB data transfer + Storage`	Depende do canal de comunicação. Preço por quantidade enviada.	Preço em blocos de 5000 chamadas de integração por hora	Não, preços do Database
Um único ou vários consumidores para uma mensagem	Um único consumidor. (Condições de rendas permitidas, mas apenas um consumidor por mensagem).	Único e Vários	Único e Vários	Único e Múltiplo (Depende da definição de integração)	Único e Vários
Retenção de mensagens após leitura	Não	Sim	Não	Sim (Depende da definição de integração)	Sim
Ordem garantida	Melhor esforço	Sim, em uma partição	Não	Sim (Depende da definição de integração)	Parcial (É possível definir regras sobre prioridades, que podem ditar ordem de consumo)
Operação assíncrona	Sim	Sim	Sim	Sim (Depende da definição de integração)	Sim
Padrões do setor suportados para entradas	API REST, STOMP	Conexão Kafka	Eventos na Nuvem de Eventos, Alarmes do OCI	Vários adaptadores diferentes	JMS e SQL Fornecer exposição adicional com implementações ORDS personalizadas fornecendo APIs REST
Suporte do Adaptador de Terceiros	Implementações STOMP de código aberto	Qualquer ferramenta, biblioteca ou SDK compatível com Kafka	Não	Ampla gama de adaptadores do setor. Você pode gerar a partir da interface REST ou de um cliente JMS padrão	Uso da biblioteca padrão JMS O SQL é amplamente suportado
Padrões do setor suportados para saídas	STOMP, API REST	Conexão Kafka	E-mail, Slack, PagerDuty, HTTP/S	Vários adaptadores diferentes	JMS e SQL
Taxa máxima de mensagens	10 MBPS	1 MB por segundo por partição Até 250 solicitações `GET` por segundo	60 por minuto para HTTP/S 10 por minuto para E-mail 60 por minuto para tópicos de notificação	Nenhum especificado	Depende do tamanho do banco de dados
Período de retenção de mensagens	7 dias (ou menos, se configurado)	7 dias	Até repetições de entrega esgotadas	Nenhum definido	Configurável
Volume Máximo de Retenção	2 GB por fila (20 GB por tenancy)	A retenção é ditada pela taxa de gravação máxima de 1 MB por segundo por partição por 7 dias.	A função da taxa de mensagens e da duração da nova tentativa de entrega.	Não aplicável	Depende da configuração do Banco de Dados
Suportado pelo OCI SDK ou CLI para enviar mensagens	Sim	Sim	Sim	Não	Não
Implantações individuais por compartimento	Sim	Sim	Sim	Não. Instâncias do Oracle Integration separadas no nível do compartimento, e não integrações individuais	Não. As instâncias do banco de dados se alinham aos compartimentos, não às filas individuais
Usa Autenticação do IAM (RBAC e assim por diante)	Sim	Sim	Sim	Sim	Sim
Os dados são criptografados em voo e em repouso	Sim	Sim	Sim	Sim	Depende da configuração do Banco de Dados
Transformação de mensagem	Não	Não	Limitado. Formatação amigável para e-mail etc. Se o ponto final estiver usando o Oracle Functions, o serviço Functions poderá transformar a mensagem.	Sim	Sim (Procedimentos SQL armazenados)
Auditoria	Sim (usando Log)	Sim (usando Log)	Sim (usando Log)	Sim (Inclui o Oracle Integration com Log)	Sim

Você pode interpretar a matriz usando as seguintes informações:

Modelo de pagamento: refere-se a por mensagem ou compra em massa de capacidade.
Condição de atribuição: Quando uma fila tem vários consumidores, os consumidores são descritos como estando em uma 'condição de rastreamento' porque as próximas mensagens são processadas pelo consumidor que primeiro está pronto para outra mensagem.
Pontos finais baseados em REST: Alguns dos serviços oferecem pontos finais baseados em REST. Se o payload REST for modelado usando uma especificação de API Aberta, talvez ele não forneça um SDK específico do payload. Nesses casos, você pode usar serviços do API Gateway para gerar SDKs. Consulte a Documentação do OCI sobre Geração de SDKs para um Recurso de API para obter mais informações.

Além dos serviços da OCI, a matriz se refere a estas tecnologias:

STOMP: Simple (ou Streaming) Text Orientated Messaging Protocol. Ele oferece um formato de transmissão interoperável para que os clientes STOMP possam se comunicar com qualquer corretor de mensagens STOMP para fornecer interoperabilidade de mensagens fácil e ampla entre muitos idiomas, plataformas e corretores.
Implementações STOMP: refere-se aos servidores de mensagens compatíveis com STOMP conhecidos.
Kafka Connect: Essa ferramenta permite o streaming e o dimensionamento de dados de forma confiável entre o Apache Kafka e outros sistemas. Permite definir rapidamente conectores que movem grandes coleções de dados para dentro e para fora do Kafka.

Você pode ler informações adicionais sobre as tecnologias na seção Explorar.