• 03/19/2020
• 4 minutos para ler
• • d
  • D
  • a
  • v
  • d
  • +6

  >

O modelo Bulkhead é um tipo de desenho de aplicação que é tolerante a falhas. Em uma arquitetura de anteparo, elementos de uma aplicação são isolados em piscinas para que, se uma falhar, as outras continuem a funcionar. É nomeado após as partições seccionadas (anteparas) do casco de um navio. Se o casco de um navio estiver comprometido, apenas a seção danificada se enche de água, o que evita que o navio se afunde.

Contetexto e problema

Uma aplicação baseada em nuvem pode incluir vários serviços, com cada serviço tendo um ou mais consumidores. Carga excessiva ou falha em um serviço terá impacto em todos os consumidores do serviço.

Além disso, um consumidor pode enviar solicitações para vários serviços simultaneamente, usando recursos para cada solicitação. Quando o consumidor envia uma solicitação para um serviço que está mal configurado ou não responde, os recursos utilizados pela solicitação do cliente podem não ser liberados em tempo hábil. medida que as solicitações para o serviço continuam, esses recursos podem ser esgotados. Por exemplo, o pool de conexões do cliente pode estar esgotado. Nesse momento, os pedidos do consumidor a outros serviços são afetados. Eventualmente, o consumidor não pode mais enviar solicitações para outros serviços, não apenas o serviço original sem resposta.

A mesma questão do esgotamento de recursos afeta os serviços com múltiplos consumidores. Um grande número de solicitações originárias de um cliente pode esgotar os recursos disponíveis no serviço. Outros consumidores não são mais capazes de consumir o serviço, causando um efeito de falha em cascata.

Solução

Partição das instâncias do serviço em diferentes grupos, com base na carga do consumidor e nos requisitos de disponibilidade. Este projeto ajuda a isolar falhas e permite que você mantenha a funcionalidade do serviço para alguns consumidores, mesmo durante uma falha.

Um consumidor também pode dividir recursos, para garantir que os recursos usados para chamar um serviço não afetem os recursos usados para chamar outro serviço. Por exemplo, a um consumidor que chama vários serviços pode ser atribuído um pool de conexões para cada serviço. Se um serviço começar a falhar, ele só afeta o pool de conexões atribuído a esse serviço, permitindo que o consumidor continue usando os outros serviços.

Os benefícios desse padrão incluem:

• Isolar os consumidores e serviços de falhas em cascata. Um problema que afeta um consumidor ou serviço pode ser isolado dentro de seu próprio anteparo, evitando que toda a solução falhe.
• Permite preservar alguma funcionalidade no caso de uma falha no serviço. Outros serviços e recursos da aplicação continuarão a funcionar.
• Permite a implantação de serviços que oferecem uma qualidade de serviço diferente para aplicações consumidoras. Um pool de consumidores de alta prioridade pode ser configurado para usar serviços de alta prioridade.

O diagrama a seguir mostra os anteparos estruturados em torno de pools de conexão que chamam serviços individuais. Se o Serviço A falhar ou causar algum outro problema, o pool de conexões é isolado, de modo que apenas as cargas de trabalho que utilizam o pool de fios atribuído ao Serviço A são afetadas. As cargas de trabalho que usam os Serviços B e C não são afetadas e podem continuar trabalhando sem interrupção.

O próximo diagrama mostra vários clientes chamando um único serviço. A cada cliente é atribuída uma instância de serviço separada. O cliente 1 fez demasiados pedidos e sobrecarregou a sua instância. Como cada instância de serviço está isolada das outras, os outros clientes podem continuar fazendo chamadas.

Issues e considerações

• Definir partições em torno do negócio e requisitos técnicos da aplicação.>
• Considerando a combinação de anteparas com padrões de nova tentativa, disjuntor e estrangulamento para fornecer um manuseio de falhas mais sofisticado.

>

• Ao dividir consumidores em anteparas, considere o uso de processos, tanques de rosca e semáforos. Projetos como resiliência4j e Polly oferecem uma estrutura para a criação de anteparos para consumidores.
• Ao dividir os serviços em anteparos, considere a possibilidade de implantá-los em máquinas, contêineres ou processos virtuais separados. Os contêineres oferecem um bom equilíbrio de isolamento de recursos com despesas gerais bastante baixas.
• Serviços que comunicam usando mensagens assíncronas podem ser isolados através de diferentes conjuntos de filas. Cada fila pode ter um conjunto dedicado de instâncias processando mensagens na fila, ou um único grupo de instâncias usando um algoritmo para separar e despachar o processamento.
• Determinar o nível de granularidade para os anteparos. Por exemplo, se você quiser distribuir locatários em partições, você poderia colocar cada locatário em uma partição separada, ou colocar vários locatários em uma partição.
• Monitorar o desempenho e o SLA de cada partição.

Quando usar este padrão

Utilizar este padrão para:

• Isolar recursos usados para consumir um conjunto de serviços backend, especialmente se o aplicativo puder fornecer algum nível de funcionalidade mesmo quando um dos serviços não estiver respondendo.
• Isolar consumidores críticos de consumidores padrão.
• Proteger o aplicativo de falhas em cascata.

Este padrão pode não ser adequado quando:

• O uso menos eficiente de recursos pode não ser aceitável no projeto.
• A complexidade adicional não é necessária

Exemplo

O seguinte ficheiro de configuração Kubernetes cria um contentor isolado para executar um único serviço, com a sua própria CPU e recursos e limites de memória.