Este artigo descreve o padrão Messaging Bridge, que é uma técnica que você pode usar para integrar sistemas diferentes criados sobre diferentes infraestruturas de mensagens.
Contexto e problema
Muitas organizações e cargas de trabalho podem, inadvertidamente, ter sistemas de TI que usam várias infraestruturas de mensagens, como Microsoft Message Queueing (MSMQ), RabbitMQ, Azure Service Bus e Amazon SQS. Esse problema pode ocorrer devido a fusões, aquisições ou devido à extensão dos sistemas locais atuais para componentes hospedados na nuvem para economia e facilidade de manutenção.
Os desenvolvedores podem enfrentar esse desafio modificando os sistemas que estão sendo integrados para se comunicar usando serviços Web baseados em HTTP. No entanto, esta abordagem tem inconvenientes, incluindo:
- Os sistemas devem ser modificados adicionando um cliente HTTP de um lado e um manipulador de solicitação HTTP do outro. Os sistemas devem então ser novamente testados e reimplantados.
- Os pontos de extremidade HTTP devem ser hospedados, o que aumenta a complexidade quando você torna os serviços Web seguros e altamente disponíveis.
- Problemas frequentes de conectividade de rede que exigem mecanismos de repetição personalizados.
Solução
Se os sistemas que estão sendo integrados consistirem em componentes que se comunicam por meio da troca de mensagens, o padrão Messaging Bridge melhora a integração e reduz as desvantagens.
Nesse cenário, cada sistema se conecta a uma infraestrutura de mensagens. Para integrar diferentes infraestruturas de mensagens, introduza um componente de ponte que se conecta a duas ou mais infraestruturas de mensagens ao mesmo tempo. A ponte puxa mensagens de um e empurra-as para o outro sem alterar a carga útil.
Os sistemas que estão sendo integrados não precisam reconhecer os outros ou a ponte. O sistema de remetente está configurado para enviar mensagens específicas para uma fila designada em sua infraestrutura de mensagens nativa. A ponte pega essas mensagens e as encaminha para outra fila em uma infraestrutura de mensagens diferente, onde o sistema recetor as pega.
Benefícios
- Os sistemas que estão sendo integrados através do Messaging Bridge não precisam ser modificados. Idealmente, os pontos de extremidade não estão cientes de que as mensagens estão conectadas.
- A integração é mais confiável em comparação com a alternativa HTTP devido à garantia do mecanismo de entrega de mensagens pelo menos uma vez.
- Os cenários de migração podem ser mais flexíveis. Por exemplo, os pontos de extremidade podem ser migrados de uma infraestrutura de mensagens para outra conforme a programação permite, em vez de todos de uma só vez.
Desvantagens
- Os recursos avançados de uma ou ambas as tecnologias de mensagens podem não estar disponíveis na rota em ponte.
- A rota em ponte precisa considerar as limitações de ambas as tecnologias. Por exemplo, o tamanho máximo da mensagem pode ser de 4 MB no MSMQ, mas apenas 64 KB nas filas de Armazenamento do Azure.
Problemas e considerações
Considere os seguintes pontos ao implementar o padrão Messaging Bridge:
Se um dos sistemas integrados depender de transações distribuídas, por exemplo, Microsoft Distributed Transaction Coordinator (DTC), para ser correto, você deverá implementar um mecanismo de desduplicação na ponte.
Se um dos sistemas que estão sendo integrados não usar nenhuma infraestrutura de mensagens e não puder ser modificado, você poderá criar a ponte de mensagens entre a infraestrutura usada pelo outro sistema e uma fila emulada pelo SQL Server. O sistema herdado pode enviar mensagens usando o recurso de captura de dados de alteração para o SQL Server enviar suas alterações por push para uma tabela de fila dedicada. A ponte pode encaminhar essas mensagens para a infraestrutura de mensagens real.
Você pode usar uma única fila em cada infraestrutura de mensagens, designada como fila de ponte. Nessa topologia, configure o sistema de envio para usar essa fila específica como destino para tipos de mensagem que são enviados para o outro sistema. Você também pode usar vários pares de filas em cada infraestrutura de mensagens, para que o remetente não tenha conhecimento da ponte. Uma fila de sombra é criada para cada fila de destino na infraestrutura de mensagens do sistema de destino. A ponte encaminha mensagens entre as filas de sombra e suas contrapartes.
Para atender aos SLAs (contratos de nível de serviço) de disponibilidade desejados, talvez seja necessário expandir a ponte de mensagens usando a abordagem de consumidores concorrentes.
Os componentes regulares de processamento de mensagens usam o padrão Retry para lidar com falhas transitórias. O limite do contador de tentativas permite que os componentes detetem mensagens suspeitas e as removam da fila para desbloquear o processamento. A ponte pode exigir uma política de repetição diferente para evitar a falsa identificação de mensagens como venenosas se ocorrer uma falha de infraestrutura. Você pode usar o padrão Disjuntor para pausar o encaminhamento.
Quando utilizar este padrão
Use o padrão Messaging Bridge quando precisar:
- Integre sistemas existentes com necessidade mínima de modificação.
- Integre aplicativos herdados que não podem usar outras tecnologias de mensagens.
- Estenda os aplicativos locais existentes com componentes hospedados na nuvem.
- Ligue sistemas geo-distribuídos quando a ligação à Internet não estiver estável.
- Migre um único sistema distribuído de uma infraestrutura de mensagens para outra de forma incremental, sem a necessidade de migrar todo o sistema de uma só vez.
Este padrão pode não ser adequado se:
- Pelo menos um dos sistemas envolvidos depende de um recurso de uma infraestrutura de mensagens que não está presente no outro.
- A integração é síncrona por natureza, e o sistema iniciador requer resposta imediata.
- A integração tem requisitos funcionais ou não funcionais específicos, como questões de segurança ou privacidade.
- O volume de dados para a integração excede a capacidade do sistema de mensagens ou torna as mensagens uma solução cara para o problema.
Design da carga de trabalho
Um arquiteto deve avaliar como o padrão Messaging Bridge pode ser usado no design de sua carga de trabalho para abordar as metas e os princípios abordados nos pilares do Azure Well-Architected Framework. Por exemplo:
| Pilar | Como esse padrão suporta os objetivos do pilar |
|---|---|
| A Otimização de Custos está focada em sustentar e melhorar o retorno do investimento da sua carga de trabalho. | Esta etapa intermediária pode aumentar a longevidade do seu sistema existente sem a necessidade de regravações, permitindo a interoperabilidade com sistemas que usam uma tecnologia diferente de mensagens ou eventos. - CO:07 Custos dos componentes |
| A Excelência Operacional ajuda a fornecer qualidade de carga de trabalho por meio de processos padronizados e coesão da equipe. | Essa dissociação oferece flexibilidade quando você faz a transição da tecnologia de mensagens e eventos dentro de sua carga de trabalho ou quando você tem requisitos heterogêneos de dependências externas. - OE:06 Implantando alterações de carga de trabalho |
Como em qualquer decisão de design, considere quaisquer compensações em relação aos objetivos dos outros pilares que possam ser introduzidos com esse padrão.
Exemplo
Há um aplicativo escrito em uma estrutura .NET para gerenciar o agendamento de funcionários hospedado localmente. O aplicativo é bem estruturado com componentes separados que se comunicam via MSMQ. O aplicativo funciona e a equipe de carga de trabalho não tem intenção de reescrevê-lo. Um novo consumidor dos dados de agendamento precisa ser construído para atender a uma necessidade de negócios, e a estratégia de TI exige a construção de novos softwares como aplicativos nativos da nuvem para otimizar os custos e o tempo de entrega.
A arquitetura assíncrona baseada em fila funcionou para a equipe de carga de trabalho no passado, então a equipe usará a mesma abordagem de arquitetura, mas com a tecnologia moderna, Service Bus. A equipe de carga de trabalho não deseja introduzir comunicação síncrona entre a nuvem e a implantação local para mitigar a latência ou a indisponibilidade de uma que afeta a outra.
A equipe decide usar o padrão Messaging Bridge para conectar os dois sistemas. O padrão consiste em duas partes. Uma parte recebe mensagens da fila MSMQ existente e as encaminha para o Service Bus. A outra parte recebe mensagens do Service Bus e as encaminha para a fila MSMQ existente.
Quando a equipe de implementação usa essa abordagem, utiliza a infraestrutura existente no aplicativo existente para se integrar com os novos componentes. O aplicativo existente não está ciente de que os novos componentes estão hospedados no Azure. Da mesma forma, os novos componentes se comunicam com o aplicativo herdado da mesma forma que se comunicam entre si, enviando mensagens do Service Bus. A ponte encaminha mensagens entre os dois sistemas.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
Principais autores:
- Rob Bagby - Brasil | Principal Líder de Conteúdo de Arquitetura
- Kyle Baley - Brasil | Engenheiro de Software
- Udi Dahan - Brasil | Fundador e CEO da Particular Software
- Chade Kittel - Brasil | Engenheiro de Software Principal
- Bryan Lamos - Brasil | Relações com Desenvolvedores
- Szymon Pobiega - Brasil | Engenheira
Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.
Próximos passos
- Descrição do padrão do Messaging Bridge da comunidade de padrões de integração empresarial.
- Saiba como implementar uma ponte de mensagens na estrutura Java do Spring.
- A ponte QPid pode ser usada para unir tecnologias de mensagens habilitadas para AMQP.
- A ponte de mensagens NServiceBus é uma implementação .NET de uma ponte de fila para fila que oferece suporte a uma variedade de infraestruturas de mensagens, incluindo MSMQ, Service Bus e Armazenamento de Filas do Azure.
- NServiceBus.Router é um projeto de código aberto que implementa o padrão Messaging Bridge. Ele também permite unir mais de duas tecnologias em uma única instância e tem recursos avançados de roteamento de mensagens.
Recursos relacionados
- O padrão Consumidores concorrentes garante que a implementação da ponte de mensagens possa lidar com a carga.
- O padrão Retry permite que o Messaging Bridge lide com falhas transitórias.
- O padrão Disjuntor conserva recursos quando ambos os lados da ponte sofrem tempo de inatividade.