Luiz Schons – PHP

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.

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

PHP — Streams Filters

Tue, 04 Jun 2024 00:00:00 -0300

Se você já trabalhou com arquivos em PHP, provavelmente já usou funções como fopen, fwrite, fread, fclose, entre outras. Streams são uma abstração muito poderosa e flexível para trabalhar com arquivos e outros recursos de I/O.

Streams são uma forma de abstrair a manipulação de dados de entrada e saída, permitindo que você leia e escreva dados de e para diferentes fontes, como arquivos, strings, conexões de rede, etc.

Por exemplo, você pode usar streams para ler dados de um arquivo, processá-los e escrevê-los em outro arquivo, sem ter que se preocupar com a origem ou destino dos dados.

Ou então, você pode usar streams para ler dados de uma conexão de rede, processá-los e escrevê-los em um banco de dados. E assim por diante.

Exemplo básico

$stream = fopen('data.txt', 'r');
while (!feof($stream)) {
 $line = fgets($stream);
 echo $line;
}
fclose($stream);

Neste exemplo, abrimos um arquivo chamado data.txt em modo de leitura ('r'). Em seguida, lemos o conteúdo do arquivo linha por linha até o final do arquivo (feof($stream)). Por fim, fechamos o arquivo com fclose($stream).

Mas o que é um stream? Um stream é um recurso que representa uma fonte ou destino de dados. No exemplo acima, $stream é um stream que representa o arquivo data.txt.

Vamos ver um exemplo mais avançado.

Exemplo avançado

$context = stream_context_create([
 'http' => [
 'method' => 'POST',
 'header' => 'Content-Type: application/json',
 'content' => json_encode(['key' => 'value']),
 ],
]);

$stream = fopen('http://example.com/data.csv', 'r', false, $context);
while (!feof($stream)) {
 $line = fgetcsv($stream);
 print_r($line);
}
fclose($stream);

Neste exemplo, criamos um contexto de stream com stream_context_create, que é um array associativo com opções de configuração para o stream. No caso, estamos configurando um stream HTTP com o método POST, o cabeçalho Content-Type: application/json e o corpo da requisição em formato JSON.

Em seguida, abrimos um stream para a URL http://example.com/data.csv em modo de leitura ('r') com o contexto de stream que acabamos de criar.

Depois, lemos o conteúdo do stream linha por linha com fgetcsv, que lê uma linha do stream e a converte em um array de valores separados por vírgula.

Por fim, fechamos o stream com fclose.

Mas por que usar streams?

O PHP surgiu em uma época em que a manipulação de arquivos era a principal forma de interagir com o sistema de arquivos e outros recursos de I/O. Por isso, as funções de manipulação de arquivos do PHP são baseadas em operações de baixo nível, como abrir, ler, escrever e fechar arquivos, os famosos fopen, fread, fwrite e fclose.

Com o tempo, a necessidade de interagir com outros tipos de recursos de I/O, como conexões de rede, bancos de dados, etc., tornou-se cada vez mais comum. E foi aí que os streams entraram em cena.

Streams são essencialmente uma camada de abstração sobre diferentes tipos de recursos de I/O, permitindo que você leia e escreva dados de e para esses recursos de forma consistente, independente da origem ou destino dos dados.

Quando eu falo de recursos de I/O, estou me referindo a qualquer coisa que você possa ler ou escrever dados, como arquivos, strings, janelas de console, conexões de rede, sockets, pipes, etc.

E quando eu falei de não se preocupar com a origem ou destino dos dados, eu quis dizer que você não precisa saber se está lendo de um arquivo, de uma conexão de rede, de um banco de dados, etc. Você simplesmente lê os dados do stream e os processa da forma que desejar. Isso é muito poderoso e flexível.

E como eu uso streams?

Para usar streams em PHP, você precisa entender alguns conceitos básicos:

Resource
Context
Wrapper
Stream functions
Stream filters

Nota: Este é apenas um resumo básico sobre streams em PHP. Para saber mais, consulte a documentação oficial.

Resource

