​

File Transfer

​

Shared Database

​

Remote Procedure Invocation�(..COM.. .NET..SOAP .. REST.. gRPC, middle layers as Api Gateways)

​

Messaging

Messaging Systems

​

Message Chanel

Como um aplicativo se comunica com outro usando mensagens?

​

Message

Como duas aplicações conectadas por um canal de mensagens podem trocar uma informação?

​

Pipes and Filter

Como podemos dividir um processamento complexo em tarefas menores mantendo independência e flexibilidade?

​

Message Router

Como você pode desacoplar as etapas de processamento individuais para que as mensagens possam ser passadas para diferentes filtros, dependendo de um conjunto de condições?

​

Message Translator

Como os sistemas que usam diferentes formatos de dados podem se comunicar uns com os outros usando mensagens?

​

Message Endpoint

Como um aplicativo se conecta a um canal de mensagens para enviar e receber mensagens?

Message Construction

​

Command Message

Como as mensagens podem ser usadas para invocar um procedimento em outro aplicativo?

​

Document Message

Como as mensagens podem ser usadas para transferir dados entre aplicativos?

​

Event Message

Como as mensagens podem ser usadas para transmitir eventos de um aplicativo para outro?

​

Request-Reply

Quando um aplicativo envia uma mensagem, como ele pode obter uma resposta do remetente?

​

Correlation Identifier

Como um solicitante que recebeu uma resposta sabe para qual solicitação essa resposta é?

​

Message Sequence

Como as mensagens podem transmitir uma quantidade arbitrariamente grande de dados ou fazer parte de um grupo de mensagens?

Cenário: Inventário de Produtos

Document Message:

Produto (Estado inteiro em um dado momento de tempo) �Nome:Malte�Categoria:Insumo�Tipo:Ingrediente�Fabricação: 12/05/2023

Event Message

ProdutoInserido�ProdutoDescontinuado

Command Message

AdicionarProduto�DesabilitarProduto�DeletarProduto

Query Message

ObterProduto

Pattern

Implementação

Document Message:

Transferir uma estrutura de dados

​

Conteúdo é mais importante do que tempo

Sem instruções ao receptor

Pode ser implementada como uma mensagem que transmitida por Filas e Tópicos, utilizando por exemplo Azure Service Bus como Channel de Mensagens .

Command Message:

Contém uma instrução clara e geralmente tem um receptor específico

Acoplamento remetente ao receptor

Dada a natureza unidirecional de uma mensagem de comando filas são mais adequadas como canais de mensagens para transmiti-los

Pattern

Implementação

Event Message:

Notifica algo que aconteceu sobre um objeto�Descrição do que aconteceu mas não o estado completo*�O tempo geralmente é um fator importante

Geralmente consumida por Event-Driven Consumer

Tópico Azure Event Grid

�Através de uma exchange do Rabbit��Em um tópico do Kafka

Query Message:

Instruir o receptor sobre que informações devem ser retornadas ao chamador.

Acoplamento do remetente com o receptor

Da mesma forma que a mensagem de comando , as filas são mais adequadas como canais de mensagens para transmiti-los.

Pattern

Implementação

Message Sequence:

Quantidade de dados a serem transmitidos não cabem em uma única mensagem, por conta do tamanho ou outras restrições ou mensagem que tenham dependência de outras mensagens e precisam ser processadas em uma determinada sequência

• Sequence Identifier : para distinguir o grupo de mensagens.
• Position Identifier: para ordenar cada mensagem em uma sequência
• Size or End Indicator: para indicar o número de mensagens do grupo ou identificar a última mensagem do grupo.

O Azure Service Bus permite implementar o Sequence Pattern usando o cabeçalho da sessão SessionId como identificador de sequência. ��Para Position Identifier, podemos usar o cabeçalho SequenceNumber

​

Size or End poder ser definidos através de custom properties�

​

​

Messaging Channels

​

Point-to-Point Channel

Como o remetente pode ter certeza de que exatamente um destinatário receberá o documento ou realizará a chamada?

