Usar as ferramentas e os padrões certos para arquiteturas conduzidas por evento

As arquiteturas conduzidas por evento dão suporte à produção e ao consumo eficientes de eventos, que comunicam alterações de estado do sistema ou do aplicativo. Essas arquiteturas permitem conexões flexíveis entre sistemas e dão suporte a processos e atualizações quase em tempo real que funcionam entre sistemas. Embora seja fácil ver as vantagens de arquiteturas conduzidas por evento, os detalhes da implementação nem sempre são tão claros. Quais recursos você precisa considerar em padrões de arquitetura conduzidos por evento? Quais problemas específicos esses padrões solucionam? Quais considerações especiais se aplicam às suas soluções e quais são os padrões ideais para lidar com elas?

Este guia apresenta padrões usados para criar arquiteturas ideais conduzidas por evento ao trabalhar com tecnologias do Salesforce. Ele também discute ferramentas de controle disponíveis no Salesforce e fornece recomendações de ferramentas para uma seleção de casos de uso. Para obter informações sobre integrações em nível de dados envolvendo o Salesforce, consulte nosso Guia de decisão de integração de dados.

• Use arquiteturas conduzidas por evento para processos que não exigem respostas síncronas a solicitações. Os padrões descritos neste guia são projetados para consistência de dados, escalabilidade e reutilização, o que ajuda a manter o débito técnico a um mínimo conforme o panorama de aplicativos da sua organização evolui. (Consulte Bem-arquitetado - taxa de transferência para obter mais informações.)

• Se o MuleSoft ou outra solução Enterprise Service Bus (ESB) fizer parte do seu panorama existente, use-o sempre que possível. Essas soluções são projetadas para dar suporte a padrões de arquitetura conduzidos por evento e têm recursos poderosos que permitem reutilizar integrações em toda a sua empresa.

• Use a API Pub/Sub para qualquer padrão de publicação/assinatura futuro em vez de criar seus próprios manipuladores de evento usando outras APIs, incluindo a API de streaming. Agora que a API Pub/Sub está disponível ao público em geral, use-a para qualquer novo padrão de publicação/assinatura. Planeje migrar as comunicações de evento existentes usando outras APIs de plataforma, como a API de streaming ou serviços do Apex personalizados, para a API Pub/Sub quando for viável.

• Os eventos de plataforma e a Captura de dados de alteração (CDC) são os mecanismos preferidos para publicar alterações de registro e campo que precisam ser consumidas por outros sistemas. Não recomendamos usar PushTopic e eventos genéricos para novas implementações. A Salesforce continuará oferecendo suporte a eventos genéricos e PushTopic nos recursos funcionais atuais, mas não planeja fazer mais investimentos nessa tecnologia.

	A Plataforma Salesforce é uma plataforma abrangente baseada em IA que une funcionários, agentes de IA autônomos, dados da empresa e aplicativos em um único sistema confiável para aumentar a produtividade e a experiência do cliente. Ele permite a criação de uma "empresa ativa" conectando aplicativos Customer 360, Data Cloud e Slack para automação completa.
	O MuleSoft é a plataforma de integração líder da Salesforce que permite que as organizações conectem aplicativos, dados e dispositivos em ambientes locais e na nuvem. O MuleSoft é uma plataforma que dá aos TI as plataformas para desbloquear dados entre sistemas, desenvolver estruturas de integração e automação escalonáveis e criar experiências diferenciadas e conectadas rapidamente.

Arquiteturas conduzidas por evento (EDAs) são recomendadas para cenários que exigem notificações quase em tempo real, distribuição de carga de processamento para mensagens de alto volume ou complexas e integração de sistemas como IoT e dispositivos móveis que exigem resiliência de conectividade por meio de fila. No entanto, os EDAs não devem ser implementados para processos que exigem respostas humanas síncronas imediatas, pois são projetados para execução assíncrona. Eles também não são adequados se os dados de origem mudarem com tanta frequência que um padrão mais simples, como processamento em lote, seria suficiente.

