Reliability Patterns
Confiabilidade — é o estudo da probabilidade de um ativo ou sistema falhar durante um determinado tempo sob certas condições de operações.
Ok, e o que é Sistema?
Um sistema (do grego σύστημα systēma, através do latim systēma), é um conjunto de elementos interdependentes de modo a formar um todo organizado. É uma definição que acontece em várias disciplinas, como biologia, medicina, informática, administração, direito… (Wikipedia)
E como posso praticar a Confiabilidade em meus sistemas de tecnologia?
1. a Resiliência - capacidade do seu sistema de reagir a falhas e ainda permanecer funcional. Funciona com um gatilho para voltar meu sistema ao estado desejado.
2. a Antifragilidade, é a capacidade do seu sistema aprender com o descomportamento. Nesta abordagem o sistema aprende e se adapta a novos comportamentos, base evolutiva.
A confiabilidade de manter os resultados integros de um sistema, mesmo que eventualmente ocorram eventos diversos, não se trata de evitar a falhas, mas de aceitar a falha e aprender métodos de manter as coisas funcionando. O Reliability Patterns são métodos de identificar padrões em uma arquitetura para que confiabilidade do sistema seja mantida. Aqui um evemplo que resulta mensagens confiáveis de um sistema, sem impactar o cliente, mesmo que um sistema apresente oscilação na entrega.
Dois exemplos de tais padrões são:
- Retry pattern (como na imagem)
Em um ambiente nativo de nuvem distribuído, as chamadas para serviços e recursos de nuvem podem falhar devido a falhas transitórias (de curta duração), que normalmente se corrigem após um breve período de tempo. A implementação de uma estratégia de repetição ajuda um serviço nativo da nuvem a mitigar esses cenários. O padrão Retry permite que um serviço tente novamente uma operação de solicitação com falha um número (configurável) de vezes com um tempo de espera exponencialmente crescente. - Circuit breaker pattern
Embora o padrão de repetição possa ajudar a salvar uma solicitação emaranhada em uma falha parcial, há situações em que as falhas podem ser causadas por eventos imprevistos que exigirão mais tempo para serem resolvidos. Essas falhas podem variar em gravidade, desde uma perda parcial de conectividade até a falha completa de um serviço. Nessas situações, é inútil para um aplicativo repetir continuamente uma operação que provavelmente não será bem-sucedida.
O padrão Circuit Breaker pode impedir que um aplicativo tente repetidamente executar uma operação que provavelmente falhará. Após um número predefinido de chamadas com falha, ele bloqueia todo o tráfego para o serviço. Periodicamente, ele permitirá uma chamada de teste para determinar se a falha foi resolvida.
Exemplo de Fluxo de Aquisição Confiável (Mulesoft):
O fluxo de aquisição confiável (o lado esquerdo do diagrama) entrega uma mensagem de forma confiável de uma fonte de mensagem que não implementa transações para uma operação de saída de um conector que implementa transações. A operação pode ser de qualquer tipo de terminal transacional, como VM ou JMS. Se o fluxo de aquisição confiável não puder entregar a mensagem, ele garante que a mensagem não seja perdida.
Para conexões baseadas em soquete como HTTP, isso significa retornar uma resposta de “solicitação malsucedida” ao cliente para que o cliente possa tentar novamente a solicitação.
Para conexões baseadas em recursos como Arquivo ou FTP, significa não excluir o arquivo, para que possa ser reprocessado.
O fluxo de lógica do aplicativo (o lado direito do diagrama) entrega a mensagem da fonte de mensagem que usa um conector transacional para a lógica de negócios do aplicativo.
Mensagens confiáveis
Os aplicativos de alta confiabilidade devem ter tolerância zero para perda de mensagens. Isso significa que tanto o Mule subjacente quanto suas conexões individuais precisam ser confiáveis.
Se seu aplicativo usa uma conexão transacional, como JMS, VM ou DB, o sistema de mensagens confiável é garantido pelo suporte integrado para transações no conector. Isso significa, por exemplo, que você pode configurar uma transação em um listener JMS que garante que as mensagens sejam removidas apenas do servidor JMS quando a transação for confirmada. Isso garante que, se ocorrer um erro durante o processamento da mensagem, ela ainda estará disponível para reprocessamento. Em outras palavras, o suporte transacional nesses conectores garante que as mensagens sejam entregues de forma confiável de uma origem para uma operação ou entre processadores dentro de um fluxo.
Se você quiser mover mensagens entre diferentes conectores que dão suporte a transações, use transações XA para garantir que as transações de ambos os conectores sejam confirmadas como uma unidade atômica.
Consulte Gerenciamento de Transações para obter mais informações sobre XA e outros tipos de transações.
Se você tiver um aplicativo da Web que usa um conector não transacional, como HTTP, siga um padrão de confiabilidade para garantir mensagens confiáveis para seu aplicativo.
Comparando endpoints em padrões de confiabilidade
Você pode acoplar o fluxo de aquisição confiável com qualquer tipo de endpoint transacional. Você não precisa usar um endpoint de VM em um padrão de confiabilidade. O diagrama a seguir ilustra um padrão de confiabilidade em que o fluxo de aquisição confiável entrega uma mensagem a um terminal JMS:
O conector de VM usa filas na memória por padrão, o que o torna muito mais rápido do que outros terminais transacionais, como JMS.
A tabela a seguir lista as vantagens e desvantagens de usar terminais VM, JMS e JDBC em um fluxo de aquisição confiável.
Fonte: https://docs.mulesoft.com/mule-runtime/4.4/reliability-patterns