​

Publish-Subscribe Channel

Como o remetente pode transmitir a mensagem para vários receptores interessados?

​

Invalid Message Channel

Como um destinatário de mensagens pode lidar com o recebimento de uma mensagem que não faz sentido?

​

Dead Letter Channel

O que o sistema de mensagens fará com uma mensagem que não pode entregar?

​

Guaranteed Delivery

Como o remetente pode ter certeza de que uma mensagem será entregue, mesmo que o sistema de mensagens falhe?

​

Messaging Bridge

Como vários sistemas de mensagens podem ser conectados de modo que as mensagens disponíveis em um também estejam disponíveis nos outros?

​

Message Filter

Como podemos evitar que mensagens não relevantes sejam entregues?

​

Scatter-Gather

Como você mantém o fluxo geral de mensagens quando uma mensagem precisa ser enviada para vários destinatários, cada um dos quais pode enviar uma resposta?

​

Content-Based Router

Como implementamos o roteamento dinâmico com base no conteúdo ou nos cabeçalhos de uma mensagem?

​

Splitter

Como podemos processar uma mensagem se ela contém vários elementos, cada um dos quais deve ser processado de maneira diferente?

​

Recipient List

Como podemos deixar a mensagem definir a lista de receptores dinamicamente?

​

Aggregator

Como combinamos os resultados de mensagens individuais, mas relacionadas, para que possam ser processadas como um todo?

​

Resequencer

Como podemos colocar um fluxo de mensagens relacionadas, mas fora de sequência, de volta na ordem correta?

Pattern

Number of Messages Consumed

Number of Messages Published

Stateful?

Content-Based Router

1

1

No (mostly)

Message Filter

1

0 or 1

No (mostly)

Recipient List

1

multiple (incl. 0)

No

Splitter

1

multiple

No

Aggregator

multiple

1

Yes

Resequencer

multiple

multiple

Yes

Desafio

Patterns

Como definir e estruturar minhas mensagens?

​

Que dados devo incluir?

Document Message

Event Message

Command Message

Query Message

Desafios

Patterns

Como podemos identificar quando as mensagens devem ser processadas como parte de um grupo e em uma determinada sequência?��Como transmitir uma quantidade grande, arbitrária de dados?

Message Sequence

Desafio

Patterns

Devemos implementar uma interface direta entre o emissor e o receptor das nossas mensagens ou remetente não precisa ter ciência nenhuma do destinatário?

Point-to-Point Channel

Publish-Subscribe Channel

Pattern

Implementação

Point-to-Point Channel :

Remetente está ciente de um destinatário que deve receber e processar a mensagem. É comum que Mensagens de Comando ou Mensagens de Consulta�

​

Uma fila deve ter apenas um consumidor, dessa forma é comum que o remetente que coloca a mensagem na fila esteja ciente do destinatário.�

Azure Service Bus Queue

Publish-Subscribe Channel

Permite enviar uma mensagem para todos os receptores interessados ​​disponíveis (assinantes). Nesse padrão, o remetente não precisa saber quem está assinando as mensagens, cada um dos assinantes ativos terá sua cópia de cada mensagem.

Azure Service Bus �Azure Event Grid�Kafka�RabbitMQ

Desafio

Patterns

Como o aplicativo destinatário deve receber a mensagem?

Ele precisa receber a mensagem do canal ou o canal deve enviar a mensagem para ele?

​

Push-Pull Channel (*)

Push-Push Channel (*)

​

Pattern

Implementação

A Push-Pull Channel

É um canal de mensagens que não pode enviar mensagens para os aplicativos receptores pretendidos. Assim, cabe ao aplicativo receptor puxar as mensagens do canal. Esse tipo de canal se encaixa bem com o consumidor de pesquisa.

​

Azure Service Bus��Tópicos do Kafka