Aqui estão vários cenários comuns que geralmente são adequados para uma arquitetura conduzida por evento:

A maioria das organizações grandes tem paisagens de TI complexas que têm uma combinação de sistemas com diferentes recursos. É possível ou provável que sua organização tenha sistemas legados que não oferecem suporte a integrações conduzidas por evento. Você também pode ter casos de uso em que integrações conduzidas por evento não fazem sentido, mesmo que os sistemas tenham suporte para elas (por exemplo, transferências de arquivos SFTP de terceiros). Se você dar um passo para trás e olhar para o panorama de TI da sua organização como um todo, provavelmente, como acontece com outras soluções de arquitetura, você usará uma mistura de padrões para dar suporte a diferentes cenários. Quando você decidir tornar o evento conduzido sua abordagem preferida para integrações, pense nela como outra ferramenta na sua caixa de ferramentas. Ele pode e deve ser usado nos cenários certos, mas não é uma abordagem a ser imposta a todos os sistemas. O desenvolvimento de uma estratégia de integração abrangente ajudará a determinar quando os padrões descritos neste guia podem ou não ser adequados.

Muitos cenários exigem arquiteturas conduzidas por evento, e em alguns cenários, as arquiteturas conduzidas por evento funcionarão mesmo que não sejam as mais adequadas. Porém, em alguns cenários, arquiteturas conduzidas por evento simplesmente não devem ser usadas. Aqui estão algumas perguntas do ponto de decisão para ajudá-lo a identificar estes cenários:

Há uma variedade de padrões de arquitetura conduzidos por evento. Alguns são padrões de finalidade geral que podem ser aplicados em casos de uso que não têm requisitos especiais além de serem conduzidos por evento; por exemplo, consulte Bem-Arquiteto - Interoperabilidade. Outros padrões são aplicáveis aos casos de uso específicos discutidos aqui, como integrações que envolvem grandes volumes de dados ou cenários que exigem retenção de mensagens mais longa.

A tabela abaixo compara os atributos dos padrões descritos neste documento. Use-o como uma referência rápida quando precisar identificar possíveis padrões para um determinado caso de uso.

O Salesforce oferece várias ferramentas para ajudá-lo a lidar com seus casos de uso conduzidos por evento. Esta tabela contém uma visão geral de alto nível das ferramentas disponíveis.

Quando um registro crítico muda de estado em um aplicativo principal, por exemplo, o status de um pedido muda de "Processando" para "Enviado", vários outros sistemas provavelmente precisam de uma notificação quase em tempo real para realizar suas respectivas tarefas. Uma necessidade de negócios específica surge quando o volume dessas alterações é alto e as mensagens são complexas, tornando as integrações de ponto a ponto tradicionais pesadas e difíceis de manter. Estabelecer conexões frágeis e personalizadas para cada aplicativo dependente leva a débitos técnicos e impede a capacidade da organização de escalar rapidamente. É necessária uma abordagem de integração robusta para gerenciar essas sincronizações de dados frequentes sem acoplar o sistema de origem diretamente a cada sistema consumidor.

O diagrama abaixo mostra um padrão de publicação/assinatura típico com vários editores e assinantes compartilhando dados por meio de um barramento de evento. Esse padrão fundamental forma a base para os padrões mais específicos que podem ser encontrados em todo o restante deste guia. Algumas características principais desse padrão são:

• Não há conexão direta entre editores e assinantes. Os editores simplesmente enviam mensagens para um barramento de evento, que as transmite para qualquer outro sistema que queira escutá-las.

• O mesmo sistema pode ser um editor e um assinante.

• Os sistemas podem publicar ou assinar vários tipos de eventos.

• Como acontece com todos os padrões neste guia, o padrão publish / subscribe se enquadra em uma categoria geral de padrão de integração conhecida como invocação de procedimento remoto (RPI) ou simplesmente "apagar e esquecer".