Vamos nos aprofundar um pouco mais no conceito de recurso (resource) em PHP.

Um stream é representado por um recurso (resource) em PHP. Um recurso é uma variável especial que contém uma referência interna para um recurso externo, como um arquivo, uma conexão de rede, etc. Você pode criar um recurso com a função fopen e fechá-lo com a função fclose.

Um resource em PHP é um identificador interno para recursos externos, e a função get_resource_type pode ser usada para obter o tipo de recurso.

$stream = fopen('data.txt', 'r');
echo get_resource_type($stream);
fclose($stream);

No console, você verá algo como stream.

O resource sempre vai referenciar o arquivo aberto.

Context

Um contexto de stream é um array associativo com opções de configuração para o stream. Você pode criar um contexto de stream com a função stream_context_create e passá-lo como argumento para funções que abrem streams, como fopen, file_get_contents, etc.

Quando você abre um stream com um contexto de stream, as opções de configuração do contexto são aplicadas ao stream. Por exemplo, você pode configurar um stream HTTP com o método POST, o cabeçalho Content-Type: application/json, etc.

$context = stream_context_create([
 'http' => [
 'method' => 'POST',
 'header' => 'Content-Type: application/json',
 'content' => json_encode(['key' => 'value']),
 ],
]);

$stream = fopen('http://example.com/data.csv', 'r', false, $context);

Ou então, você pode usar um contexto de stream para configurar um stream FTP com o nome de usuário e senha.

$context = stream_context_create([
 'ftp' => [
 'username' => 'user',
 'password' => 'pass',
 ],
]);

$stream = fopen('ftp://example.com/data.csv', 'r', false, $context);

Wrapper

Um wrapper é um esquema de URL que define como o PHP deve abrir um stream. Por exemplo, o wrapper http é usado para abrir streams HTTP, o wrapper ftp é usado para abrir streams FTP, etc.

Quando você abre um stream com fopen, o PHP usa o wrapper correspondente para abrir o stream. Por exemplo, se você abrir um stream http://example.com/data.csv, o PHP usará o wrapper http para abrir o stream.

Você também pode usar wrappers para abrir streams de outros tipos de recursos, como strings, variáveis de memória, etc.

$stream = fopen('data:text/plain;base64,SGVsbG8gV29ybGQ=', 'r');
echo stream_get_contents($stream);
fclose($stream);

Neste exemplo, estamos abrindo um stream de uma string codificada em base64 com o wrapper data. O conteúdo da string é Hello World.

$stream = fopen('php://memory', 'r+');

Neste exemplo, estamos abrindo um stream de uma variável de memória com o wrapper php. O stream é aberto em modo de leitura e escrita ('r+').

$stream = fopen('ogg://temp', 'r+');

OGG é um wrapper que permite a manipulação de arquivos de áudio no formato OGG, isso é um exemplo de um wrapper personalizado.

Você pode criar seus próprios wrappers personalizados para abrir streams de outros tipos de recursos, como bancos de dados, APIs, etc.

Veja a documentação oficial para mais informações sobre wrappers em PHP.

Stream functions

O PHP fornece várias funções para trabalhar com streams, como fopen, fclose, fread, fwrite, feof, fseek, ftell, fgetcsv, stream_get_contents, etc.

Você pode usar essas funções para abrir, fechar, ler, escrever, posicionar, verificar o final, etc., de um stream.

Por exemplo, você pode usar fopen para abrir um stream, fread para ler dados do stream, fwrite para escrever dados no stream e fclose para fechar o stream.

$stream = fopen('data.txt', 'r');

while (!feof($stream)) {
 $line = fgets($stream);
 echo $line;
}

fwrite($stream, 'Hello World');
fclose($stream);

Neste exemplo, estamos abrindo um arquivo chamado data.txt em modo de leitura ('r'). Em seguida, lemos o conteúdo do arquivo linha por linha até o final do arquivo com fgets. Depois, escrevemos a string Hello World no arquivo com fwrite. Por fim, fechamos o arquivo com fclose.