Push-Push �É um canal de mensagens capaz de enviar mensagens para os aplicativos receptores pretendidos. Assim, o aplicativo receptor deve ser capaz de receber as mensagens e estar disponível. Esse padrão de Canal de Mensagens se ajusta bem ao Consumidor Orientado a Eventos. Além disso, os Canais Push-Push são ideais para Mensagens de Evento

O Azure Event Grid é um Canal Push-Push ideal para Mensagens de Evento. ��Dado que o Event Grid envia as mensagens para o aplicativo receptor pretendido, o aplicativo deve estar disponível.

Event Grid oferece retries configuráveis e dead-lettering

Desafio

Patterns

Como gerenciamos as mensagens inválidas que passam pelo canal?�

Onde armazenamos mensagens quando elas não podem mais ser processadas pelo destinatário pretendido?

Invalid Message Channel

Dead-Letter Channel

​

Pattern

Implementação

Invalid Message Channel

O canal de mensagens inválidas é um canal para o qual um canal de mensagens ou o aplicativo receptor pode entregar essas mensagens inválidas de maneira elegante sem perdê-las.

De valores obrigatórios ausentes a valores inválidos, a uma estrutura de mensagem inválida e a tipos de mensagem inválidos. Em todos esses casos, não adianta tentar novamente o processamento da mensagem, pois ela continuará falhando nas validações.

Azure Service Bus Queues and Topics , há uma subfila de Dead-Letters, mas não uma subfila separada de Mensagens Inválidas. No entanto, podemos usar os campos DeadLetterReason e DeadLetterErrorDescription para especificar a causa do envio da mensagem para a subfila. Dado que o Barramento de Serviço não fornece Validação de Mensagem (*), isso deve ocorrer no aplicativo receptor e esse aplicativo seria responsável por mover a mensagem para a subfila correspondente ao especificar o motivo..��Quando o Event-Grid tenta entregar um evento e recebe um código de resposta Http 400 (Bad Request) ou Http 413 (Request Entity Too Large) do receptor, ele imediatamente envia o evento para o ponto final de mensagens mortas. A Validação de Mensagem (*) deve ocorrer no aplicativo receptor e esse aplicativo deve retornar o código de status Http correspondente para a Grade de Eventos. No momento da redação, a grade de eventos oferece suporte apenas para gravar mensagens inválidas em um blob, que não pode ser considerado um canal de mensagens adequado. Então cabe à solução ou ao administrador puxar esses eventos para resolver as entregas.

Dead Letter Channel

​

No padrão anterior, descrevemos como lidar com mensagens que não podem ser processadas quando a mensagem é inválida. Mas, e se a mensagem for válida, mas não puder ser entregue ao destinatário pretendido? Isso pode acontecer por vários motivos, desde a indisponibilidade do destinatário, a uma falha de comunicação com o destinatário, a não ser capaz de identificar o destinatário, a uma mensagem expirada. Quando o canal não pode entregar a mensagem, deve haver uma maneira elegante de remover a mensagem da fila ou assinatura do tópico e deixá-la em outro lugar para um tipo diferente de processamento ou solução de problemas. Este é o propósito de um Dead Letter Channel.

​

​

Barramento de Serviço do Azure fornece uma subfila de mensagens mortas e subassinaturas para que as mensagens que não podem ser entregues possam ser movidas para lá. As mensagens também podem ser movidas para a letra morta se seu TimeToLive for excedido ou quando todas as novas tentativas (MaxDeliveryCount) forem esgotadas.

Desafio

Patterns

Como podemos ter certeza de que uma mensagem é entregue ao destinatário pretendido?

Como podemos garantir que tentativas de entrega repetidas não tenham um impacto negativo na integridade ou no desempenho do destinatário pretendido?

​

Guaranteed Delivery

Circuit Breaker (*)

​

Pattern

Implementação

Guaranteed Delivery

Quando o destinatário não está disponível ou acessível através da rede, o sistema de mensagens pode armazenar a mensagem e tentar entregá-la novamente até que o destinatário esteja acessível ou disponível. Para fazer isso, o canal de mensagens não deve apenas ter a mensagem na memória, mas também persisti-la no disco para que a mensagem sobreviva a uma falha no canal.

