Luiz Schons – Microservices

Design for Failure: como assim meu sistema falha?

Thu, 15 Oct 2026 00:00:00 -0300

Todo sistema falha. A pergunta não é se um serviço vai cair, é o que acontece com o resto quando ele cair. Esse é o assunto da minha palestra Design for Failure, que apresentei na SoftWeek e no PHPeste em 2025, e este artigo é a versão escrita dela, com um pouco mais de espaço para os detalhes que não cabem em 40 minutos de palco.

A ideia da palestra é simples: dar nome aos padrões que a gente já usa, às vezes sem saber. Retry, fallback, circuit breaker e saga não são invenções recentes, e entender de onde vem cada um ajuda a saber quando usar, e principalmente quando não usar.

Um aviso antes de começar: todo código aqui é didático. Ele existe para mostrar a ideia, não para ir direto para produção. Para isso existem bibliotecas testadas, que eu cito no caminho.

De um servidor para muitos pontos de falha

Toda loja virtual começa do mesmo jeito: um servidor, uma aplicação e um banco de dados. Enquanto o servidor usa 20% da capacidade, está tudo bem. Aí a loja cresce, o uso vai para 80%, e é hora de escalar. Existem duas formas de fazer isso:

Vertical: você melhora o equipamento que já tem. Mais CPU, mais memória, um servidor maior. É simples, mas tem um teto e fica caro rápido.
Horizontal: você aumenta o número de equipamentos. Mais servidores, containers, um Kubernetes orquestrando tudo. Não tem um teto tão claro, mas agora o sistema é distribuído.

E é no sistema distribuído que você começa a perceber que existem muitos pontos de falha. Uma chamada entre dois serviços pode demorar demais, o outro lado pode ter caído, pode ter um lock segurando um recurso. Cada seta num diagrama de arquitetura é uma chamada de rede, e toda chamada de rede pode falhar.

Para o resto do artigo, vamos usar uma loja dividida em serviços. Uma compra passa pelo e-commerce, que fala com o estoque, com o frete e com o pagamento. Se todo mundo responde, o cliente recebe um 200 OK. Mas e se o serviço de frete estiver fora do ar?

Retry: tentar de novo, do jeito certo

A resposta mais natural é tentar de novo. Muitas falhas em rede são temporárias: um pacote perdido, um timeout num momento de pico, um container reiniciando. A segunda tentativa, alguns instantes depois, muitas vezes funciona.

Essa ideia é dos anos 70 e 80, quando as primeiras redes compartilhadas precisavam lidar com colisões: a Ethernet, por exemplo, sorteia quanto esperar antes de transmitir de novo, num intervalo que dobra a cada colisão. É daí que vêm os dois ingredientes de um bom retry:

Backoff exponencial: o tempo de espera aumenta a cada tentativa (1 s, 2 s, 4 s, 8 s…). Assim você não fica martelando um serviço que já está com dificuldade.
Jitter: um pouco de aleatoriedade nesse tempo (por exemplo, 4 s ± 20%). Parece detalhe, mas é o que evita que todos os clientes tentem de novo no mesmo instante.

Em PHP, com Guzzle, fica assim:

use GuzzleHttp\Exception\ConnectException;
use GuzzleHttp\Exception\ServerException;

public function callShipping(array $data): array
{
 $maxAttempts = 3;

 for ($attempt = 1; ; $attempt++) {
 try {
 $response = $this->httpClient->post('http://shipping/api/quote', [
 'json' => $data,
 'timeout' => 2,
 ]);

 return json_decode((string) $response->getBody(), true);
 } catch (ConnectException | ServerException $e) {
 if ($attempt === $maxAttempts) {
 throw $e;
 }

 $backoffMs = 1000 * 2 ** ($attempt - 1); // 1 s, 2 s, 4 s...
 $jitter = random_int(-20, 20) / 100; // ±20%
 usleep((int) ($backoffMs * (1 + $jitter) * 1000));
 }
 }
}

Repare no que não é retentado. O catch pega só falha de conexão e erro 5xx, que são os casos em que tentar de novo pode dar certo. Um 4xx, como um 400 ou um 422, significa que o pedido está errado, e mandar o mesmo pedido três vezes só gera três erros.

Três cuidados que valem para qualquer retry:

Só repita o que é idempotente. Retentar uma consulta de frete é seguro. Retentar uma cobrança, sem uma chave de idempotência, pode cobrar o cliente duas vezes, porque a primeira tentativa pode ter funcionado e só a resposta se perdeu.
Conte o tempo total. Com timeout de 2 s e esperas de 1 s e 2 s, o pior caso são 9 segundos. Alguém está esperando do outro lado.
No PHP-FPM, esperar custa um processo. Aquele usleep segura um worker parado sem fazer nada. No Swoole e no Hyperf, a mesma chamada só pausa a corrotina, e o processo segue atendendo outras requisições.

Thundering herd: quando o retry piora tudo