Quando uma organização precisa enviar atualizações instantâneas a um grande número de aplicativos clientes, como notificações por push ou mensagens SMS para dispositivos móveis, o processo tradicional de criar transmissões exclusivas para cada destinatário se torna rapidamente um gargalinho de escalabilidade. A necessidade de negócio principal, neste caso, é a distribuição rápida e de alto desempenho de uma única informação, como um alerta de conta ou um aviso de alteração crítica de serviço, para vários aplicativos de ponto de extremidade simultaneamente. Uma abordagem simplificada para cumprir esse requisito envolve rotear todas as mensagens por uma única fila, que atua como o ponto central de informações de evento para todos os sistemas de consumo. Essa abordagem melhora o desempenho eliminando a necessidade de gerenciar muitas cópias de mensagem separadas.

Com o padrão de efusão, as mensagens são entregues para um ou vários destinos (ou seja, escutando clientes ou assinantes) por meio de uma única fila de mensagens. Os assinantes recuperam a mesma mensagem da fila, em vez de sua própria cópia exclusiva. (Observe que, embora isso melhore o desempenho, também pode tornar mais difícil verificar se um assinante específico recebeu ou não a mensagem.)

Alguns cenários de evento são caracterizados por um influxo significativo de volume de mensagens que ameaça sobrecarregar a capacidade dos processos de sincronização e transformação ou por uma lógica complexa de várias etapas necessária para processar e transformar dados de evento.

Alguns exemplos incluem:

• Picos sazonais de volume: Pode haver picos de volume que os varejistas online veem quando uma seleção de seus produtos está "na temporada". Quando grandes números de clientes estão fazendo compras ao mesmo tempo, o número de eventos gerados pode exceder temporariamente a capacidade dos processos de sincronização e transformação. Consulte Well-Architected – Data Handling para obter mais informações.

• Gerenciamento de caso ou reivindicações: As empresas baseadas em serviço podem enfrentar aumentos no número de casos ou reivindicações durante interrupções.

• Transformações de dados complexas: Organizações que exigem lógica complexa para transformar mensagens costumam se preocupar com eventos sendo gerados mais rapidamente do que podem ser transformados.

Esse padrão lida com o desafio de as mensagens serem geradas mais rapidamente do que podem ser transformadas. Ele garante que grandes volumes de mensagens e manipulações de dados necessárias possam ser tratadas com confiança, incorporando uma plataforma de mensagens de streaming e segmentando a lógica de processamento de mensagens em componentes dedicados.

O padrão de Mensagens passadas funciona segmentando a lógica de processamento de mensagens em vários componentes:

• Um componente lida com o roteamento de mensagens, determinando as transformações necessárias e o destino final.

• Um conjunto separado de componentes lida com diferentes camadas de transformação de mensagem (por exemplo, mapeamentos de campo, relacionamentos de objeto etc.).

• O último componente grava a mensagem final modificada.

Alguns produtores geram um fluxo contínuo de eventos. Um exemplo comum é o streaming de mídia, que envolve interações do usuário que ocorrem naturalmente como eventos separados. Vários sistemas devem reagir ao mesmo comportamento do usuário simultaneamente sem bloquear a experiência de streaming principal.

Considere os eventos para uma plataforma de streaming de música. Essas podem incluir:

• Rastrear eventos iniciados/pausados/pularam

• Eventos de sessão de escuta com carimbos de data e hora

• Eventos de criação/modificação da lista de reprodução

• Eventos de compartilhamento social

• Download para escuta offline

No padrão de streaming, os assinantes acessam cada fluxo de evento e processam os eventos na ordem exata em que são recebidos. Cópias únicas de cada fluxo de mensagens são enviadas a cada assinante, tornando possível entregar conteúdo específico do assinante e identificar quais assinantes recebem quais fluxos.

Para que um fluxo faça sentido, todos os seus eventos e suas mensagens associadas precisam estar na ordem correta. Se você originar os dados em um fluxo de sistemas diferentes, precisará incorporar lógica de pedido adicional como parte do processo de design.

