Com a Arquitetura Microsserviços, uma única aplicação/funcionalidade de software é implementada como uma combinação de vários microsserviços e suas interações. Portanto, as comunicações entre os serviços e sua coordenação são vitais para uma implementação bem-sucedida da arquitetura de microsserviços.
Esse texto é uma tradução autorizada do artigo escrito por Kasun Indrasiri. Para acessar a versão original em inglês, clique aqui.
É importante entender que as tarefas que um ESB (Enterprise Service Bus) realiza em uma implementação de SOA continuam sendo necessárias quando você alterna para a Arquitetura de Microsserviços. As funcionalidades de integração realizadas pelo ESB são separadas e distribuídas entre todos os microsserviços. Portanto, estabelecer algum nível de organização lógica dos microsserviços, com base em suas granularidades e capacidades, é bastante útil quando se trata da implementação de serviços.
Assim, se observarmos mais de perto a implementação de microsserviços, podemos identificar diferentes tipos de serviços que podemos categorizar em camadas diferentes. Podemos criar uma arquitetura em camadas, como mostrado na Figura 1 (originalmente eu havia proposto essa arquitetura como um conjunto lógico de camadas, mas também poderia ser uma arquitetura concreta baseada em camadas) com diferentes tipos de microsserviços.
Figura 1: Arquitetura de Microsserviços em Camadas
Desta forma, com base em suas funcionalidades e granularidade, podemos identificar as seguintes categorias de serviços:
1. Microsserviços Atômicos/Centrais (Core)
Na camada mais inferior, temos serviços de granularidade fina autocontidos (sem dependências de serviços externos) que contém muito da lógica do negócio e pouco ou nada da lógica de comunicação de rede.
2. Composição/Integração de Microsserviços
Embora implementem lógica do negócio, os microsserviços atômicos geralmente não podem ser mapeados diretamente para uma funcionalidade completa de negócio, pois tem uma granularidade muito fina, isto é, o ideal é que implementem funções mais atômicas (e restritas a um domínio específico do negócio). Portanto, uma funcionalidade de negócio específica pode exigir uma composição de vários desses serviços atômicos. A camada do meio é composta por tais microsserviços compostos ou microsserviços de integração. Esses serviços geralmente têm que suportar uma parte significativa das funcionalidades do ESB, como roteamento, transformações, orquestração, patterns de resiliência e estabilidade, etc.
Os serviços de composição/integração são de baixa granularidade (comparativamente aos serviços atômicos), normalmente independentes entre si e também contêm lógica do negócio (roteamento, quais os serviços a serem chamados, como fazer o mapeamento de tipo de dados etc.), como os microsserviços atômicos, mas incluem ainda lógica de comunicação de rede (comunicação entre serviços através de vários protocolos, comportamentos de resiliência, como circuit breakers).
Na arquitetura de Microsserviços, a maioria dos recursos de ESB/integração (como EIPs (Enterprise Integration Patterns), patterns de resiliência e estabilidade) está na camada de serviços de composição/integração.
Esses serviços também podem fazer a ponte entre outros sistemas legados e proprietários (por exemplo, SAP ERP), APIs externas da Web (por exemplo, Salesforce), bancos de dados compartilhados, etc. (geralmente conhecidos como camada anticorrupção).
3. Serviços de API/Serviços de Borda
Você irá expor um conjunto selecionado de serviços compostos ou até mesmo alguns serviços atômicos como APIs gerenciadas usando serviços de API/serviços de Borda. Esses serviços são um tipo especial de serviços compostos, que aplicam recursos de roteamento básico, controle de versão de APIs, patterns de segurança de API, controle de fluxo (throttling), aplicam monetização, criam composições de API, etc.
Tecnologias para construção de Microsserviços
Quando se trata da implementação de microsserviços, a maioria das implementações atuais usa arbitrariamente um dado framework ou uma linguagem de programação para construir microsserviços, sem levar em conta os diferentes tipos de serviço. Com a proliferação do número de serviços, isso levará a “pesadelos” de projeto, implementação e escalabilidade. Portanto, precisamos escolher a tecnologia certa, com base na natureza dos microsserviços que estamos desenvolvendo.
Serviços Core/Atômicos: A maioria das tecnologias existentes está se concentrando na construção desses serviços. Existem inúmeros frameworks/bibliotecas disponíveis para construir este tipo de serviço (por exemplo, SpringBoot, Dropwizard, WSO2 MSF4J).
Serviços Combinados/de Integração: a maioria das implementações de microsserviços atuais tentou usar o mesmo conjunto de tecnologias para construir serviços core/atômicos e serviços compostos/de integração. No entanto, a maioria das estruturas e plataformas de microsserviços não são projetadas para a construção de serviços compostos.
Portanto, a construção de serviços compostos está se tornando a tarefa mais desafiadora (imagine a quantidade de trabalho relacionado à implementação de vários patterns de integração “do zero”, usando Java ou qualquer outra linguagem de programação semelhante) para construir a arquitetura de microsserviços.
Para superar esse problema existem tecnologias emergentes como a Ballerina (que é uma linguagem de programação projetada para composições de serviços e interações de rede) e Service Mesh frameworks (o uso de Service Mesh permite que você concentre nele as tarefas de comunicações de rede e você pode se concentrar apenas na lógica do negócio. Por exemplo, você não precisa se preocupar com circuit breaking quando invoca outro serviço).
Serviços de API/Borda: a maioria das soluções (monolíticas) de gateway e gerenciamento de API existentes pode simplificar esses serviços, desde que os serviços de API contenham o mínimo de lógica do negócio. No entanto, a maioria das implementações de microsserviços tenta colocar uma grande quantidade de lógica do negócio nessa camada, mantendo-a como um único monólito. Isso não é uma arquitetura sustentável e viola o princípio fundamental do microsserviço. Portanto, existem duas abordagens possíveis para superar esse problema:
- Transfira as composições para a camada de composição e use um gateway monolítico apenas para expô-las como APIs.
- Separe runtime do API Gateway (conceito de micro-gateway) para que cada serviço de API/borda possa ser construído e gerenciado independentemente.
As mesmas tecnologias que usamos para construir o serviço composto também podem ser usadas no desenvolvimento de serviços de API/borda. A maioria das soluções (monolíticas) existentes de gerenciamento/API Gateway ainda estão evoluindo para oferecer suporte a conceitos como micro-gateways.
Referências
Microservices for the Enterprise: Designing, Developing, and Deploying
Kasun Indrasiri e Prabath Siriwardena
Autor: Kasun Indrasiri