Agora imagine mil clientes chamando o mesmo serviço no momento em que ele cai. Todos falham juntos, todos esperam 1 segundo, e todos tentam de novo juntos. O serviço, que estava tentando se recuperar, recebe mil requisições no mesmo instante e cai de novo. Isso tem nome: thundering herd, a manada trovejante.

O jitter é exatamente o que quebra essa sincronia. Simulei os mil clientes com e sem ele:

Sem jitter, o serviço recebe 1.000 requisições em 100 ms, três vezes seguidas. Com ±20%, o pico cai para 271. É o mesmo número de tentativas, só que espalhadas. E quanto mais aleatoriedade, mais espalhado: sortear a espera inteira entre zero e o backoff, o chamado full jitter, baixa o pico ainda mais.

Fallback: uma resposta alternativa

O retry resolve falhas rápidas. Mas e quando o frete fica fora do ar por dez minutos? Tentar três vezes e devolver erro para o cliente significa que nenhuma compra fecha nesse período, por causa de um único serviço.

É aqui que entra o fallback, uma ideia que ganhou força nos anos 90 e 2000 junto com os conceitos de alta disponibilidade e graceful degradation: quando um serviço crítico falha, o sistema não para inteiro, ele devolve uma resposta alternativa. Pode ser um valor padrão, uma resposta em cache ou um valor calculado antes.

No exemplo da loja, se o frete não responde, dá para usar o último valor calculado para aquele CEP ou um frete padrão:

private const DEFAULT_SHIPPING = ['price' => 29.90, 'days' => 10];

public function shippingQuote(array $data): array
{
 try {
 return $this->callShipping($data);
 } catch (ConnectException | ServerException $e) {
 $this->logger->warning('Shipping unavailable, using fallback', [
 'error' => $e->getMessage(),
 ]);

 return $this->cache->get("shipping:{$data['zip']}", self::DEFAULT_SHIPPING);
 }
}

A compra continua. O cliente talvez pague um frete um pouco diferente, mas consegue comprar.

Duas coisas importantes sobre fallback:

Ele é uma decisão de negócio, não só técnica. Um frete padrão pode sair mais caro para a loja do que o real, e alguém precisa concordar com isso. E nem tudo tem fallback: não existe “pagamento padrão”.
Passar pelo fallback nunca é um bom sinal. Ele mantém o sistema de pé, mas esconde o problema. Por isso o log ali dentro não é enfeite: todo fallback precisa de métrica e alerta, senão o frete pode ficar fora do ar uma semana sem ninguém perceber.

Circuit breaker: parar de bater em cachorro morto

Com retry e fallback, o cliente é atendido. Mas olhe o que está acontecendo por baixo: a cada compra, o e-commerce tenta o frete três vezes, espera os timeouts, e só aí vai para o fallback. Multiplique isso por todas as compras e o serviço de frete, que caiu, continua recebendo uma enxurrada de chamadas. É bater em cachorro morto: ninguém ganha nada, e ainda atrapalha a recuperação.

O ideal seria o serviço de frete poder dizer “para de tentar aí, ainda tô me recuperando”. Como ele não pode, quem chama precisa perceber sozinho. Essa é a função do circuit breaker, inspirado nos disjuntores elétricos e popularizado pelo livro Release It!, de Michael Nygard, em 2007. Quando a falha passa de um limite, o disjuntor “desarma” e corta as chamadas por um tempo.

Ele tem três estados:

CLOSED: o normal. As chamadas passam, e as falhas são contadas.
OPEN: as falhas chegaram ao limite. Nenhuma chamada sai; tudo vai direto para o fallback, sem esperar timeout. O serviço do outro lado ganha um respiro.
HALF-OPEN: passou o tempo de espera. Uma chamada de teste é liberada. Se der certo, o circuito fecha e a vida segue. Se der errado, abre de novo e a contagem recomeça.

Uma versão enxuta em PHP:

enum CircuitState
{
 case Closed;
 case Open;
 case HalfOpen;
}

final class CircuitBreaker
{
 private CircuitState $state = CircuitState::Closed;
 private int $failures = 0;
 private ?int $openedAt = null;

 public function __construct(
 private int $threshold = 5, // falhas seguidas para abrir
 private int $cooldown = 60, // segundos até liberar um teste
 ) {}

 public function canExecute(): bool
 {
 if ($this->state === CircuitState::Open
 && time() - $this->openedAt >= $this->cooldown) {
 $this->state = CircuitState::HalfOpen; // libera uma chamada de teste
 return true;
 }

 return $this->state === CircuitState::Closed;
 }

 public function onSuccess(): void
 {
 $this->failures = 0;
 $this->state = CircuitState::Closed;
 }

 public function onFailure(): void
 {
 $this->failures++;

 if ($this->state === CircuitState::HalfOpen || $this->failures >= $this->threshold) {
 $this->state = CircuitState::Open;
 $this->openedAt = time();
 }
 }
}

E o uso, juntando com o retry e o fallback:

public function shippingQuote(array $data): array
{
 if (! $this->breaker->canExecute()) {
 return $this->shippingFallback($data);
 }

 try {
 $quote = $this->callShipping($data); // já com retry
 $this->breaker->onSuccess();

 return $quote;
 } catch (ConnectException | ServerException $e) {
 $this->breaker->onFailure();

 return $this->shippingFallback($data);
 }
}

Com o circuito aberto, a compra não espera mais nove segundos para cair no fallback: ela vai direto. O cliente é atendido mais rápido e o frete para de apanhar.

Um detalhe que pega muita gente no PHP: onde esse estado mora? No PHP-FPM, cada requisição começa do zero, então um objeto CircuitBreaker em memória esquece tudo ao final de cada requisição e nunca abre. O estado precisa ficar num lugar compartilhado, como Redis ou APCu. No Swoole e no Hyperf, o processo continua vivo entre requisições, e o estado em memória funciona por worker. O Hyperf, inclusive, já tem componentes prontos para isso, o hyperf/retry e o hyperf/circuit-breaker.

E, como no fallback, um circuito abrindo é um evento que alguém precisa ver. Ele deve gerar alerta e aparecer no seu monitoramento.

Saga: e a consistência?

Até aqui, cada padrão lidou com uma chamada que falha. Mas uma compra é um conjunto de passos: reservar o estoque, cobrar o pagamento, agendar a entrega. E se o estoque foi reservado e o pagamento cobrado, mas a entrega falhou?

Num banco de dados só, isso seria uma transação: ou tudo acontece, ou nada acontece. Mas cada serviço tem o seu banco, e não existe uma transação que abrace todos eles. A resposta para isso é a saga, descrita por Hector Garcia-Molina e Kenneth Salem em 1987: uma sequência de transações locais em que cada ação tem a sua compensação correspondente. Reservou estoque? A compensação é liberar a reserva. Cobrou? A compensação é estornar.

Para o usuário, a operação parece atômica, mas tecnicamente a consistência é eventual. O sistema garante o “tudo ou nada” não por uma transação de verdade, mas pela capacidade de desfazer cada passo se o processo falhar.

Existem duas formas principais de coordenar uma saga:

Coreografada

Ninguém coordena: cada serviço reage a eventos e publica os seus. Quando algo falha, quem percebe publica um evento, e cada serviço desfaz a própria parte. Na palestra usei o event dispatcher do Hyperf para o exemplo ficar curto. Entre serviços diferentes, esse evento viaja por um broker como Kafka ou RabbitMQ, e o listener vira um consumidor.

Quem percebe a falha publica o evento:

} catch (ConnectException | ServerException $e) {
 $this->breaker->onFailure();

 $this->eventDispatcher->dispatch(new OrderCancelled(
 orderId: $data['order_id'],
 reason: 'Shipping failed: ' . $e->getMessage(),
 ));
}

E cada serviço cuida da sua compensação. No estoque, por exemplo:

use Hyperf\Event\Contract\ListenerInterface;

final class ReleaseStockOnOrderCancelled implements ListenerInterface
{
 public function __construct(private StockRepository $stock) {}

 public function listen(): array
 {
 return [OrderCancelled::class];
 }

 public function process(object $event): void
 {
 // Idempotente: o mesmo evento pode chegar duas vezes.
 $this->stock->releaseReservation($event->orderId);
 }
}

O ponto forte é o desacoplamento: não existe um serviço central que, se cair, para tudo. O ponto fraco é que o fluxo não está escrito em lugar nenhum. Ele existe espalhado pelos listeners, e entender “o que acontece quando um pedido é cancelado” exige olhar vários serviços. Falei mais sobre esse estilo no artigo sobre Event-Driven Architecture.

Orquestrada

Um orquestrador conhece o fluxo inteiro: chama cada serviço na ordem e, se algum falhar, dispara as compensações dos passos que já aconteceram, na ordem inversa:

final class PlaceOrderSaga
{
 public function run(Order $order): void
 {
 $compensations = [];

 try {
 $this->stock->reserve($order);
 $compensations[] = fn () => $this->stock->release($order);

 $this->payment->charge($order);
 $compensations[] = fn () => $this->payment->refund($order);

 $this->shipping->schedule($order);
 } catch (Throwable $e) {
 foreach (array_reverse($compensations) as $compensate) {
 $compensate();
 }

 throw new OrderFailed("Order {$order->id} failed", previous: $e);
 }
 }
}

Se a entrega falha, o pagamento é estornado e depois o estoque é liberado. O fluxo está num lugar só, fácil de ler e de testar. Em troca, o orquestrador vira uma peça central: se ele cai, nenhuma saga anda.

Num sistema real, falta uma coisa nesse código: guardar o estado da saga. Se o orquestrador cair no meio de uma compensação, ele precisa saber, ao voltar, onde parou. E uma compensação também pode falhar, então ela precisa de retry e precisa ser idempotente. É por isso que, em produção, sagas costumam rodar em cima de ferramentas como Temporal ou de uma tabela de estado bem cuidada.

Os tipos de saga

