← Microservices: desenhar fronteiras e operar sistemas distribuídos
12 / 12 · 70 MIN

Isolamento de capacidade e limites partilhados

Compara um pool partilhado com reservas separadas e identifica dependências que continuam a juntar os caminhos.

Comparar mantendo o orçamento

O primeiro ensaio tinha dois lugares partilhados. O segundo mantém dois lugares totais, mas atribui um ao batch e outro à operação crítica. Mantém o batch retido no seu Event e deixa a operação crítica concluir. Assim, a comparação não atribui o resultado a um aumento escondido de capacidade. O guião observa o batch ainda ativo quando confirma a conclusão crítica. Esta é uma demonstração de admissão local; todos os workers continuam no mesmo processo e máquina. O desenho não reserva CPU, memória ou ligações reais a uma base de dados. Usa a observação para formular uma hipótese sobre isolamento que depois possa ser testada no sistema de destino.

Explicar o custo da reserva

Depois da consulta crítica terminar, o seu lugar está livre. Um segundo batch continua a ser rejeitado porque o pool batch está cheio e não existe empréstimo entre pools. Esse resultado é intencional: a reserva mantém capacidade para o próximo pedido crítico. Também significa que a utilização total pode ser inferior à de um pool partilhado. Na decisão de projeto, relaciona esse custo com os objetivos de disponibilidade e a distribuição da carga. Se a equipa propuser empréstimo temporário, precisa de definir recuperação da reserva e comportamento dos jobs já admitidos. O presente laboratório não implementa preempção, empréstimo ou garantias de prioridade.

Seguir a dependência comum

Um terceiro caso representa duas admissões de entrada separadas que convergem num lugar downstream comum. O batch adquire o seu lugar e o lugar downstream. A operação crítica adquire a sua reserva de entrada, mas não consegue adquirir o recurso seguinte. Os três contadores são locais e o caso não abre qualquer ligação a uma base de dados. O objetivo é tornar explícita a fronteira que continua partilhada. Num mapa operacional, segue ligações, locks, filas e limites de chamadas até ao serviço dependente. Aprovar apenas os pools de entrada deixa por demonstrar o comportamento das camadas que podem voltar a unir os caminhos.

Separar concorrência, taxa e fila

O guião executa doze jobs sequenciais num pool com um lugar. Todos entram e terminam; peak permanece em um e admitted chega a doze. Não mede pedidos por segundo nem impõe um limite temporal. Este resultado impede interpretar um limite de concorrência como quota de taxa. Também não existe uma fila de espera no caminho de rejeição: a tentativa falhada não cria worker. Ao desenhar uma solução real, especifica separadamente trabalho simultâneo, entradas por intervalo e quantidade máxima de pedidos em espera. Inclui o tempo útil restante antes de consumir capacidade com um pedido que já perdeu valor para o consumidor.

Planear cancelamento sem o inventar

Os workers deste guião só terminam ao libertar o Event, encontrar o erro injetado ou atingir a proteção do ensaio. Não recebem um sinal de cancelamento do chamador. Uma solução cooperativa precisaria de um contrato sobre quem sinaliza, onde o worker verifica e que ações podem já ter ocorrido. A confirmação de cancelamento deve distinguir pedido recebido de trabalho realmente parado. Se houver efeitos duráveis, a reconciliação e a identidade da operação continuam relevantes. Não extrapoles join com timeout para afirmar que uma biblioteca ou uma base de dados concreta cancela pedidos. Acrescenta testes dessa biblioteca e observações no destino antes de fazer tal afirmação.

Definir evidência para o handover

Para um handover fictício de APS, entrega um desenho dos pools, limites por dependência, significado das rejeições e procedimento de recuperação. Mostra tanto a consulta crítica durante saturação batch como a recuperação depois de retirar a carga. Compara capacidade total, mistura de pedidos e critérios de sucesso entre versões. O relatório local inclui doze grupos, hash do guião e contagem de threads terminadas; não substitui métricas de uma aplicação representativa. Acrescenta responsáveis, alertas, critérios de reversão e revisão conjunta de desenvolvimento e operações. A aprovação deve indicar precisamente o que foi observado e deixar testes de carga, segurança e revisão humana ainda não realizados como trabalho pendente.

python3 content/labs/micro-capacity/run.py --output /tmp/dr-capacity-new-run.json
# Use a new output path for each run; existing reports are not overwritten.
NA PRÁTICA

Um lugar reservado permite concluir a consulta crítica enquanto o batch permanece retido; uma dependência comum pode voltar a bloquear ambos.

Armadilhas comuns

Tratar dois semáforos como isolamento de CPU; emprestar reservas sem contrato; confundir concorrência com taxa; declarar cancelamento sem confirmação.

Tópicos relacionados: Capacity planning · Disponibilidade e dependências

Leva esta ideia contigo

Uma reserva protege apenas o recurso que controla. A aceitação deve seguir o caminho inteiro e mostrar recuperação, custos e efeitos no consumidor.

Criar conta

Referência: Bulkhead pattern · Microservice architecture patterns and scoped platform examples; primary guidance consulted 2026-09-30