Você pode usar essas funções para trabalhar com streams de diferentes tipos de recursos, como o curl, sockets, pipes, etc.

$url = 'http://example.com/data/page.html';
$data = curl_init($url);
curl_setopt($data, CURLOPT_RETURNTRANSFER, true);
$response = curl_exec($data);
curl_close($data);
$stream = fopen('php://memory', 'r+');
fwrite($stream, $response);
rewind($stream);
echo stream_get_contents($stream);
fclose($stream);

Neste exemplo, estamos fazendo uma requisição HTTP com o curl para a URL http://example.com/data/page.html. Em seguida, abrimos um stream de uma variável de memória com o wrapper php em modo de leitura e escrita ('r+'). Depois, escrevemos a resposta da requisição no stream com fwrite. Por fim, exibimos o conteúdo do stream com stream_get_contents e fechamos o stream com fclose.

Stream filters

Aqui chegamos a um dos recursos mais poderosos e flexíveis dos streams em PHP: os filtros de stream.

Imagine o seguinte cenário: você está lendo dados de um arquivo e precisa processar esses dados antes de exibi-los na tela. Com os filtros de stream, você pode criar um filtro que processa os dados conforme necessário e aplicá-lo ao stream de leitura, sem precisar modificar o código que lê os dados.

Por exemplo, você pode usar um filtro de stream para converter os dados de um arquivo de texto para letras maiúsculas antes de exibi-los na tela.

$stream = fopen('data.txt', 'r');
stream_filter_append($stream, 'string.toupper');
echo stream_get_contents($stream);
fclose($stream);

Neste exemplo, estamos abrindo um arquivo chamado data.txt em modo de leitura ('r'). Em seguida, aplicamos o filtro string.toupper ao stream com stream_filter_append, que converte os dados para letras maiúsculas. Por fim, exibimos o conteúdo do stream com stream_get_contents e fechamos o arquivo com fclose.

Essa conversão é feita automaticamente pelo filtro de stream, ocorre durante a leitura dos dados e não afeta o arquivo original.

Você pode criar seus próprios filtros de stream para processar os dados de acordo com suas necessidades.

Veja a documentação oficial para mais informações sobre filtros de stream em PHP.

FilterPHP

Mas eu preparei um exemplo para você entender melhor como funciona um filtro de stream.

No primeiro exemplo, vamos criar um filtro de stream que filtrará somente para linhas que contêm a palavra “PHP”.

<?php

class FilterPHP extends php_user_filter
{
 public $stream;
 public string $filter;

 public function onCreate(): bool {
 $this->stream = fopen('php://temp', 'w+');
 return $this->stream !== false;
 }

 public function filter($in, $out, &$consumed, $closing): int {
 $this->filter = 'PHP';
 $out_data = '';
 while ($bucket = stream_bucket_make_writeable($in)) {
 $line = explode("\n", $bucket->data);
 foreach ($line as $l) {
 if (str_contains($l, $this->filter)) {
 $out_data .= $l . "\n";
 }
 }
 }

 $bucket_out = stream_bucket_new($this->stream, $out_data);
 stream_bucket_append($out, $bucket_out);

 return PSFS_PASS_ON;
 }
}

Vamos entender o que está acontecendo no código acima passo a passo.

Criamos uma classe chamada FilterPHP que estende a classe php_user_filter. Esta classe é usada para criar um filtro de stream personalizado.

Se você já trabalhou com classes em PHP, deve estar estranhando o fato de estender uma classe com um nome tão estranho. Isso acontece porque a classe php_user_filter é uma classe interna do PHP que não segue as convenções de nomenclatura de classes em PHP que foram estabelecidas pela comunidade ao longo dos anos.

A classe FilterPHP possui duas propriedades: $stream e $filter. A propriedade $stream é usada para armazenar um stream temporário onde os dados filtrados serão escritos. A propriedade $filter é usada para armazenar o filtro que será aplicado aos dados.
O método onCreate é chamado quando o filtro é criado. Neste método, abrimos um stream temporário com fopen('php://temp', 'w+') e armazenamos o recurso do stream na propriedade $stream. Se o stream não puder ser aberto, retornamos false.