O livro Software Architecture: The Hard Parts (Ford, Richards, Sadalage e Dehghani) organiza as sagas por três escolhas: comunicação síncrona ou assíncrona, consistência atômica ou eventual, e coordenação orquestrada ou coreografada. Na palestra mostrei três das combinações:

	Comunicação	Consistência	Coordenação
Epic Saga	Síncrona (HTTP)	Atômica	Orquestrada
Parallel Saga	Assíncrona (Kafka)	Eventual	Orquestrada
Anthology Saga	Assíncrona (Kafka)	Eventual	Coreografada

A Epic Saga é a mais parecida com o código acima: o orquestrador chama cada serviço por HTTP, espera a resposta, e nenhum serviço fala com outro diretamente. A Parallel Saga mantém o orquestrador, mas conversa por mensagens, o que permite executar passos em paralelo. A Anthology Saga é a coreografada pura: sem orquestrador, cada serviço mantém a sua transação e trata o próprio rollback. Quanto mais para baixo na tabela, menos acoplamento e mais escala, e mais difícil entender o que está acontecendo.

Juntando tudo

Numa arquitetura real, esses padrões aparecem juntos. A chamada ao frete tem retry com backoff e jitter, um circuit breaker em volta, um fallback com o último valor calculado e um log de cada tentativa e falha. A compra inteira é uma saga, que desfaz os passos se algo der errado no meio.

Agora os seus sistemas podem falhar tranquilamente.

Ou talvez não.

Cada padrão desses resolve um problema e cria outro. O retry aumenta a carga no serviço que já está mal. O fallback esconde a falha e pode custar dinheiro. O circuit breaker precisa de estado compartilhado e de limites bem calibrados, senão abre à toa ou não abre nunca. A saga troca uma transação simples por consistência eventual, compensações e muito mais código. Tudo é trade-off.

Então não se apeguem a padrões. Identifique o que faz mais sentido para o seu contexto: qual falha é provável, quanto ela custa, quanto tempo alguém pode esperar, e qual resposta errada é aceitável. Não existe bala de prata.

Os slides da palestra estão no Speaker Deck. Se você já passou por uma falha em cascata, ou usa algum desses padrões de um jeito diferente, me conta nos comentários.

Microservices são débitos técnicos?

Fri, 06 Dec 2024 00:00:00 -0300

Desenvolver software nunca esteve tão complexo e ao mesmo tempo tão simples. A complexidade está na quantidade de tecnologias, frameworks, linguagens e padrões que temos disponíveis para desenvolver software. A simplicidade está na facilidade de acesso a essas tecnologias e na facilidade de desenvolver software.

Com a facilidade de desenvolver software, muitas vezes, não nos preocupamos com a qualidade do software que estamos desenvolvendo. A qualidade do software é um fator muito importante para o sucesso de um projeto. É ela que garante que o software seja fácil de manter, fácil de evoluir e fácil de corrigir.

Muitas vezes focamos os nossos estudos e nosso tempo para o aprendizado de novas tecnologias e frameworks, mas esquecemos de estudar e aprender sobre arquitetura de software e isso é um grande erro. A arquitetura de software é o que garante a manutenibilidade, a evolução e a correção do software.

Decidir qual arquitetura utilizar em um projeto é uma tarefa muito importante e que deve ser feita com muito cuidado. Uma escolha não muito acertada pode trazer muitos problemas para o projeto e para a equipe de desenvolvimento, e o grande problema é que esses efeitos colaterais podem não ser percebidos no início do projeto, mas sim ao longo do tempo.

Alguns dos principais problemas que podem ser causados por uma arquitetura de software não muito acertada são grande acoplamento entre os módulos do software, baixa coesão entre os módulos, dificuldade em escalar, problemas de performance, dificuldade em testar, entre outros.

Imagine o seguinte cenário: o tempo foi passando, você e sua equipe foram notando que o software está ficando cada vez mais complexo, parece que a cada nova funcionalidade que é implementada, o software fica mais instável, mais difícil de manter, mais difícil de evoluir e mais difícil de corrigir. E agora? O que fazer?

Eis que surge do nada a palavra mágica: Microservices. Microservices é a solução para todos os problemas de arquitetura de software. Microservices é a solução para todos os problemas de acoplamento, coesão, escalabilidade, performance e testes.

Eu concordo que micro-serviços são uma excelente solução para muitos problemas de arquitetura de software, mas não são a solução para todos os problemas.

Você já pensou em refatorar seu código antes de tentar uma solução mais complexa como micro-serviços?

Pensou em estudar e aprender sobre arquitetura de software antes de tentar uma solução baseada puramente em tendências do momento ou em soluções que funcionaram para outras empresas?

A Netflix, Amazon, Google têm soluções ótimas para os problemas de arquitetura de software delas, mas será que essas soluções funcionam para o seu projeto?

Será que está na hora de você e sua equipe pararem de tentar soluções mágicas e começarem a estudar e aprender sobre qualidade e arquitetura de software?

Você não acha que usar micro-serviços para resolver problemas de arquitetura de software é um débito técnico?

Não vou dar resposta para essas perguntas, mas acho que você deveria pensar sobre isso.

