# Acoplamento estático e dinâmico em Microservices 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** ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1728676759014/bb9c5c1b-8245-4a17-9691-a5a166d7539f.png align="center") ### **Componentes:** 1. **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. 2. **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. 3. **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. 4. **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. 5. **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. 6. **RabbitMQ**: * Permite a mensageria assíncrona entre serviços, facilitando a comunicação desacoplada. * Transmite eventos de pedidos e transações para partes interessadas. 7. **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. 8. **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. 9. **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. 10. **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: 1. **Dependência de código**: um microservice chama diretamente outro através de uma chamada de função ou API. 2. **Dependência de banco de dados**: um microservice acessa diretamente o banco de dados de outra aplicação. 3. **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: 1. **Dependência de mensageria**: um microservice envia uma mensagem para um barramento de mensagens e espera que outro serviço responda. 2. **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](https://www.amazon.com.br/Arquitetura-Software-Trade-off-Arquiteturas-Distribu%C3%ADdas/dp/8550819840)