O método onCreate é um método obrigatório que deve ser implementado em todos os filtros de stream personalizados, funcionando como um construtor para o filtro.

Mas o que é php://temp? php://temp é um wrapper que permite a criação de streams temporários em PHP. Os streams temporários são armazenados na memória ou em um arquivo temporário, dependendo do tamanho dos dados.

4. O método filter é chamado para filtrar os dados do stream. Neste método, lemos os dados de entrada das seguintes variáveis:

$in: stream de entrada, onde os dados originais são lidos. Este stream é somente leitura, vem de input e é passado para o filtro.
$out: stream de saída, onde os dados filtrados são escritos. Este stream é somente escrita, vem de output e é passado para o filtro.
&$consumed: quantidade de dados consumidos pelo filtro. Este valor é atualizado pelo filtro e passado de volta para o PHP.
$closing: indica se o stream está sendo fechado. Se for true, o filtro deve liberar todos os recursos alocados.

Nota: O & na frente de uma variável em PHP indica que a variável é passada por referência, ou seja, o valor da variável pode ser alterado dentro da função e refletido fora dela.

5. No método filter, lemos os dados de entrada do stream com stream_bucket_make_writeable e os armazenamos na variável $out_data. Em seguida, dividimos os dados em linhas com explode("\n", $bucket->data) e verificamos se cada linha contém a palavra "PHP" com str_contains($l, $this->filter).

6. Se a linha contiver a palavra “PHP”, a linha é adicionada à variável $out_data. Em seguida, criamos um novo bucket de saída com stream_bucket_new e o adicionamos ao stream de saída com stream_bucket_append.

7. Por fim, retornamos PSFS_PASS_ON para indicar que o filtro deve continuar a passar os dados para o próximo filtro ou para o stream de saída.

Agora que criamos o filtro de stream, vamos aplicá-lo a um stream de entrada.

<?php
require_once './FilterPHP.php';
$json = 'https://raw.githubusercontent.com/sschonss/stream-php/main/data.json';
$fileContents = file_get_contents($json);

if ($fileContents === false) {
 die('Failed to fetch data from the endpoint.');
}

stream_filter_register('filterphp', 'FilterPHP') or die("Failed to register filter.");

$tempStream = fopen('php://temp', 'r+');
fwrite($tempStream, $fileContents);
rewind($tempStream);

$out_fp = fopen('php://stdout', 'w') or die("Failed to open output stream.");
stream_filter_append($tempStream, 'filterphp');

while ($data = fread($tempStream, 1024)) {
 $data = str_replace('"name": ', '', $data);
 $data = str_replace('"description": ', '', $data);
 echo $data;
}

fclose($tempStream);
fclose($out_fp);

Neste exemplo, estamos lendo um arquivo JSON de uma URL com file_get_contents e armazenando o conteúdo do arquivo em uma variável chamada $fileContents.

Em seguida, registramos o filtro de stream FilterPHP com stream_filter_register. O primeiro argumento é o nome do filtro, que será usado para aplicar o filtro ao stream de entrada. O segundo argumento é o nome da classe do filtro.

É importante registrar o filtro de stream antes de aplicá-lo ao stream de entrada, para que o PHP saiba como lidar com o filtro.

Depois, abrimos um stream temporário com fopen('php://temp', 'r+') e escrevemos o conteúdo do arquivo no stream com fwrite. Em seguida, rebobinamos o stream com rewind.

Nota: O rewind é uma função que move o ponteiro interno do stream para o início do stream. Isso é necessário porque o ponteiro interno do stream é movido para o final do stream após a escrita.

Nota: Ponteiro em PHP é como se fosse um cursor que aponta para a posição atual do stream.

Depois, abrimos um stream de saída com fopen('php://stdout', 'w') e aplicamos o filtro de stream FilterPHP ao stream temporário com stream_filter_append.

