Olá, pessoal!
No post anterior, apresentei a visão geral do My Broker B3. Hoje, vamos "abrir o capô" e falar sobre a fundação que sustenta todo esse ecossistema: a infraestrutura.
Para um sistema de microserviços, configurar manualmente cada banco de dados, broker de mensagens e ferramenta de monitoramento seria um pesadelo de produtividade. Por isso, utilizei o Docker Compose para criar um ambiente local que replica fielmente as necessidades de um sistema distribuído de alta complexidade.
🏗️ A Estratégia de Isolamento de Domínios
Uma decisão central no design deste projeto foi o isolamento de dados por domínio. Em vez de um único banco de dados monolítico, cada microserviço possui sua própria instância ou base lógica:
-
Persistência Relacional (SQL): Utilizo MySQL 8.0 para os domínios da Corretora (
Identity,Wallet,OrdereAsset) e PostgreSQL 15 para o núcleo da B3. Isso garante que uma falha no banco de ordens não afete o serviço de identidade, por exemplo. - Camada de Cache (Redis): Implementei instâncias leves de Redis (Alpine) isoladas para dados de mercado e carteira, garantindo latência sub-milissegundo onde a velocidade é crítica.
- NoSQL (MongoDB): Uma instância centralizada para armazenar dados não estruturados, como históricos de preços (Ticks) e relatórios.
📡 Mensageria: O Backbone do Sistema
O arquivo docker-compose.yml orquestra dois gigantes da mensageria para diferentes propósitos:
- Apache Kafka (KRaft): Configurado no modo moderno KRaft (sem Zookeeper), o que torna o container mais leve e estável para o desenvolvimento local. Ele lida com o alto volume de eventos internos.
- RabbitMQ: Atua como a nossa ponte (Bridge) de comunicação entre o Broker e a B3, garantindo o desacoplamento total entre os sistemas.
📊 Observabilidade desde o "Dia 1"
Não se gerencia o que não se mede. Por isso, incluí Prometheus e Grafana diretamente na infraestrutura base. Assim que um microserviço sobe, ele já pode exportar métricas que são visualizadas em dashboards em tempo real.
🔐 Segurança e Configuração com .env
Um detalhe crucial para qualquer projeto profissional é a gestão de segredos e configurações. No docker-compose.yml, utilizei variáveis de ambiente para evitar o hardcoding de senhas e portas.
Toda a configuração sensível fica isolada em um arquivo .env (ignorado pelo Git), enquanto um arquivo .env.example é fornecido como template. Isso demonstra uma boa prática de segurança:
# Trecho do docker-compose utilizando variáveis de ambiente
broker-identity-db:
image: mysql:8.0
environment:
MYSQL_DATABASE: ${BROKER_IDENTITY_DB_NAME}
MYSQL_USER: ${BROKER_DB_USER}
MYSQL_PASSWORD: ${BROKER_DB_PASS}
🚀 Como Executar
Com a infraestrutura automatizada, basta um comando para subir os 12 containers:
docker-compose up -d
Essa padronização garante que o ambiente de desenvolvimento seja idêntico para qualquer pessoa que colaboresse no projeto se fosse o caso, eliminando o clássico problema do "na minha máquina funciona".
No próximo post, vamos falar sobre o primeiro microserviço que criei que faz a integração com API externa da Brappi, armazena em um banco mongo e publica em um tópico Kafka os preços atualizados!
🔎 Sobre a série
⬅️ Post Anterior: Construindo um ecossistema de Microserviços.
📘 Índice da Série: Guia da Série.
Links:
Top comments (0)