Os casos de uso de enfileiramento são onipresentes. Os exemplos incluem:

• Conexões de internet de baixa qualidade: Organizações de serviço de campo ou outras organizações em que as equipes com dispositivos móveis precisam trabalhar em áreas com acesso à Internet de baixa qualidade ou intermitente se beneficiam do enfileiramento, pois os aplicativos nesses dispositivos podem se conectar às filas e recuperar todas as mensagens relevantes quando a conectividade é restaurada.

• Buffering de mensagem: Quando o volume de mensagens ocasionalmente excede a capacidade de processamento de um assinante e a latência aumentada não cria problemas adicionais, as filas podem ser uma margem para armazenar mensagens em excesso e evitar a perda de dados.

• Gerenciamento de transporte: Organizações de logística que precisam monitorar suas frotas podem usar esse padrão para visualizar as rotas que cada veículo está seguindo quase em tempo real e garantir que os motoristas estejam sendo o mais eficientes possível.

• Dispositivos de IoT: Os fabricantes costumam usar sistemas que geram fluxos de dados rápidos, e esses fluxos podem ter efeitos a jusante em sistemas adicionais. Esse padrão pode ser usado para identificar sequências de eventos que exigem intervenção humana antes que ocorram falhas catastróficas em vários sistemas.

No padrão de enfileiramento, os produtores enviam mensagens para filas, que mantêm as mensagens até que os assinantes as recuperem. A maioria das filas de mensagens segue a ordem de primeira entrada e primeira saída (FIFO) e exclui todas as mensagens após a recuperação. Cada assinante tem uma fila exclusiva, que exige etapas de configuração adicionais, mas permite garantir a entrega e identificar quais assinantes receberam quais mensagens.

Devido à natureza assíncrona do padrão de enfileiramento, pode haver um longo atraso entre a adição de uma mensagem a uma fila e a recuperação dessa mensagem. As filas exigem memória ou espaço de armazenamento para conter suas mensagens, portanto, elas não podem crescer indefinidamente, o que significa que um assinante que está offline indefinidamente pode causar uma falha se mensagens suficientes se acumularem na fila. O buffering de mensagens poderá ter o mesmo efeito se os tempos de processamento do assinante ficarem longos demais, fazendo com que grandes volumes de mensagens se acumulem nas filas. Para mitigar esses riscos, realize uma análise completa dos requisitos de armazenamento para todas as filas de mensagens e, se necessário, projete processos que limparão e desabilitarão as filas se as mensagens não forem recuperadas dentro de um tempo definido ou quando atingirem um volume predeterminado.

Mesmo que você esteja totalmente convencido de que uma arquitetura orientada por evento é a melhor para sua organização, pode estar começando com uma paisagem que já tem um grande número de integrações de ponto a ponto. Obter financiamento para um projeto para substituir todas as suas integrações de uma só vez pode ser difícil e talvez nem sequer seja possível usar uma arquitetura conduzida por evento diretamente com alguns sistemas legados. Nesses cenários, você pode adotar uma abordagem incremental para migrar para uma arquitetura mais solta, convertendo primeiro os aplicativos mais críticos para os negócios, então convertendo outros sistemas conforme eles são atualizados ou substituídos em projetos futuros. Essa abordagem facilita a adição de novos aplicativos ao barramento de eventos e permite que sua paisagem de TI geral permaneça escalonável e resiliente à medida que os sistemas continuam sendo adicionados ao longo do tempo.

Como arquitetos, sabemos que toda arquitetura vem com desvantagens. Uma arquitetura conduzida por evento não é exceção. Embora uma paisagem repleta de sistemas soltos seja altamente escalonável e resiliente, há algumas vantagens a serem consideradas também:

• Estratégia global de integração: Independentemente das ferramentas e padrões que você decide usar, é importante começar criando uma estratégia para como os dados serão compartilhados entre os vários sistemas no panorama da sua organização. Essa estratégia deve incluir as metas da sua organização para seus dados, como os dados podem ser compartilhados e padrões usados, além de fontes de dados, destinos, estruturas e requisitos de propriedade e acesso.

• Suporte para sistemas legados: Sua organização pode ter sistemas legados que simplesmente não oferecem suporte a padrões de arquitetura conduzidos por evento. Embora seja possível criar soluções alternativas (por exemplo, com um processo que atua como um passo a passo assinando eventos e então enviando a saída para o sistema de destino por meio de um meio diferente de transferência de dados), talvez você queira considerar outros métodos de integração neste caso.

• Alterações estruturais em mensagens: Depois que a estrutura da mensagem inicial é definida e acordada entre editores e assinantes, pode ser difícil alterar, principalmente se os assinantes forem externos. Há várias maneiras de lidar com esse problema. Você pode usar pontos de extremidade com controle de versão, mas certifique-se de definir e comunicar um ciclo de vida claro para cada versão para que seus desenvolvedores não tenham que manter muitas versões simultaneamente. Se o Apache Kafka no Heroku fizer parte da sua paisagem, você também poderá considerar um registro de esquema ou uma ferramenta semelhante, mas certifique-se de que os outros sistemas na sua paisagem também dêem suporte a ele (e o usem).

• Falta de visibilidade entre editores e assinantes: Na maioria dos padrões de arquitetura conduzidos por evento, os editores não estão cientes do status de seus assinantes. Portanto, se um editor enviar uma mensagem crítica enquanto todos os assinantes estiverem offline, talvez a mensagem nunca seja entregue. Você pode resolver esse problema usando a funcionalidade de reprodução ou adicionando assinantes redundantes que são executados em servidores separados para todas as mensagens críticas.

• Botões de desempenho: À medida que uma arquitetura conduzida por evento cresce, o barramento de evento pode se tornar um gargalos para a entrega de mensagens se ele ficar sobrecarregado com muitos editores tentando enviar mensagens a muitos assinantes ao mesmo tempo. Você pode lidar com isso aumentando os recursos de memória e processamento alocados ao barramento de evento ou usando vários barramentos de evento para processar diferentes tipos de mensagens em paralelo.

Antes de implementar uma arquitetura conduzida por evento, considere se você realmente precisa usar uma no primeiro lugar. A seção anterior descreve cenários de negócios comuns que são adequados a cada padrão de arquitetura conduzida por evento. Você também pode ler mais em Well-Architected - Interoperability. Revise os desafios a serem considerados ao implementar Arquiteturas conduzidas por evento para determinar se os padrões que você tem em mente são mais adequados para seus casos de uso específicos.

Observe que, embora a maioria dos cenários abordados neste guia envolva integrações, as arquiteturas conduzidas por evento também podem ser usadas para enviar mensagens em uma única organização do Salesforce por meio do uso de eventos de plataforma, por exemplo. Lembre-se de quaisquer limites de alocação de evento aplicáveis ao projetar processos que usam eventos de plataforma como um sistema de mensagens interno.

Frequentemente, antipadrões em arquiteturas conduzidas por evento vêm do uso de eventos como uma solução alternativa para comunicações internas em uma organização do Salesforce. Antipadrões comuns incluem:

• Publicar eventos de acionadores do Apex associados ao mesmo objeto de evento: Isso resultará em um loop de acionador infinito.

• Publicar eventos do Apex antes da conclusão de uma transação DML: Se uma transação falhar e reverter, quaisquer eventos publicados que tenham o comportamento Publicar publicação imediata não serão incluídos no comportamento de reversão.

• Publicar eventos no Fluxo para orquestrar a automação subsequente: A melhor maneira de coordenar a lógica entre várias automações é usar subfluxos ou Flow Orchestrator.