Por fim, lemos os dados do stream temporário com fread e exibimos os dados na tela com echo. Antes de exibir os dados, removemos as aspas duplas das chaves name e description com str_replace.

Por fim, fechamos o stream temporário e o stream de saída com fclose.

O retorno do código acima será algo como:

php-filter_1 | "PHP",
php-filter_1 | "PHP (Hypertext Preprocessor) é uma linguagem de script amplamente utilizada para desenvolvimento web e pode ser embutida em HTML."
php-filter_1 | "Composer é um gerenciador de dependências para PHP, permitindo que você declare as bibliotecas que seu projeto depende e as instale."
php-filter_1 | "Laravel é um framework web PHP, conhecido por sua sintaxe elegante e ferramentas robustas para desenvolvimento rápido de aplicativos."
php-filter_1 | "Symfony é um conjunto de componentes PHP reutilizáveis e um framework web para criar aplicações e sites."
php-filter_1 | "CodeIgniter é um framework PHP poderoso e simples de usar, construído para desenvolvedores que precisam de um toolkit elegante para criar aplicativos web completos."
php-filter_1 | "CakePHP",
php-filter_1 | "CakePHP é um framework PHP rápido de desenvolvimento que proporciona uma estrutura extensível para desenvolvedores criar aplicativos web."
php-filter_1 | "Zend Framework é uma coleção de pacotes PHP profissionais com mais de 570 milhões de instalações."

Caso você queira testar o código acima, você pode clonar o repositório stream-php e executar o comando docker-compose up para subir o container com o PHP e testar o código.

Conclusão

Streams são uma abstração poderosa e flexível para trabalhar com arquivos e outros recursos de I/O em PHP. Com streams, você pode ler e escrever dados de e para diferentes fontes, como arquivos, strings, conexões de rede, etc., de forma consistente e independente da origem ou destino dos dados.

Além disso, você pode usar contextos de stream para configurar streams com opções específicas, wrappers para abrir streams de diferentes tipos de recursos, funções de stream para trabalhar com streams de forma eficiente e filtros de stream para processar os dados conforme necessário.

Espero que este guia tenha sido útil para você entender melhor como trabalhar com streams em PHP. Se tiver alguma dúvida, sugestão ou correção, fique à vontade para entrar em contato.

Até a próxima!

JIT (Just in Time) — PHP

Tue, 28 May 2024 00:00:00 -0300

Se você ainda não atualizou para o PHP 8.0 ou maior, está na hora de fazer isso. O PHP 8.0 foi lançado em 26 de novembro de 2020 e trouxe o JIT (Just In Time) e é sobre ele que vamos falar hoje.

Código OPC

Quando você executa um script PHP, o PHP o compila para um código intermediário chamado de código OPC (PHP Opcode). O código OPC é então executado pela máquina virtual Zend.

Segue um exemplo de código PHP e seu código OPC:

PHP:

$a = M_PI;
$b = 10 + sin($a);
echo "Result: ", $b;

Código OPC:

Finding entry points
Branch analysis from position: 0
1 jumps found. (Code = 62) Position 1 = -2
filename: /in/ceTlX
function name: (null)
number of ops: 9
compiled vars: !0 = $a, !1 = $b
line #* E I O op fetch ext return operands
-------------------------------------------------------------------------------------
 2 0 E > ASSIGN !0, 3.14159
 3 1 INIT_FCALL 'sin'
 2 SEND_VAR !0
 3 DO_ICALL $3
 4 ADD ~4 10, $3
 5 ASSIGN !1, ~4
 4 6 ECHO 'Result%3A+'
 7 ECHO !1
 5 8 > RETURN 1

Basicamente, o código OPC é uma sequência de instruções que a máquina virtual Zend executa.

JIT

Mas onde o JIT entra nisso? O JIT é um compilador que compila o código OPC em código de máquina nativo. Isso significa que o JIT compila o código OPC em código de máquina que a CPU pode executar diretamente.

Dessa forma não usamos mais a máquina virtual Zend para executar o código OPC, mas sim o código de máquina nativo gerado pelo JIT.

Habilitando o JIT