​

​

Event Grid oferece suporte a novas tentativas de entrega de eventos aos aplicativos receptores. Ele implementa a política de retirada exponencial para evitar a sobrecarga de endpoints não saudáveis ​​ou minimizar o tráfego quando o endpoint fica inativo por um longo período. No entanto, no momento em que escrevo, ele tenta novamente em até 24 horas.

��

​

O padrão Circuit Breaker �pode impedir sistemas downstream sejam sobrecarregados com mensagens que provavelmente falharão devido à indisponibilidade ou ao status não íntegro do sistema downstream. Ao implementar esse padrão, a solução deve ser capaz de detectar falhas no aplicativo receptor e interromper o envio de mensagens quando é improvável que sejam processadas com sucesso. Ao mesmo tempo, a solução deve detectar quando a falha foi resolvida para que possa retomar o envio das mensagens em fila.

​

​

Esse padrão não é um recurso interno de nenhum dos Serviços de Integração do Azure. No entanto, Jeff Hollan, gerente de programa da equipe Azure maneira de implementar esse padrão usando Aplicativos Lógicos e Azure Functions. A solução descrita em sua postagem depende do cache Redis como um estado compartilhado em todas as instâncias (consumidores concorrentes) que processam as mensagens e um aplicativo lógico como um gerenciador de processos que pode gerenciar o estado do circuito (aberto ou fechado). A solução descrita usa Hubs de Eventos, mas pode ser facilmente implementada com o Barramento de Serviço do Azure.

​

Desafio

Patterns

Como um cliente pode controlar suas Como implementamos transações para que as mensagens não sejam perdidas no processo de envio ou recebimento de uma mensagem para ou de um canal?

Transactional Client

​

Pattern

Implementação

Transactional Client

é a implementação de limites de uma transação atômica para que as mensagens não sejam perdidas no processo de envio ou recebimento. O escopo da transação também pode ir além, por exemplo:

​

• Database to Message:so that the object is not marked as processed or deleted on the sender application’s database until it has been successfully sent to the Messaging Channel.
• para que o objeto não seja marcado como processado ou excluído no banco de dados do aplicativo remetente até que seja enviado com sucesso
• Message to Database:
• para que a mensagem não seja excluída do canal de mensagens até que seja confirmada no banco de dados de destino no aplicativo receptor.
• ​
• this can easily be implemented using Service Bus, a Logic App workflow, and a Logic App connector. The Logic App workflow trigger would be a Peek-Lock on the Service Bus queue or topic subscription. Later, the workflow will try to deliver the message to the receiver application. Only if the delivery is successful, the message is completed on Service Bus, otherwise, the message will be abandoned so that a new instance of the workflow can retry later. This pattern was described in detail in the previous post, in the Guaranteed Delivery pattern.
• Message Groups: A Logic App workflow can be implemented to receive all messages within a session from a Service Bus queue or topic subscription and only commit the transaction if all messages have been received and processed successfully.
• Receive-Send Message Pairs: To implement this pattern, a Logic App workflow could be utilised, so a message is not completed on a queue or topic subscription until a correlated message is successfully sent to another queue or topic.
• Send-Receive Message Pairs: This pattern can be implemented on a Logic App workflow, implementing the Request-Reply pattern, either using the webhook action, or Service Bus sessions, and not committing or completing the request message, until the reply is received.

​

Desafio

Patterns

Como podemos processar várias mensagens ao mesmo tempo com vários workers no aplicativo receptor?��Como podemos controlar quantas mensagens são processadas em um determinado momento com base nos requisitos ou na capacidade do receptor?

Competing Consumers�

Throttled Consumer (*)

Singleton Consumer (*)

​

Pattern

Implementação

Competing Consumers

