Acoplamento estático e dinâmico em Microservices
I am a Senior Software Architect with extensive experience in backend development, specializing in PHP frameworks such as Laravel and Hyperf. My expertise lies in software architecture and building scalable, high-performance applications with a strong focus on Developer Experience. I design and evolve modern architectures including well-structured monoliths, microservices, and event-driven systems, always striving for a balance between performance, simplicity, and cost. I have hands-on experience in high-scale environments with over 100k users, legacy modernization, cloud cost optimization, robust API design, event-driven architectures, technical debt management, and advocating best engineering practices. As a tech community enthusiast, I organize events at DevParaná and actively share knowledge to strengthen the local ecosystem.
As a dedicated professional, I thrive on collaboration and communication, fostering strong relationships with colleagues and clients alike. My adaptability allows me to navigate challenges with ease, while my problem-solving skills enable me to find innovative solutions in dynamic environments. I believe in the power of empathy and active listening, which helps me understand diverse perspectives and create inclusive spaces. My commitment to continuous learning drives me to seek growth opportunities, ensuring that I contribute effectively to any team. I am passionate about leveraging my emotional intelligence to inspire and motivate those around me.
- Event-Driven Architecture
- API Design
- Microsserviços
- Developer Experience (DX)
- Clean Architecture / DDD / SOLID
- Microservices Architecture
- Docker
- PHP (Laravel, Hyperf, Swoole)
- Software Architecture
- Cloud Computing
- Node.js
- Laravel (PHP)
- Hyperf
- Kubernetes
- GraphQL
- Swoole
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 é a 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).
Manter 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 balançador 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.