• Criando dependências de tempo de execução: Não publique eventos para facilitar a comunicação entre pacotes sem tomar as etapas adequadas para eliminar as dependências de tempo de execução.

• Cargas úteis desnecessariamente grandes: Ao fazer solicitações, é melhor enviar e receber a menor quantidade possível de dados na carga útil. Cada ação de um usuário pode potencialmente gerar várias solicitações, e é importante que elas sejam processadas de maneira eficiente. Enviar mais dados do que o necessário pode contribuir para desacelerar o transporte e aumentar o tempo de processamento.

• Manuseio não seletivo de eventos de solicitação: Quando há vários componentes ouvindo um evento de aplicativo, os desenvolvedores devem garantir que o manipulador de evento seja executado apenas quando for realmente desejado e útil. Por exemplo, no Console do Lightning, os componentes contidos em guias que não estão focalizadas ainda podem estar ouvindo, embora não estejam visíveis. Um desenvolvedor pode usar várias técnicas, como usar um item de utilitário em segundo plano como o único ouvinte ou chamar getEnclosingTabId() para determinar se essa instância do componente está delimitada na guia focada para garantir que cada evento seja tratado apenas quando ele for pretendido.

• Usando o comportamento de publicação de Eventos de plataforma incorretamente: Os Eventos de plataforma têm dois comportamentos de publicação: Publicar imediatamente e Publicar após confirmação. Pode ser útil usar eventos de plataforma em tempo real para casos de uso, como Registro, em que você deseja publicar o evento de registro independentemente de a transação ser bem-sucedida ou confirmada. No entanto, use Publicar imediatamente com muito cuidado com eventos de plataforma em tempo real. Os eventos podem ser consumidos por assinantes na mesma transação e causar bloqueios de linha ou outras condições de corrida.

Ao implementar uma arquitetura conduzida por evento, uma das chaves para o sucesso é definir padrões para como os eventos em si são projetados. Os detalhes variarão dependendo dos casos de uso da sua organização, mas aqui estão algumas diretrizes gerais:

• Determine a estrutura ideal para suas cargas úteis de evento. Embora tamanhos menores de mensagem reduzam os tempos de processamento, bombardear assinantes com volumes enormes de mensagens pode causar gargalos de desempenho. Talvez seja necessário iterar em seus tamanhos e estruturas de carga útil para encontrar o saldo certo. O MuleSoft e ferramentas ESB semelhantes oferecem a capacidade de projetar cargas úteis personalizadas nas mensagens associadas aos seus eventos, o que pode ajudá-lo a visualizar estruturas de dados para melhorar o desempenho no lado do assinante. (Consulte Good-Architected – API Management para obter mais informações.)

• Pense em seus processos de ponta a ponta. Certifique-se de que você não esteja criando cenários de "loop infinito", que podem ser difíceis de rastrear depois que as integrações forem implementadas. Um exemplo disso seria dois sistemas que publicam eventos quando os registros são atualizados, ao mesmo tempo que escutam os eventos uns dos outros, que acionam eventos publicados adicionais quando são processados.

  Você pode corrigir esse tipo de antipadrão adicionando lógica a ambos os sistemas que garante que as alterações feitas como resultado de um evento sendo consumido não resultem na publicação de um novo evento. Você também deve documentar todos os seus eventos, seus acionadores associados e os sistemas a jusante que podem ser afetados. Use esta documentação como referência durante sessões de design para ajudar a capturar loops intermináveis e cenários semelhantes o mais cedo possível. (Consulte Bem-Arquiteto - Projeto de processo para obter mais informações.)

• Usar convenções de nomenclatura comuns entre sistemas. Convenções de nomenclatura consistentes são uma prática recomendada para todo o desenvolvimento de software, incluindo arquiteturas conduzidas por evento. Reserve tempo para documentar um conjunto de padrões para nomes de evento, estruturas, objetos associados e processos de tratamento de erros para garantir a consistência entre sistemas. (Consulte Bem-Arquiteto - Padrões de Design para obter mais informações.)