Não acho que você nunca deve usar micro-serviços, mas acho que você deve pensar muito antes de usar.

Existem sim casos onde essa arquitetura faz todo sentido, mas existe uma grande quantidade de casos onde essa arquitetura só está sendo usada para resolver débitos técnicos deixados por uma decisão errada tomada no início do projeto.

Não abomine microservices, mas não os use como solução para todos os problemas.

Estude, aprenda, e tome decisões baseadas em fatos e não em tendências.

Manter um software de qualidade é um trabalho árduo e que exige muito estudo e dedicação, mas é um trabalho que vale a pena.

E você, o que acha? Microservices são débitos técnicos?

Acoplamento estático e dinâmico em Microservices

Fri, 11 Oct 2024 00:00:00 -0300

Aplicações monolíticas são aquelas que possuem um único código fonte, um único executável e um único processo. Muitas vezes, essas aplicações são construídas em uma única linguagem de programação e são implantadas em um único servidor.

Quando começamos a desenvolver, monolitos são a nossa primeira experiência na maioria das vezes. Eles são fáceis de desenvolver, testar e implantar. No entanto, à medida que a aplicação cresce, o monolito começa a se tornar um problema.

A escalabilidade de um software é uma das coisas mais importantes a serem consideradas hoje. Saber lidar de forma dinâmica com o crescimento de usuários e dados é essencial para o sucesso de um software.

Sistemas monolíticos são difíceis de escalar. Eles são construídos como um único bloco de código, o que significa que, para escalar a aplicação, você precisa replicar todo o código ou escalar verticalmente o servidor. Isso pode ser caro e ineficiente.

Escalabilidade vertical é a capacidade de aumentar a capacidade de um servidor, adicionando mais recursos, como CPU, RAM e disco. Isso é feito para melhorar o desempenho de um servidor.

Escalabilidade horizontal é a capacidade de aumentar a capacidade de um sistema, adicionando mais instâncias do sistema. Isso é feito para melhorar a disponibilidade e a confiabilidade de um sistema.

Microservices é uma arquitetura de software que resolve esse problema (mas cria outros). Em vez de construir uma única aplicação monolítica, você constrói várias aplicações pequenas e independentes, chamadas de micro-serviços. Cada microservice é responsável por uma parte específica da aplicação e se comunica com outras aplicações.

Embora, em teoria, os micro-serviços pareçam oferecer uma solução ideal para problemas de escalabilidade, eles apresentam desafios próprios na prática. Um dos principais desafios é o gerenciamento do acoplamento entre eles.

No mundo ideal, microservices devem ser independentes e desacoplados. Isso significa que uma aplicação deve ser capaz de funcionar sem depender de outra. No entanto, principalmente em migrações de sistemas monolíticos para microservices, é comum que dependam uns dos outros e chamamos isso de acoplamento.

Existem dois tipos de acoplamento em microservices: acoplamento estático e acoplamento dinâmico, e é sobre eles que vamos falar hoje.

Exemplo de arquitetura de microservices

Componentes:

API Gateway:
- Atua como o ponto de entrada para todas as solicitações externas ao sistema.
- Recebe requisições HTTP dos clientes e as encaminha para os serviços internos apropriados (como ProductCatalogService, OrderService, e UserService).
- Mantém o controle de acesso, autenticação, roteamento de requisições, e agregação de respostas.
ProductCatalogService:
- Gerencia informações sobre produtos à venda, como descrições, preços e disponibilidade.
- Pode consultar um serviço de descoberta como o Consul para localizar outros serviços necessários.
OrderService:
- Gera pedidos de compra.
- Interage com outros serviços para obter informações do produto (via ProductCatalogService) e detalhes do usuário (via UserService).
- Manipula pedidos no banco de dados MongoDB e publica eventos de pedidos para o RabbitMQ, permitindo comunicação assíncrona com outros serviços.
UserService:
- Administra informações de usuários, como perfis, preferências e histórico de compras.
- Permite que outros serviços venham a consultar informações do usuário de forma segura.
PaymentService:
- Responsável pelo processamento de transações de pagamento.
- Interage com o banco de dados MongoDB para armazenar informações sobre transações financeiras.
- Publica eventos de transação no RabbitMQ para permitir que outros serviços (como o NotificationService) sejam notificados sobre ocorrências financeiras.
RabbitMQ:
- Permite a mensageria assíncrona entre serviços, facilitando a comunicação desacoplada.
- Transmite eventos de pedidos e transações para partes interessadas.
NotificationService:
- Envia notificações para os usuários com base em eventos recebidos através do RabbitMQ, como atualizações de status de pedidos ou mensagens de confirmação de pagamento.
MongoDB:
- Armazena dados críticos para o sistema, como informações de pedidos, usuários e transações.
- Um banco de dados NoSQL, como o MongoDB, é bem adequado para sistemas que exigem flexibilidade de esquema e manuseio eficiente de dados não estruturados.
Consul:
- Serviço utilizado para descoberta, configuração e gerenciamento de serviços.
- Permite que microservices descubram dinamicamente a localização de outros serviços, facilitando uma arquitetura altamente flexível e resiliente.
Nginx:
- Pode representar um servidor web reverso ou balanceador de carga que distribui requisições entre várias instâncias do API Gateway, melhorando a capacidade e a disponibilidade.

