Luiz Schons – Mensageria

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.

Arquitetura Hexagonal e Mensageria com PHP

Thu, 04 Jul 2024 00:00:00 -0300

Arquitetura Hexagonal (Ports and Adapters)

Link para o projeto: https://github.com/sschonss/microservices-hexagonal

Existem diversas formas de se organizar um projeto, e uma das formas mais conhecidas é a arquitetura hexagonal. A arquitetura hexagonal é uma forma de organizar o projeto de forma que ele seja independente de frameworks, banco de dados, UI, etc. O objetivo é que o projeto seja independente de qualquer tecnologia, e que possa ser facilmente substituído.

Neste projeto, a arquitetura hexagonal foi implementada utilizando a linguagem de programação PHP e o framework Laravel. A ideia é que o projeto seja independente do Laravel, e dessa maneira, usamos somente o Laravel para criar rotas e controladores, e o restante do projeto é independente do Laravel.

Estrutura do projeto

O projeto foi dividido em 3 camadas principais:

Laravel: Toda a infraestrutura do projeto, como rotas, controladores, etc.
Adapters: Camada responsável por conter os adaptadores de entrada e saída do projeto.
Core: Camada responsável por conter as regras de negócio do projeto. Dentro do core, iremos trabalhar com Domain Driven Design (DDD).

Adapters

Os adapters são responsáveis por adaptar as entradas e saídas do projeto. Mas o que isso significa?

Imagine que você tem um projeto que precisa se comunicar com um banco de dados. Se você não utilizar uma camada de adapter, você terá que utilizar o banco de dados diretamente no seu projeto. Isso significa que você terá que utilizar as classes do banco de dados diretamente no seu projeto, e isso fará com que seu projeto fique dependente do banco de dados.

Então um ORM (Object Relational Mapping) é um exemplo de adapter. O ORM é uma camada que adapta a comunicação com o banco de dados, e dessa maneira, o projeto não fica dependente do banco de dados.

Dentro do nosso projeto, temos os seguintes adapters:

EmailAdapter: Adapter responsável por enviar e-mails.
RabbitMQAdapter: Adapter responsável por enviar mensagens para o RabbitMQ.

Eles contêm as classes que adaptam a comunicação com o serviço de e-mail e com o RabbitMQ.

Tudo isso somente usando PHP sem Laravel, para que o projeto seja independente e possa ser facilmente substituído.

Core

O core é a camada responsável por conter as regras de negócio do projeto. Dentro do core, iremos trabalhar com Domain Driven Design (DDD).

O que é DDD?

Domain Driven Design é uma forma de organizar o projeto de forma que ele seja separado por domínios. Cada domínio é uma parte do projeto que contém as regras de negócio. Dessa maneira, o projeto fica organizado e fácil de ser mantido.

Dentro do core, temos os seguintes domínios:

Email: Domínio responsável por emails em geral da aplicação.
Connections: Domínio responsável por conexões com serviços externos, como RabbitMQ, Redis, etc.

Dentro de cada domínio, teremos as camadas responsáveis por conter as regras de negócio para cada feature.

O mais importante é que o core não depende de nada. Ele é independente de qualquer framework, banco de dados, etc. Dessa maneira, podemos facilmente substituir o Laravel por outro framework, ou o MySQL por outro banco de dados.

O Core se comunica com serviços externos através dos adapters. Dessa maneira, o core não fica dependente de nenhum serviço externo, somente do adapter.

Projeto

O projeto é um exemplo simples de como a arquitetura hexagonal pode ser implementada. O projeto é um sistema de cadastro de usuários, onde o usuário pode se cadastrar e receber um e-mail de boas-vindas.

O projeto foi dividido em 3 serviços:

Main App: Serviço principal, onde o usuário se cadastra. Nele está a arquitetura hexagonal.
RabbitMQ: Serviço de mensageria, onde o Main App envia uma mensagem para o RabbitMQ.
Email App: Serviço de e-mail, onde lê as mensagens do RabbitMQ e envia um e-mail para o usuário.

Dessa maneira, o Main App não fica dependente do RabbitMQ e do serviço de e-mail. Ele somente envia uma mensagem para o RabbitMQ, e o RabbitMQ envia a mensagem para o serviço de e-mail.

Como rodar o projeto

Para rodar o projeto, você precisa ter o Composer, Docker e o Docker Compose instalados na sua máquina.

Após instalar o Docker e o Docker Compose, basta rodar o seguinte comando:

cd main-app composer install ./vendor/bin/sail up

Após rodar o comando, o projeto estará rodando na porta 80.

Já podemos criar um usuário através do endpoint POST /api/user, passando o seguinte JSON:

{ "name": "John Doe", "email": "john@doe.com", "password": "123456" }

Após criar o usuário, será disparado um evento para o RabbitMQ, mas o serviço de e-mail ainda não está rodando. Para rodar o serviço de e-mail, basta rodar o seguinte comando:

cd email-app docker-compose up --build --force-recreate

Após rodar o comando, o serviço de e-mail estará rodando e irá ler as mensagens do RabbitMQ e enviar um e-mail para o usuário.

Acessar o RabbitMQ

Para acessar o RabbitMQ, basta acessar o seguinte endereço:

http://localhost:15672

E fazer login com as seguintes credenciais:

Username: guest Password: guest

Conclusão

A arquitetura hexagonal é uma forma de organizar o projeto de forma que ele seja independente de qualquer tecnologia. Neste projeto, a arquitetura hexagonal foi implementada utilizando a linguagem de programação PHP e o framework Laravel. A ideia é que o projeto seja independente do Laravel, e dessa maneira, usamos somente o Laravel para criar rotas e controladores, e o restante do projeto é independente do Laravel.

Também foi implementado um serviço de mensageria com RabbitMQ e um serviço de e-mail. Dessa maneira, o Main App não fica dependente do RabbitMQ e do serviço de e-mail. Ele somente envia uma mensagem para o RabbitMQ, e o RabbitMQ envia a mensagem para o serviço de e-mail.

Vimos como a mensageria ajuda a desacoplar os serviços, e como a arquitetura hexagonal ajuda a organizar o projeto de forma que ele seja independente de qualquer tecnologia.

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