Os microsserviços são um estilo de arquitetura popular para criar aplicações resilientes, altamente dimensionáveis, possíveis de implementar de forma independente e capazes de evoluir rapidamente. Contudo, uma boa arquitetura de microsserviços requer uma abordagem diferente no que respeita a conceção e criação de aplicações.
Uma arquitetura de microsserviços consiste numa coleção de pequenos serviços autónomos. Cada serviço é autônomo e deve implementar um único recurso de negócios dentro de um contexto limitado. Um contexto delimitado é uma divisão natural dentro de uma empresa e fornece um limite explícito dentro do qual existe um modelo de domínio.
O que são os microsserviços?
Os microsserviços são serviços pequenos, independentes e relativamente interligados. Uma única pequena equipa de programadores consegue escrever e tratar da manutenção de um serviço.
Cada serviço é um código base separado, que pode ser gerido por uma equipa de desenvolvimento pequena.
Os serviços podem ser implementados de forma independente. Uma equipa pode atualizar um serviço existente sem reconstruir e reimplementar toda a aplicação.
Os serviços são responsáveis pela persistência dos seus próprios dado ou estado externo. Isto é diferente do modelo tradicional, em que uma camada de dados separada processa a persistência dos dados.
Os serviços comunicam entre si através de APIs bem definidas. Os detalhes internos da implementação de cada serviço estão ocultos de outros serviços.
Suporta programação poliglota. Por exemplo, os serviços não precisam compartilhar a mesma pilha de tecnologia, bibliotecas ou estruturas.
Além dos próprios serviços, alguns outros componentes estão presentes numa arquitetura de microsserviços típica:
Gestão/orquestração. Este componente é responsável por colocar os serviços em nós, identificando falhas, reequilibrando os serviços nos nós e assim sucessivamente. Normalmente, este componente é uma tecnologia pronta a utilizar, como o Kubernetes, em vez de ser algo personalizado.
Gateway de API. O gateway da API é o ponto de entrada para os clientes. Em vez de chamarem serviços diretamente, os clientes chamam o gateway de API, o qual reencaminha a chamada para os serviços adequados no back-end.
As vantagens de utilizar um gateway de API incluem:
Dissocia os clientes dos serviços. Pode dar uma versão dos serviços e refatorizá-los, sem ser necessário atualizar todos os clientes.
Os serviços podem utilizar protocolos de mensagens que não são adequados para a Web, como o AMQP.
O Gateway da API pode realizar outras funções transversais, como a autenticação, o registo, a terminação de SSL e o balanceamento de carga.
Políticas prontas para uso, como para limitação, armazenamento em cache, transformação ou validação.
Benefícios
Agilidade. Como os microsserviços são implementados de forma independente, pode gerir a correção de erros e o lançamento de funcionalidades com mais facilidade. Pode atualizar um serviço sem implementar novamente toda a aplicação e reverter uma atualização caso algo corra mal. Em muitas aplicações tradicionais, se for encontrado um erro numa parte da aplicação, esse erro poderá bloquear todo o processo de lançamento da versão. Novos recursos podem ficar retidos aguardando que uma correção de bug seja integrada, testada e publicada.
Equipas pequenas e direcionadas. Um microsserviço deve ser pequeno ao ponto de ser possível que uma única equipa consiga criá-lo, testá-lo e implementá-lo. As equipas mais pequenas promovem uma maior agilidade. As equipas grandes tendem a ser menos produtivas, porque a comunicação é mais demorada, a despesa de gestão aumenta e a agilidade diminui.
Base de código pequena. Em um aplicativo monolítico, há uma tendência ao longo do tempo para as dependências de código se tornarem emaranhadas. Adicionar um novo recurso requer tocar no código em muitos lugares. Como os microsserviços não partilham código nem arquivos de dados, a arquitetura de microsserviços minimiza as dependências, o que torna mais fácil adicionar novas funcionalidades.
Misto de tecnologias. As equipas podem escolher a tecnologia mais adequada ao respetivo serviço, através da utilização de várias tecnologias diferentes, conforme as necessidades.
Isolamento de falhas. Se um microsserviço individual ficar indisponível, ele não interromperá todo o aplicativo, desde que todos os microsserviços upstream sejam projetados para lidar com falhas corretamente. Por exemplo, você pode implementar o padrão Disjuntor ou projetar sua solução para que os microsserviços se comuniquem entre si usando padrões de mensagens assíncronas.
Escalabilidade. Os serviços podem ser dimensionados independentemente, o que lhe permite ampliar os subsistemas que necessitem de mais recursos sem que, para isso, tenha de aumentar horizontalmente toda a aplicação. Usando um orquestrador como o Kubernetes, você pode empacotar uma maior densidade de serviços em um único host, o que permite uma utilização mais eficiente dos recursos.
Isolamento de dados. É muito mais fácil fazer atualizações de esquema porque apenas é afetado um único microsserviço. Em um aplicativo monolítico, as atualizações de esquema podem se tornar muito desafiadoras, porque diferentes partes do aplicativo podem tocar nos mesmos dados, tornando arriscadas quaisquer alterações no esquema.
Desafios
Os microsserviços não trazem apenas benefícios. Eis alguns dos desafios a considerar antes de adotar uma arquitetura de microsserviços.
Complexidade. Uma aplicação de microsserviços tem mais partes em movimento do que a aplicação monolítica equivalente. Cada serviço é mais simples, mas o sistema como um todo é mais complexo.
Desenvolvimento e teste. Escrever um pequeno serviço que depende de outros serviços dependentes requer uma abordagem diferente de escrever um aplicativo monolítico tradicional ou em camadas. As ferramentas existentes não foram sempre concebidas para funcionar com as dependências do serviço. Refatorizar através de limites de serviço pode ser difícil. Testar as dependências do serviço também é particularmente desafiante, especialmente quando a aplicação está a evoluir rapidamente.
Falta de governação. A abordagem descentralizada da criação de microsserviços tem vantagens, mas também pode provocar problemas. Pode ficar com tantas linguagens e estruturas diferentes que se torna difícil gerir a aplicação. Poderá ser útil implementar alguns padrões em todo o projeto, sem restringir excessivamente a flexibilidade das equipas. Isto aplica-se especialmente a funcionalidades transversais, como o registo.
Congestionamento e latência de rede. A utilização de muitos serviços pequenos e granulares pode originar uma maior comunicação entre serviços. Além disso, se a cadeia de dependências de serviços ficar muito longa (o serviço A chama o serviço B, que chama o C, etc.), a latência adicional pode tornar-se um problema. Terá de estruturar as APIs cuidadosamente. Evite APIs excessivamente tagarelas, pense em formatos de serialização e procure locais para usar padrões de comunicação assíncronos, como nivelamento de carga baseado em fila.
Integridade dos dados. Com cada microsserviço responsável pela sua própria persistência de dados. Como resultado, a consistência dos dados pode ser um desafio. Adote a consistência eventual sempre que possível.
Gestão. O êxito dos microsserviços requer uma cultura DevOps madura. O registo correlacionado entre serviços pode ser um desafio. Normalmente, o registo tem de correlacionar múltiplas chamadas de serviço para uma única operação de utilizador.
Controlo de versões. As atualizações de um serviço não podem interromper os serviços que dependem dele. Múltiplos serviços poderiam ser atualizados num determinado momento pelo que, sem uma estrutura cuidadosa, poderia ter problemas de retrocompatibilidade ou compatibilidade com as versões seguintes.
Competências. Os microsserviços são sistemas altamente distribuídos. Avalie cuidadosamente se a equipa tem as competências e a experiência para o êxito.
Processo de criação de uma arquitetura de microsserviços
Os artigos aqui listados apresentam uma abordagem estruturada que permite conceber, criar e operar uma arquitetura de microsserviços.
Análise de domínios. Para evitar algumas armadilhas comuns ao criar microsserviços, utilize a análise de domínios para definir os limites dos microsserviços. Siga estes passos:
- Utilizar a análise de domínios para modelar os microsserviços.
- Utilizar o DDD tático para conceber microsserviços.
- Identificar os limites dos microsserviços.
Conceber os serviços. Os microsserviços requerem uma abordagem diferente no que respeita a conceção e criação de aplicações. Para obter mais informações, veja Conceber uma arquitetura de microsserviços.
Operar na produção. Como as arquiteturas de microsserviços são distribuídas, as suas operações têm obrigatoriamente de ser robustas no que respeita a implementação e monitorização.
- CI/CD para arquiteturas de microsserviços
- Criar um pipeline CI/CD para microsserviços no Kubernetes
- Monitorizar microsserviços em execução no Azure Kubernetes Service (AKS)