Acoplamento estático

Os componentes em verde representam acoplamento estático.

O acoplamento estático ocorre quando um microservice depende de outro microservice em tempo de compilação ou configuração inicial do sistema.

Na maioria das vezes, acoplamentos estáticos são fáceis de identificar. Os mais comuns são:

Dependência de código: um microservice chama diretamente outro através de uma chamada de função ou API.
Dependência de banco de dados: um microservice acessa diretamente o banco de dados de outra aplicação.
Dependência de configuração: um micro-serviço depende de configurações específicas de outro microservice.

Outra forma de acoplamento estático é quando um microservice depende de um contrato específico de outro. Por exemplo, um microservice espera que outro serviço retorne um objeto JSON específico. Se o contrato mudar, o microservice que depende dele pode quebrar, então é preciso atualizar a aplicação que depende do contrato.

Acoplamento dinâmico

Os componentes em azul representam acoplamento dinâmico.

O acoplamento dinâmico ocorre quando um microservice depende de outro em tempo de execução.

Na maioria das vezes, acoplamentos dinâmicos são mais difíceis de identificar. Os mais comuns são:

Dependência de mensageria: um microservice envia uma mensagem para um barramento de mensagens e espera que outro serviço responda.
Dependência de descoberta de serviço: um microservice consulta um serviço de descoberta para localizar outro.

O interessante do acoplamento dinâmico é que ele permite que microservices sejam mais independentes e desacoplados. Se um microservice não estiver disponível, o que depende dele pode continuar funcionando, mesmo que de forma limitada.

Conclusão

Na hora de projetar microservices, é importante considerar o acoplamento entre eles. Acoplamento estático e acoplamento dinâmico são duas formas de acoplamento que podem ser usadas em sistemas distribuídos.

Não existe uma regra rígida sobre qual tipo de acoplamento é melhor. Na verdade, a maioria dos sistemas de microservices terá uma combinação de acoplamento estático e acoplamento dinâmico.

Você como arquiteto precisa decidir qual tipo de acoplamento faz mais sentido para o problema que você está resolvendo no momento. Em alguns casos, acoplamento estático pode ser mais simples e eficiente. Em outros casos, acoplamento dinâmico pode ser mais flexível e resiliente.

O importante é entender as diferenças entre acoplamento estático e acoplamento dinâmico e saber quando usar cada um deles.

Referências

Arquitetura de Software: as Partes Difíceis: Análises Modernas de Trade-off Para Arquiteturas Distribuídas

Event-driven Architecture (EDA)

Sat, 03 Aug 2024 00:00:00 -0300

Arquitetura de software envolve muitos trade-offs. Uma escolha inadequada pode gerar retrabalho e atrasos, por isso é importante conhecer as opções disponíveis e entender quando cada uma faz sentido.

Neste artigo, vamos falar sobre a Arquitetura Orientada a Eventos (Event-driven Architecture — EDA), um estilo cuja principal característica é a comunicação entre serviços por meio de eventos.

O que é EDA?

A Arquitetura Orientada a Eventos promove a produção, detecção, consumo e reação a eventos. Um evento pode ser qualquer fato relevante para o sistema: uma alteração de estado, uma ação do usuário, um erro ou uma mensagem recebida.

Os eventos são mensagens assíncronas geradas por um produtor e consumidas por um ou mais consumidores. O produtor não precisa conhecer os consumidores, e os consumidores não precisam conhecer os produtores. Isso permite construir sistemas mais desacoplados, escaláveis e flexíveis.

No exemplo deste artigo, vamos simular o seguinte cenário:

Exemplo prático

O sistema é composto por quatro serviços.

`ecommerce-frontend`

Frontend de um e-commerce que permite adicionar produtos ao carrinho.
Usa React para criar a interface do usuário.

`stock-service`

Gerencia o estoque dos produtos.
Usa PHP para se comunicar com o RabbitMQ.

Um exemplo simplificado de publicação de um evento de estoque em PHP:

$message = new AMQPMessage(json_encode([
 'order_id' => 1,
 'status' => 'updated',
]));

$channel->basic_publish($message, '', 'stock_updated');

O código acima é apenas um exemplo didático, não um código funcional ou seguro para produção.

`payment-service`

Processa os pagamentos dos pedidos.
Usa Python para se comunicar com o RabbitMQ.

def process_payment(order):
 print(f"Processando pagamento do pedido: {order['order_id']}")
 return True

`rabbitmq`

Servidor de mensageria que permite a comunicação entre os serviços.
Recebe os eventos publicados e os encaminha para os consumidores interessados.

O código completo está disponível no repositório do projeto.

Fluxo de comunicação

