Microsserviços fazem uso da automação por pipelines para implementar entrega contínua e integração contínua. Essa prática é fundamental para expandir de forma consistente o número de serviços digitais, garantir o nível de qualidade de entrega no produto final e alcançar os resultados desejados de maneira mais rápida.
São executados em unidades dedicadas de execução, chamadas contêineres. A automação do processo permite não apenas empacotamento e teste, mas também a entrega do produto final com todos os recursos necessários em um contêiner com o microsserviço embutido.
Os contêineres podem ser dimensionados de forma independente, permitindo a escalabilidade de acordo com as necessidades da solução como um todo.
A implementação de microsserviços é flexível, podendo cada microsserviço ser escrito em uma linguagem de programação diferente devido ao fato de serem executados separadamente. A comunicação entre eles é feita por meio de interfaces bem definidas sobre protocolos conhecidos, como JSON. Isso dá flexibilidade a solução, uma vez que podemos explorar as melhores abordagens e recursos de cada linguagem de programação.
Microsserviços devem abordar um domínio de negócios específico e oferecer documentação bem definida e pública, usando mecanismo de documentação de API's como o swagger.
Em essência, esses são os principais motivadores que acreditamos que devemos considerar quando começar a pensar em um novo design de solução usando o estilo de arquitetura de microsserviços (MSA).
A arquitetura de micros serviço (MSA) baseia-se no desenvolvimento de uma única aplicação a partir de um conjunto de serviços pequenos e independentes, executados em seus próprios processos, desenvolvidos e implantados de forma independente, ou seja, um microsserviço tem que ser autossuficiente.
A maioria das definições de MSA explica isso como um conceito arquitetônico focado em segregar os serviços disponíveis em um conjunto de serviços independentes. No entanto, os microsserviços não estão apenas dividindo os serviços disponíveis em serviços independentes.
O processo de implementação consistem em primeiramente identificar os recursos de negócios exigidos da aplicação. Em seguida, esses recursos de negócios são implementados como serviços independentes, refinados e autônomos. Pode-se adotar diferentes pilhas de tecnologia, com cada serviço atendendo a um escopo de negócio muito específico e limitado. Cada requisito de negócio motiva a implementação de um microsserviço adicional, criado a partir do conjunto original de serviços. É importante perceber que isso vai além de simplesmente dividir os serviços para chegar a terrenos mais complexos.
O projeto de microsserviço inicia-se pela decisão adequada do seu tamanho, escopo e recursos. Abaixo estão algumas das principais preocupações e equívocos sobre o assunto:
Linhas de código/tamanho de equipe são métricas ruins: Existem várias discussões sobre como decidir o tamanho dos microsserviços com base no número de linhas de código da implementação ou no tamanho de sua equipe (ou seja, equipe de duas pizzas). No entanto, essas são consideradas métricas muito impraticáveis e ruins, porque ainda podemos desenvolver serviços que violam completamente os princípios de arquitetura de microsserviços com menos código e equipes de duas pizzas.
'Micro' é um termo enganador: a maioria dos desenvolvedores tende a pensar que eles deveriam tentar tornar o serviço o menor possível. Isso é uma má interpretação.
No contexto de serviços da Web/SOA, os serviços geralmente são implementados em diferentes granularidades - de algumas funções a várias dezenas de funções. Ter web services e reformulá-los como microsserviços não lhe trará nenhum benefício de MSA.
Em aplicações monolíticas, as funções de negócios de diferentes processadores/componentes são chamadas usando chamadas de função ou chamadas de método em nível de idioma. No SOA, isso foi transferido para um sistema de mensagens de nível de serviço da Web muito mais fracamente acoplado, que é baseado principalmente no SOAP, além de protocolos diferentes, como HTTP, JMS..
Na arquitetura monolítica, a aplicação armazena dados em bancos de dados únicos e centralizados para implementar várias funções/capacidades da aplicação. No MSA, as funções estão dispersas em vários microsserviços e, se usarmos o mesmo banco de dados centralizado, é difícil garantir o baixo acoplamento entre os serviços (por exemplo, se o esquema do banco de dados tiver mudado de um determinado microsserviço, isso quebra vários outros serviços). Portanto, cada microsserviço precisaria ter seu próprio banco de dados.
Cada microsserviço pode ter um banco de dados privado para persistir os dados necessários para implementar a funcionalidade comercial oferecida a partir dele. Um determinado microsserviço só pode acessar o banco de dados privado dedicado, mas não os bancos de dados de outros microsserviços. Em alguns cenários de negócios, talvez seja necessário atualizar vários bancos de dados para uma única transação. Em tais cenários, os bancos de dados de outros microsserviços devem ser atualizados apenas por meio de sua API de serviço (não é permitido acessar diretamente o banco de dados).
O gerenciamento de dados descentralizados oferece microsserviços totalmente desacoplados e a liberdade de escolher técnicas de gerenciamento de dados (SQL ou NoSQL etc., sistemas de gerenciamento de banco de dados diferentes para cada serviço). No entanto, para casos de uso transacionais complexos que envolvem vários microsserviços, o comportamento transacional deve ser implementado usando as APIs oferecidas de cada serviço e a lógica reside no nível do cliente ou intermediário.
No MSA, o número de microsserviços com os quais vamos precisar lidar é bastante alto. Suas localizações mudam dinamicamente devido à natureza rápida e ágil de desenvolvimento/implantação de microsserviços. Portanto, precisaremos encontrar a localização de um microsserviço durante o tempo de execução. A solução para esse problema é e usar um registro de serviço.
O registro de serviço contém os metadados das instâncias de microsserviço (que incluem seus locais reais, porta do host, etc.). As instâncias de microsserviço são registradas no registro de serviço na inicialização e cancelado o registro no desligamento. Os consumidores podem encontrar os microsserviços disponíveis e suas localizações através do registro de serviços.
Para encontrar os microsserviços disponíveis e sua localização, precisamos ter um mecanismo de descoberta de serviço. Existem dois tipos de mecanismos de descoberta de serviço - descoberta no lado do cliente e descoberta no lado do servidor. Vamos dar uma olhada mais de perto nesses mecanismos de descoberta de serviço:
Descoberta do lado do cliente: nessa abordagem, o cliente ou o API Gateway obtém o local de uma instância de serviço consultando um registro de serviço.
Aqui, o cliente/API-GW precisa implementar a lógica de descoberta de serviço chamando o componente Service-Registry.
Descoberta do lado do servidor: nessa abordagem, os clientes/API-GW enviam a solicitação para um componente (como um balanceador de carga) que é executado em uma localização conhecida. Esse componente chama o registro de serviço e determina a localização absoluta do microsserviço.
As soluções de implantação de microsserviços, como o Kubernetes, oferecem mecanismos de descoberta do lado do servidor.
O Docker é um software livre que permite a implantação contêineres de aplicações autossuficientes em ambientes Linux e Windows, sendo o atual padrão de mercado para a implantação de microsserviços que atendam aos requisitos acima. Os principais passos são:
Empacotar o microsserviço como uma imagem de container.
Implementar cada instância de serviço como um contêiner.
O dimensionamento é feito a partir da alteração do número de instâncias do contêiner. Construir, implantar e iniciar um microsserviço é mais rápido, já que estamos usando contêineres Docker, mais leves que uma VM comum.
O Kubernetes gerencia um cluster de contêineres docker como um sistema único, controlando e executando os contêineres em vários hosts. Oferece colocation de contêineres, descoberta de serviço e controle de replicação.
Tais recursos são essenciais no contexto de microsserviços. O uso do Kubernetes para implantação de microsserviços é uma abordagem extremamente poderosa, em especial na implantação de microsserviços em larga escala.
A proteção de microsserviços é implementada por padrões de segurança de API amplamente usados. O cliente autentica-se com um servidor de autorização e obtém um token opaco, conhecido como 'token de acesso'. O token de acesso tem zero informações sobre o usuário/cliente. Só tem uma referência as informações do usuário que só podem ser recuperadas pelo servidor de autorização. Portanto, isso é conhecido como um 'token de referência e' é seguro usar esse token mesmo na rede pública/internet.