Este artigo descreve o padrão Ponte de Mensagens, que é uma técnica que pode ser usada 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 o Enfileiramento de Mensagens da Microsoft (MSMQ), o RabbitMQ, o Barramento de Serviço do Azure e o 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, com vistas a uma melhor relação custo-benefício e facilidade de manutenção.
Os desenvolvedores podem enfrentar esse desafio modificando os sistemas que estão sendo integrados para que se comuniquem utilizando serviços Web baseados em HTTP. Entretanto, essa abordagem tem suas desvantagens, incluindo:
- Os sistemas devem ser modificados com a adição de um cliente HTTP em um lado e um manipulador de solicitações HTTP no outro. Em seguida, os sistemas deverão ser testados novamente e reimplantados.
- Os pontos de extremidade HTTP devem ser hospedados, o que adiciona complexidade quando você torna os serviços da Web seguros e altamente disponíveis.
- Problemas frequentes de conectividade de rede que exigem mecanismos de repetição criados de forma personalizada.
Solução
Se os sistemas que estão sendo integrados consistem em componentes que se comunicam por meio da troca de mensagens, o padrão de Ponte de Mensagens melhora a integração e mitiga as desvantagens.
Nesse cenário, cada sistema conecta-se a uma infraestrutura de mensagens. Para integração entre diferentes infraestruturas de mensagens, introduza um componente de ponte que se conecte a duas ou mais infraestruturas de mensagens ao mesmo tempo. A ponte efetua pull de mensagens de um e as envia por push para o outro sem alterar o conteúdo.
Os sistemas que estão sendo integrados não precisam reconhecer os outros ou a ponte. O sistema remetente é configurado para enviar mensagens específicas para uma fila designada em sua infraestrutura de mensagens nativa. A ponte coleta essas mensagens e as encaminha para outra fila em uma infraestrutura de mensagens diferente, onde o sistema receptor as coleta.
Benefícios
- Os sistemas que estão sendo integrados por meio da Ponte de Mensagens não precisam ser modificados. O ideal é que os pontos de extremidade não estejam cientes de que as mensagens estão em ponte.
- 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 o agendamento permitir, em vez de serem migrados todos de uma 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 de apenas 64 KB nas filas do Armazenamento do Microsoft Azure.
Problemas e considerações
Considere os seguintes pontos ao implementar o padrão de Ponte de Mensagens:
Se um dos sistemas integrados depender de transações distribuídas, como, por exemplo, o Coordenador de Transações Distribuídas (DTC) da Microsoft, para ser correto, você deverá implementar um mecanismo de desduplicação na ponte.
Se um dos sistemas que está sendo integrado não usa nenhuma infraestrutura de mensagens e não pode ser modificado, você poderá criar a Ponte de Mensagens entre a infraestrutura utilizada pelo outro sistema e uma fila emulada no SQL Server. O sistema herdado pode enviar mensagens usando o recurso captura de dados de alterações do SQL Server para enviar suas alterações para uma tabela de fila dedicada. A ponte pode encaminhar essas mensagens para a infraestrutura de mensagens real.
Você pode utilizar uma única fila em cada infraestrutura de mensagens, designada como fila de ponte. Nessa topologia, configure o sistema de envio para utilizar essa fila específica como destino dos tipos de mensagem enviados para outro sistema. Você também pode utilizar vários pares de filas em cada infraestrutura de mensagens, de modo que o remetente não tenha conhecimento da ponte. Um fila de sombra é criada em cada fila de destino na infraestrutura de mensagens do sistema de destino. A ponte encaminha mensagens entre as filas de sombras e suas contrapartes.
Para atender aos contratos de nível de serviço (SLAs) de disponibilidade desejados, talvez seja necessário escalar horizontalmente o Ponte de Mensagens utilizando a abordagem Consumidores concorrentes.
Os componentes regulares de processamento de mensagens utilizam o padrão Repetição para lidar com falhas transitórias. O limite do contador de repetições permite que os componentes detectem mensagens suspeita 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 suspeitas se ocorrer uma falha na infraestrutura. Você pode usar o padrão Circuit Breaker para pausar o encaminhamento.
Quando usar esse padrão
Use o padrão de Ponte de Mensagens quando você precisar utilizar:
- Integra os sistemas existentes com necessidade mínima de modificação.
- Integrar aplicativos herdados que não podem utilizar outras tecnologias de mensagens.
- Amplie os aplicativos existentes no local com componentes hospedados na nuvem.
- Conectar-se a sistemas distribuído geograficamente quando a conexão com a Internet não estiver estável.
- Migrar um único sistema distribuído de uma infraestrutura de mensagens para outra de forma incremental, sem a necessidade de migrar todo o sistema em um único esforço.
Esse 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 na outra.
- A integração é de natureza síncrona, e o sistema iniciador exige resposta imediata.
- A integração tem requisitos funcionais ou não funcionais específicos, como preocupações com segurança ou privacidade.
- O volume de dados para a integração excede a capacidade do sistema de mensagens ou torna o sistema de mensagens uma solução dispendiosa para o problema.
Design de carga de trabalho
Um arquiteto deve avaliar como o padrão Ponte de Mensagens pode ser usado no design das suas cargas de trabalho para abordar os objetivos e os princípios discutidos nos pilares do Azure Well-Architected Framework. Por exemplo:
| Pilar | Como esse padrão apoia os objetivos do pilar |
|---|---|
| A otimização de custos se concentra em sustentar e melhorar o retorno sobre o investimento da sua carga de trabalho. | Essa etapa intermediária pode aumentar a longevidade do sistema existente sem a necessidade de regravações, permitindo a interoperabilidade com sistemas que usam uma tecnologia de mensagens ou eventos diferente. - CO:07 Custos de componentes |
| A Excelência Operacional ajuda a fornecer qualidade na carga de trabalho por meio de processos padronizados e coesão da equipe. | Esse desacoplamento fornece flexibilidade quando você faz a transição da tecnologia de mensagens e eventos em sua carga de trabalho ou quando você tem requisitos heterogêneos direto de dependências externas. - OE:06 Implantando alterações de carga de trabalho |
Tal como acontece com qualquer decisão de design, considere quaisquer compensações em relação aos objetivos dos outros pilares que possam ser introduzidos com este padrão.
Exemplo
Existe um aplicativo escrito em uma estrutura .NET para gerenciar o agendamento de funcionários hospedado no local. 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 criado para atender a uma necessidade de negócios, e a estratégia de TI chama a atenção para a criação de novos softwares como aplicativos nativos da nuvem para otimizar os custos e o tempo de entrega.
A arquitetura assíncrona baseada em filas funcionou para a equipe de carga de trabalho no passado, portanto, a equipe vai utilizar a mesma abordagem arquitetônica, mas com a tecnologia moderna, o Barramento de Serviço do Azure. A equipe de carga de trabalho não deseja introduzir uma comunicação síncrona entre a nuvem e a implantação no local para mitigar a latência ou a indisponibilidade de uma que afete a outra.
A equipe decide utilizar o padrão de Ponte de Mensagens para conectar os dois sistemas. O padrão consiste em duas partes. Uma parte recebe mensagens da fila do MSMQ existente e as encaminha para o Barramento de Serviço do Azure. A outra parte recebe mensagens do Barramento de Serviço do Azure e as encaminha para a fila do MSMQ existente.
Quando a equipe de implementação usa essa abordagem, ela utiliza a infraestrutura existente no aplicativo existente para se integrar aos novos componentes. O aplicativo existente não está ciente de que os novos componentes estão hospedados no Azure. De modo semelhante, os novos componentes se comunicam com o aplicativo herdado da mesma forma que se comunicam entre si, enviando mensagens do Barramento de Serviço do Azure. A ponte encaminha mensagens entre os dois sistemas.
Colaboradores
Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.
Principais autores:
- Rob Bagby | Principal Líder de Conteúdo de Arquitetura
- Kyle Baley | Engenheiro de Software
- Udi Dahan | Fundador & CEO da Particular Software
- Chad Kittel | Engenheiro de Software Principal
- Bryan Lamos | Relacionamento com o Desenvolvedor
- Szymon Pobiega | Engenheiro
Para ver perfis não públicos do LinkedIn, entre no LinkedIn.
Próximas etapas
- Descrição do padrão de Ponte de Mensagens da comunidade de padrões de integração empresarial.
- Saiba como implementar uma Ponte de Mensagens na estrutura do Spring Java.
- A ponte QPid pode ser utilizada para conectar tecnologias de mensagens habilitadas para AMQP.
- A Ponte de Mensagens NServiceBus é uma implementação .NET de uma ponte fila a fila que dá suporte a um intervalo de infraestruturas de mensagens, incluindo MSMQ, Barramento de Serviços do Azure e Armazenamento de Filas do Azure.
- NServiceBus.Router é um projeto de código aberto que implementa o padrão Ponte de Mensagens. Ele também permite a ponte de mais de duas tecnologias em uma única instância e tem capacidades avançadas 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 Repetição permite que a Ponte de Mensagens trate de falhas transitórias.
- O padrão Circuit Breaker conserva os recursos quando um dos lados da ponte passa por um período de inatividade.