O usuário acessa o frontend do e-commerce e adiciona um produto ao carrinho.
O frontend envia uma requisição ao serviço de estoque para realizar o checkout.
O serviço de estoque verifica a disponibilidade e publica um evento no RabbitMQ.
O serviço de pagamentos consome o evento e processa o pagamento.
O serviço de pagamentos publica um evento informando o resultado do processamento.

Trade-offs

Esse fluxo é um exemplo simples de como a EDA pode desacoplar serviços e permitir comunicação assíncrona sem que produtores e consumidores precisem conhecer uns aos outros. Cada serviço fica responsável por uma tarefa e pode ser substituído ou atualizado com menor impacto nos demais.

Por outro lado, a arquitetura orientada a eventos aumenta a complexidade operacional. É necessário lidar com ordenação, entrega, idempotência, rastreabilidade e depuração de problemas distribuídos.

Por isso, antes de adotar EDA, avalie se os benefícios compensam essa complexidade para o seu projeto.

Conclusão

A Arquitetura Orientada a Eventos é uma alternativa poderosa para criar sistemas desacoplados, flexíveis e resilientes. Não existe uma arquitetura perfeita: a melhor escolha depende dos requisitos, das restrições e da maturidade operacional do projeto.

O código completo está disponível no GitHub.

Microservices e Mensageria com PHP, NodeJS, RabbitMQ e Docker

Sat, 29 Jun 2024 00:00:00 -0300

O desenvolvimento de microserviços é uma abordagem arquitetural que estrutura uma aplicação como um conjunto de serviços pequenos e independentes, que são executados em seu próprio processo e se comunicam por meio de protocolos leves, como HTTP, WebSockets ou AMQP.

Neste artigo, vamos criar uma aplicação de microserviços com PHP, RabbitMQ e Docker. O RabbitMQ é um software de mensageria que implementa o protocolo AMQP (Advanced Message Queuing Protocol), que é um protocolo de mensagens assíncronas.

O que é RabbitMQ?

Vamos imaginar o seguinte cenário: você tem um sistema que precisa enviar e-mails para os usuários. Em vez de enviar os e-mails diretamente, você pode enviar uma mensagem para uma fila de mensagens, que será consumida por um serviço que envia os e-mails. Isso é o que o RabbitMQ faz: ele recebe mensagens de produtores e as envia para consumidores.

Dessa forma é possível desacoplar a produção de mensagens do consumo, o que permite escalar cada parte do sistema de forma independente. Além disso, o RabbitMQ garante que as mensagens sejam entregues na ordem correta e que não sejam perdidas.

Arquitetura da aplicação

Nossa aplicação será composta por dois microserviços: um produtor e um consumidor. O produtor será responsável por enviar mensagens para uma fila de mensagens, e o consumidor será responsável por consumir as mensagens e exibi-las no terminal.

Nosso primeiro passo será criar o arquivo docker-compose.yml para definir os serviços da nossa aplicação:

services:
 rabbitmq:
 image: "rabbitmq:3-management"
 container_name: "rabbitmq"
 ports:
 - "15672:15672"
 - "5672:5672"

 php-app:
 build: ./php-app
 depends_on:
 - rabbitmq

 node-app:
 build: ./node-app
 depends_on:
 - rabbitmq

Neste arquivo, definimos três serviços: rabbitmq, php-app e node-app. O serviço rabbitmq é baseado na imagem rabbitmq:3-management, que inclui a interface de gerenciamento do RabbitMQ. Os serviços php-app e node-app são baseados em imagens customizadas que iremos criar.

Criando o produtor com PHP

Agora, vamos criar o diretório php-app e o arquivo Dockerfile dentro dele:

mkdir php-app && touch php-app/Dockerfile

No arquivo Dockerfile, vamos definir a imagem base e copiar os arquivos da aplicação:

FROM php:7.4-cli

RUN apt-get update && apt-get install -y librabbitmq-dev libssl-dev git unzip wget curl

RUN docker-php-ext-install sockets pdo pdo_mysql
RUN pecl install amqp && docker-php-ext-enable amqp

COPY . /usr/src/myapp
WORKDIR /usr/src/myapp

RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer

RUN composer clear-cache

RUN composer install

CMD ["php", "./publisher.php"]

Neste arquivo, definimos a imagem base php:7.4-cli e instalamos as dependências necessárias para o RabbitMQ e o Composer. Em seguida, copiamos os arquivos da aplicação para o diretório /usr/src/myapp, instalamos as dependências do Composer e executamos o script publisher.php.

Agora, vamos criar o arquivo publisher.php na raiz do projeto:

require_once __DIR__ . '/vendor/autoload.php';
use PhpAmqpLib\Connection\AMQPStreamConnection;
use PhpAmqpLib\Message\AMQPMessage;

$maxRetries = 5;
$retryDelay = 5;

for ($attempt = 0; $attempt try {
 $connection = new AMQPStreamConnection('rabbitmq', 5672, 'guest', 'guest');
 $channel = $connection->channel();
 break;
 } catch (Exception $e) {
 echo "Failed to connect to RabbitMQ. Retrying in $retryDelay seconds...\n";
 sleep($retryDelay);
 }
}