é a implementação de limites de uma transação atômica para que as mensagens não sejam perdidas no processo de envio ou recebimento. O escopo da transação também pode ir além, por exemplo:��Ao consumir mensagens de uma fila, ter um único trabalhador de processamento pode resultar em mensagens sendo empilhadas no canal, o que pode afetar a taxa de transferência. Ter consumidores concorrentes processando mensagens em paralelo de um canal permite reduzir gargalos e aumentar o rendimento. Ter vários consumidores trabalhando em paralelo pode trazer o risco de processar a mesma mensagem várias vezes. Para evitar isso, duas abordagens podem ser usadas: ��Destructive Read Leitura Destrutiva: significa que uma vez que uma mensagem é capturada por um dos consumidores, a mensagem é imediatamente removida do canal. Essa abordagem é muito simples, porém, não muito resiliente. As mensagens podem ser perdidas se ocorrer uma falha.

�Non-destructive Read: para minimizar o risco de perda de mensagens em caso de falhas, uma mensagem pode ser mantida trancada no canal após ser captada, para que nenhum outro consumidor possa pegá-la. Em seguida, a mensagem pode ser removida depois de processada com sucesso, o bloqueio pode ser renovado se o processamento estiver demorando mais do que a duração do bloqueio ou a mensagem pode ser desbloqueada se ocorrer uma falha temporária para que possa ser processada novamente por qualquer um dos os Consumidores Concorrentes.

Logic Apps implementam o padrão Consumidor Competitivo com Barramento de Serviço pronto para uso. Por padrão, o fluxo de trabalho será expandido para várias instâncias para processar várias mensagens em paralelo. Os aplicativos lógicos permitem que você implemente uma abordagem de leitura destrutiva com o gatilho de barramento de serviço de preenchimento automático e a leitura não destrutiva com o gatilho de barramento de serviço Peek-lock.

��Azure Functions implementam o padrão de consumidores concorrentes com barramento de serviço pronto para uso. Por padrão, a função será expandida para várias instâncias para processar várias mensagens em paralelo.

​

Pattern

Implementação

Throttled Consumer

Nas soluções cloud native ter consumidores concorrentes é quase sempre a norma.no entanto, podemos querer ter um número limitado de instâncias de nossos workers de processamento consumindo as mensagens disponíveis. Esse requisito é comum quando precisamos evitar sobrecarregar um aplicativo receptor com mais solicitações do que ele pode atender.��Singleton Consumer�é necessário quando o aplicativo receptor deve ou pode manipular apenas uma mensagem por vez��Processamento em ordem: se soubermos que as mensagens em uma fila são sequenciadas e precisarmos processá-las nessa ordem, precisaremos garantir que apenas um trabalhador esteja processando essas mensagens em um determinado momento. No entanto, confiar apenas na abordagem FIFO (primeiro a entrar, primeiro a sair) nas filas tem limitações para o processamento ordenado. Por exemplo, precisamos ter certeza de que as partições estão alinhadas com os requisitos de sequenciamento e devemos estar cientes de que a mensagem head-of-queue pode bloquear toda a fila se seu processamento estiver demorando, especialmente ao usar novas tentativas��Limitação de processamento: Alguns aplicativos podem manipular apenas uma mensagem por vez. Isso pode não ser verdade para aplicativos em nuvem, mas pode ser o caso em aplicativos legados.

Logic Apps ipermitem que você tenha controle de simultaneidade para que você possa limitá-los a ter apenas um número limitado de instâncias de um fluxo de trabalho em execução ao mesmo tempo. Outras mensagens aguardarão até que a instância em execução conclua sua execução.

��Azure Functions suporte ao controle do grau de paralelismo, mas com algumas limitações

��Os Aplicativos Lógicos do Azure permitem que você tenha controle de simultaneidade para que você possa limitá-los a ter apenas uma instância de um fluxo de trabalho em execução ao mesmo tempo. Outras mensagens aguardarão até que a instância em execução conclua sua execução.��Azure Functions dá suporte ao controle do grau de paralelismo, mas com algumas limitações, conforme descrito nas postagens a seguir: (1), (2) e (3).