O JIT não é habilitado por padrão. Para habilitá-lo, você precisa de alguns passos adicionais.

Primeiro, você precisa instalar a extensão opcache:

sudo apt-get install php8.0-opcache

Depois, você precisa habilitar o JIT no arquivo de configuração do PHP (php.ini):

[opcache]
opcache.enable=1
opcache.jit_buffer_size=100M
opcache.jit=tracing
opcache.jit=1205
opcache.enable_cli=1

Aqui, estamos habilitando o JIT e definindo o tamanho do buffer JIT para 100 MB. O JIT pode operar em dois modos: tracing e function. O modo tracing é o modo padrão e é mais rápido, mas o modo function é mais preciso.

Para entender melhor a diferença entre os modos tracing e function, recomendo a leitura da documentação oficial.

E depois habilitamos o JIT para a linha de comando (opcache.enable_cli=1).

Benchmark

Se você roda o PHP na Web, o JIT pode não fazer muita diferença. Mas se você roda scripts PHP na linha de comando, o JIT pode trazer um grande ganho de performance.

Pois então, vamos fazer um benchmark para comparar a performance do PHP 8.0 com e sem JIT.

No repositório php-jit-doc você encontra um script PHP que calcula um monte de coisa para deixar o processador bem ocupado.

Não vamos entrar em detalhes de escrita e padrões deste script, pois o foco é o JIT.

Vamos rodar o script sem JIT:

./start.sh

O resultado foi:

Execution time: 6.2343468666077 seconds
Encrypted: 46d37684d6032ef0167c00d29f3358d5a180438d3e8604e4c11728699d78fdb0a32284bfa8234ed59f69e7febd0d23bebab983211565582a98da8cb5c8800e42

Agora vamos habilitar o JIT e rodar o script novamente:

./start-jit.sh

O resultado foi:

Execution time: 3.292811870575 seconds
Encrypted: 46d37684d6032ef0167c00d29f3358d5a180438d3e8604e4c11728699d78fdb0a32284bfa8234ed59f69e7febd0d23bebab983211565582a98da8cb5c8800e42

Com o JIT habilitado, o script PHP rodou 3 segundos mais rápido. Isso é um ganho de performance muito considerável.

Mas lembre-se, o JIT não é uma bala de prata. Ele pode não fazer muita diferença para scripts PHP que rodam na Web. Mas para scripts PHP que rodam na linha de comando, o JIT pode trazer um grande ganho de performance.

Conclusão

Esse foi um breve resumo sobre o JIT no PHP 8.0. Se você quiser saber mais sobre o JIT, recomendo a leitura da documentação oficial.

Trouxe somente exemplos básicos e didáticos para que você entenda o que é o JIT e como habilitá-lo. Acho que era importante trazer esse conteúdo para o perfil para que possamos falar sobre assuntos mais complexos e avançados.

Se você gostou do conteúdo, deixe um comentário e compartilhe com seus amigos. Até a próxima!

Programação Paralela e Assíncrona com PHP

Thu, 25 Apr 2024 00:00:00 -0300

Photo by Ben Griffiths on Unsplash

Introdução

PHP é uma linguagem de programação de propósito geral, amplamente utilizada para desenvolvimento web. No entanto, PHP também pode ser utilizado para desenvolvimento de aplicações desktop, scripts de automação, entre outros. Neste artigo, vamos explorar o uso de PHP para programação paralela e assíncrona.

Programação Paralela

Programação paralela é um paradigma de programação que consiste em dividir um problema em partes menores que podem ser executadas simultaneamente. Em PHP, a programação paralela pode ser feita utilizando a extensão parallel ou a extensão pthreads, que permite a criação de threads em PHP.

Mas você sabe o que é uma thread?

Uma thread é uma unidade básica de processamento que pode ser executada de forma independente. Em um programa paralelo, várias threads podem ser executadas simultaneamente, o que pode resultar em um aumento significativo de desempenho.