if (!isset($connection)) {
 echo "Not possible to connect to RabbitMQ. Exiting...\n The application will be restarted by Docker\n";
 exit(1);
}

$channel->queue_declare('hello', false, false, false, false);

$msg = new AMQPMessage('Hello, RabbitMQ! Now is ' . date('Y-m-d H:i:s'));
$channel->basic_publish($msg, '', 'hello');

echo " [x] Sent 'Hello, RabbitMQ!'\n";

$channel->close();
$connection->close();

Neste arquivo, criamos uma conexão com o RabbitMQ, declaramos uma fila chamada hello e enviamos uma mensagem para essa fila. Em seguida, fechamos a conexão com o RabbitMQ. Perceba que estamos tentando conectar ao RabbitMQ várias vezes, com um intervalo de 5 segundos entre as tentativas.

Isso é importante para garantir que a aplicação consiga se conectar ao RabbitMQ mesmo que ele não esteja disponível imediatamente. Isso é uma prática comum em aplicações distribuídas, onde a disponibilidade dos serviços pode variar ao longo do tempo. Pesquise mais sobre circuit breaker e retry pattern.

Mas para instalar as dependências do RabbitMQ e do Composer, precisamos criar o arquivo composer.json na raiz do projeto:

{ "require": { "php-amqplib/php-amqplib": "^3.1", "phpseclib/phpseclib": "^3.0" } }

Criando o consumidor com Node.js

Agora, vamos criar o diretório node-app e o arquivo Dockerfile dentro dele:

mkdir node-app && touch node-app/Dockerfile

No arquivo Dockerfile, vamos definir a imagem base e copiar os arquivos da aplicação:

FROM node:14 
WORKDIR /usr/src/app 
COPY package\*.json ./ 
RUN npm install 
COPY . . 
CMD \["node", "subscriber.js"\]

Neste arquivo, definimos a imagem base node:14, copiamos os arquivos da aplicação para o diretório /usr/src/app, instalamos as dependências do Node.js e executamos o script subscriber.js.

Agora, vamos criar o arquivo subscriber.js na raiz do projeto:

const amqp = require('amqplib');

async function connectWithRetry() {
 const maxRetries = 5;
 const retryDelay = 5000;

 for (let attempt = 1; attempt try {
 const connection = await amqp.connect('amqp://rabbitmq');
 return connection;
 } catch (err) {
 console.error(`Not possible to connect to RabbitMQ. Retrying in ${retryDelay}ms. Attempt ${attempt} of ${maxRetries}`);
 await new Promise(resolve => setTimeout(resolve, retryDelay));
 }
 }

 throw new Error(`Failed to connect to RabbitMQ after ${maxRetries} attempts`);
}

async function receiveMessages() {
 try {
 const connection = await connectWithRetry();
 const channel = await connection.createChannel();
 const queue = 'hello';

 await channel.assertQueue(queue, { durable: false });

 console.log(" [*] Waiting for messages in %s.", queue);

 channel.consume(queue, function (msg) {
 console.log(" [x] Received: %s", msg.content.toString());
 }, {
 noAck: true
 });

 } catch (err) {
 console.error(err.message);
 process.exit(1);
 }
}

receiveMessages();

Neste arquivo, criamos uma conexão com o RabbitMQ, declaramos uma fila chamada hello e consumimos as mensagens dessa fila.

Em seguida, exibimos as mensagens no terminal. Assim como no produtor, estamos tentando conectar ao RabbitMQ várias vezes, com um intervalo de 5 segundos entre as tentativas. Isso é importante para garantir que o consumidor consiga se conectar ao RabbitMQ mesmo que ele não esteja disponível imediatamente.

E para instalar as dependências do RabbitMQ, precisamos criar o arquivo package.json na raiz do projeto:

{ "name": "node-app", "version": "1.0.0", "description": "", "main": "subscriber.js", "dependencies": { "amqplib": "^0.8.0" }, "author": "", "license": "ISC" }

Executando a aplicação

Agora que criamos os serviços do RabbitMQ, do produtor e do consumidor, vamos executar a aplicação com o Docker Compose:

docker compose up --build

Isso irá criar os containers dos serviços e executar a aplicação. Você verá as mensagens enviadas pelo produtor sendo exibidas no terminal pelo consumidor.

O RabbitMQ também estará disponível na porta 15672, onde você pode acessar a interface de gerenciamento e visualizar as filas e as mensagens.

Com isso, criamos uma aplicação de microserviços com PHP, RabbitMQ e Docker. Essa abordagem arquitetural permite escalar cada parte do sistema de forma independente e garante a entrega das mensagens na ordem correta.

Espero que este artigo tenha sido útil e que você possa aplicar esses conceitos em seus projetos. Se tiver alguma dúvida ou sugestão, deixe nos comentários.

Qualquer dúvida, estou à disposição.

Link do Repositório: Microservices e Mensageria com PHP, RabbitMQ e Docker