Quando você compra um processador com múltiplos núcleos, você está comprando a capacidade de executar várias threads simultaneamente. No entanto, para aproveitar ao máximo essa capacidade, é necessário que o software seja desenvolvido de forma a utilizar esses recursos de forma eficiente.

Exemplo de Programação Paralela em PHP

<?php
use function parallel\run;

class DataProcessor
{
 public function process(array $data): array {
 $formattedData = $this->formatData($data);
 $excel_file = $this->generateExcel($formattedData);
 $this->sendEmail($excel_file, Auth::user()->email);
 }
}

$data = range(1, 1000);
$processor = new DataProcessor();

$parallelResult1 = run(function () use ($processor, $data) {
 return $processor->process($data);
});

$parallelResult2 = $processor->process($data);

No exemplo acima, estamos utilizando a extensão parallel para executar o método process da classe DataProcessor em paralelo. Isso significa que o método será executado em uma thread separada, o que pode resultar em um aumento de desempenho.

Isso não é bala de prata, e nem sempre é a melhor solução para todos os problemas. No entanto, em alguns casos, a programação paralela pode ser uma forma eficiente de melhorar o desempenho de uma aplicação.

O exemplo acima é bastante simplificado, mas ilustra como a programação paralela pode ser utilizada em PHP. Para obter mais informações sobre a extensão parallel, consulte a documentação oficial.

Aqui está uma imagem de um exemplo de programação paralela em PHP:

Imagem ilustrativa de um exemplo de programação paralela retirada da internet.

Perceba que a programação paralela é diferente da programação assíncrona. Na programação paralela, várias threads são executadas simultaneamente, enquanto na programação assíncrona, várias tarefas podem ser executadas de forma concorrente, mas não necessariamente simultaneamente.

Programação Assíncrona

Programação assíncrona é um paradigma de programação que consiste em executar tarefas de forma concorrente, sem a necessidade de esperar que uma tarefa seja concluída para iniciar outra. Em PHP, a programação assíncrona pode ser feita utilizando a extensão swoole, que permite a criação de servidores web assíncronos em PHP.

Mas você sabe o que é um servidor web assíncrono?

Um servidor web assíncrono é um servidor que pode lidar com várias requisições simultaneamente, sem a necessidade de criar uma nova thread para cada requisição. Isso permite que o servidor seja mais eficiente e possa lidar com um grande número de requisições de forma concorrente.

Você pode achar o termo “servidor autocontido” em alguns lugares, mas a ideia é a mesma: um servidor que pode lidar com várias requisições simultaneamente, sem a necessidade de criar uma nova thread para cada requisição.

Exemplo de Programação Assíncrona em PHP

use Swoole\Http\Server;
$server = new Server("0.0.0.0", 9501);

$server->on("start", function (Server $server) {
 echo "Server started at http://{$server->host}:{$server->port}\n";
});

$server->on("request", function ($request, $response) {
 $data = $request->rawContent();
 $response->end("Received data: $data");
});

$server->start();

No exemplo acima, estamos utilizando a extensão swoole para criar um servidor web assíncrono em PHP. O servidor irá escutar na porta 9501 e responder a todas as requisições com uma mensagem contendo os dados recebidos.

Esse exemplo é bastante simplificado, mas ilustra como a programação assíncrona pode ser utilizada em PHP. Para obter mais informações sobre a extensão swoole, consulte a documentação oficial.

Aqui está uma imagem de um exemplo de programação assíncrona:

Imagem ilustrativa de um exemplo de programação assíncrona retirada da internet.

Ciclo de Vida de uma Requisição no PHP-FPM

Quando uma requisição é feita a um servidor web PHP, como o PHP-FPM, o servidor passa por várias etapas para processar a requisição e retornar uma resposta ao cliente. O ciclo de vida de uma requisição no PHP-FPM pode ser dividido em várias etapas:

Recebimento da Requisição: O servidor web (Apache, Nginx, etc.) recebe a requisição do cliente e a encaminha para o PHP-FPM.
Pool de Processos: O PHP-FPM mantém um pool de processos PHP pré-carregados para processar as requisições. Quando uma requisição é recebida, o PHP-FPM escolhe um processo disponível para processar a requisição.
Autoload: O PHP-FPM carrega os arquivos necessários para processar a requisição, incluindo as classes e funções utilizadas no script PHP. As classes e funções são carregadas automaticamente pelo PHP, de acordo com as regras de autoload definidas no arquivo composer.json.
Análise e Compilação: O PHP analisa o script PHP e compila o código em uma forma que pode ser executada pelo interpretador PHP.
Execução do Script: O PHP executa o script PHP, processando as instruções e gerando a saída da requisição.
Gerar Resposta: O PHP-FPM gera a resposta da requisição, incluindo o cabeçalho HTTP e o corpo da resposta.
Envio da Resposta: O PHP-FPM envia a resposta ao servidor web, que a encaminha de volta ao cliente.
Encerramento do Processo: Após enviar a resposta, o processo PHP é encerrado e retorna ao pool de processos disponíveis para processar novas requisições.

O ciclo de vida de uma requisição no PHP-FPM pode variar dependendo da configuração do servidor web e do PHP-FPM. No entanto, essas etapas são comuns na maioria dos servidores web PHP.

Ciclo de Vida de uma Requisição no Swoole

Quando uma requisição é feita a um servidor web assíncrono PHP, como o Swoole, o servidor passa por várias etapas para processar a requisição e retornar uma resposta ao cliente. O ciclo de vida de uma requisição no Swoole pode ser dividido em várias etapas:

O início do ciclo de vida de uma requisição no Swoole começa com a inicialização do servidor Swoole e a configuração do script PHP que será executado para processar as requisições. O servidor Swoole escuta em uma porta específica e aguarda a chegada de requisições.

Nesse ponto, o servidor já está com o autoload configurado, as classes e funções necessárias já estão carregadas e o script PHP está pronto para processar as requisições.

Recebimento da Requisição: Quando uma requisição é feita ao servidor Swoole, o servidor recebe a requisição e a encaminha para o script PHP configurado para processar a requisição.
Processamento da Requisição: O script PHP processa a requisição, executando as instruções necessárias para gerar a resposta da requisição.
Análise e Compilação: O PHP analisa o script PHP e compila o código em uma forma que pode ser executada pelo interpretador PHP.
Execução do Script: O PHP executa o script PHP, processando as instruções e gerando a saída da requisição.
Gerar Resposta: O script PHP gera a resposta da requisição, incluindo o cabeçalho HTTP e o corpo da resposta.
Envio da Resposta: O servidor Swoole envia a resposta ao cliente, encerrando o ciclo de vida da requisição.

E nesse momento, o servidor Swoole está pronto para processar novas requisições, mantendo um pool de processos PHP disponíveis para processar as requisições de forma assíncrona.

A diferença entre o ciclo de vida de uma requisição no PHP-FPM e no Swoole está na forma como o servidor PHP é inicializado e como as requisições são processadas. No PHP-FPM, o servidor PHP é inicializado para processar uma única requisição de cada vez, enquanto no Swoole, o servidor PHP é inicializado para processar várias requisições de forma assíncrona.

Conclusão

Neste artigo, exploramos o uso de PHP para programação paralela e assíncrona. A programação paralela e assíncrona são técnicas de programação que podem ser utilizadas para melhorar o desempenho de uma aplicação e lidar com um grande número de requisições de forma eficiente.

Nem tudo é regra, e nem sempre a programação paralela ou assíncrona é a melhor solução para um problema. No entanto, é sempre bom conhecer as diferentes técnicas de programação disponíveis e saber quando utilizá-las de forma eficiente.

Espero que este artigo tenha sido útil e que você tenha aprendido algo novo sobre programação paralela e assíncrona em PHP. Espero que futuramente eu consiga fazer um artigo mais detalhado sobre cada uma dessas técnicas, com exemplos mais complexos e detalhados.

Qualquer dúvida, correção ou sugestão, fique à vontade para entrar em contato. Obrigado por ler até aqui!

Referências

Autor

Luiz Schons