Microsserviços
Neste artigo decidi escrever um pouco sobre microsserviços, esse conhecimento é importante no desenvolvimento web e bem solicitado em diversas vagas de emprego. Saber o básico sobre microsserviços pode ser de grande ajuda.
Desvantagens:
Cada pequeno aplicativo gerado e independente é um microsserviço e tem a sua responsabilidade bem definida. Cada microsserviço também tem seu próprio banco de dados. Desta forma temos mais flexibilidade, pois mesmo se um serviço tiver problemas os outros vão continuar funcionando.
A comunicação entre os microsserviços é muito importante para que todos eles formem um grande aplicativo. Eles podem ser comunicar via HTTP por exemplo, um serviço fazendo requisições para outro por meio de uma API Rest. Também é possível usar uma comunicação mais especifica para estes casos como por exemplo GRPC.
Várias equipes de desenvolvimento podem ser formadas para trabalhar em cada microsserviço, cada uma com sua metodologia e tecnologia de desenvolvimento.
Vantagens:
Desvantagens:
https://martinfowler.com/bliki/MonolithFirst.html
Desenvolver microsserviços primeiro pode trazer problemas e complexidade. Pode ser mais vantajoso fazer o aplicativo de forma monolítica e depois identificar quais partes do aplicativo podem se tornar um microsserviço independente. Desta forma a aplicação vai sendo quebrada em pequenas partes com menos dificuldades, esse é um padrão chamado de Strangler pattern (padrão de estrangulamento).
Business service – agreda dados e fornece operações mais complexas.
Translation service – acessa recursos externos.
Edge service – entrega serviços direto ao cliente
Vamos imaginar que temos um aplicativo monolítico. Para separar um microsserviço, por exemplo um data service, precisamos identificar um domínio e a partir dele separá-lo do aplicativo.
É importante ter conhecimento sobre Domain-driven Design, isso vai nos deixar claro o que é um domínio. Começamos modelando o domínio sem pensar na persistência.
Por exemplo, temos o site de uma escola, queremos um data service do domínio de aluno. Toda vez que o aluno quiser se cadastrar ou alterar dados, ele vai acessar esse domínio. Cada domínio tem seus dados suas regras.
Devemos avaliar quais ações serão disponibilizadas por este serviço e pensar primeiro no contrato depois na implementação.
Business service
É a união de vários data services, as vezes uma operação precisa de mais de um modelo do nosso domínio.
Por exemplo, matricular um aluno não envolva apenas inserir um aluno, talvez precisamos ter um registro dele em outros serviços, como no financeiro. Então pode ser muito mais complexo do que lidar apenas com um domínio.
O business service vai matricular o aluno, então vai usar vários data services vai trabalhar em um nível mais alto.
Compartilhando código
Quando temos vários serviços precisamos compartilhar trechos de códigos, por exemplo a lógica de autenticação pode ser a mesma em todos os serviços. Poderíamos criar um microsserviço de autenticação, porém isso pode não ser o melhor, criar muitos serviços também pode ser um problema.
Podemos ter um trecho de código que pode ser compartilhado entre os serviços que faz essa autenticação, chamamos isso de Sidecar pattern. Esse modulo compartilhado ao ser atualizado, vai ser replicado em todos os serviços.
Como a web funciona?
Para saber como funcionam os microsserviços, precisamos antes entender como a web funciona. É muito importante entender o protocolo HTTP, em resumo o cliente (celular, computador, tablet) faz um acesso, por exemplo digitamos no navegador um endereço de um site. Desta forma o cliente faz uma requisição ao servidor. O servidor processa o pedido e fornece uma resposta, que muitas vezes pode ser, exibir o conteúdo do site ou solicitar um login.Protocolo HTTP
Aplicações Monolíticas
Um aplicativo monolítico tem todas ou a maioria das funcionalidades em um único processo, além dividir os componentes em camadas ou bibliotecas internas.
Desvantagens:
- Demora para fazer o deploy.
- Uma falha pode danificar ou até derrubar o sistema
- Provavelmente usa apenas uma tecnologia.
- Complexidade e risco de implantação de novas ideias.
Microsserviços
Em uma arquitetura de microsserviços onde cada parte do nosso aplicativo vai ser um pequeno aplicativo independente.
Cada pequeno aplicativo gerado e independente é um microsserviço e tem a sua responsabilidade bem definida. Cada microsserviço também tem seu próprio banco de dados. Desta forma temos mais flexibilidade, pois mesmo se um serviço tiver problemas os outros vão continuar funcionando.
A comunicação entre os microsserviços é muito importante para que todos eles formem um grande aplicativo. Eles podem ser comunicar via HTTP por exemplo, um serviço fazendo requisições para outro por meio de uma API Rest. Também é possível usar uma comunicação mais especifica para estes casos como por exemplo GRPC.
Várias equipes de desenvolvimento podem ser formadas para trabalhar em cada microsserviço, cada uma com sua metodologia e tecnologia de desenvolvimento.
Vantagens:
- Projetos independentes, tecnologias independentes
- Falhas ficam isoladas não interrompendo os outros serviços.
- Deploy mais rapido.
- Maior complexidade de desenvolvimento e infra.
- Debug mais complexo.
- Comunicação entre serviços deve ser bem pensada.
- Várias tecnologias podem se tornar um problema
- Monitoramento é necessário e mais complexo.
Método Monolitico First
Conforme abordado por Martin Fowler no site abaixo:https://martinfowler.com/bliki/MonolithFirst.html
Desenvolver microsserviços primeiro pode trazer problemas e complexidade. Pode ser mais vantajoso fazer o aplicativo de forma monolítica e depois identificar quais partes do aplicativo podem se tornar um microsserviço independente. Desta forma a aplicação vai sendo quebrada em pequenas partes com menos dificuldades, esse é um padrão chamado de Strangler pattern (padrão de estrangulamento).
Tipos de Serviços
Data service – serviço que vai armazenar e expor dados.Business service – agreda dados e fornece operações mais complexas.
Translation service – acessa recursos externos.
Edge service – entrega serviços direto ao cliente
Separando serviços
Data serviceVamos imaginar que temos um aplicativo monolítico. Para separar um microsserviço, por exemplo um data service, precisamos identificar um domínio e a partir dele separá-lo do aplicativo.
É importante ter conhecimento sobre Domain-driven Design, isso vai nos deixar claro o que é um domínio. Começamos modelando o domínio sem pensar na persistência.
Por exemplo, temos o site de uma escola, queremos um data service do domínio de aluno. Toda vez que o aluno quiser se cadastrar ou alterar dados, ele vai acessar esse domínio. Cada domínio tem seus dados suas regras.
Devemos avaliar quais ações serão disponibilizadas por este serviço e pensar primeiro no contrato depois na implementação.
Business service
É a união de vários data services, as vezes uma operação precisa de mais de um modelo do nosso domínio.
Por exemplo, matricular um aluno não envolva apenas inserir um aluno, talvez precisamos ter um registro dele em outros serviços, como no financeiro. Então pode ser muito mais complexo do que lidar apenas com um domínio.
O business service vai matricular o aluno, então vai usar vários data services vai trabalhar em um nível mais alto.
- Identifique o processo que você pretende expor.
- Identifique os domínios que serão necessários nesse serviço
- Defina a API que sera usada focando no domínio não nos dados
- Construa serviços de domínio para executar os processos
Compartilhando código
Quando temos vários serviços precisamos compartilhar trechos de códigos, por exemplo a lógica de autenticação pode ser a mesma em todos os serviços. Poderíamos criar um microsserviço de autenticação, porém isso pode não ser o melhor, criar muitos serviços também pode ser um problema.
Podemos ter um trecho de código que pode ser compartilhado entre os serviços que faz essa autenticação, chamamos isso de Sidecar pattern. Esse modulo compartilhado ao ser atualizado, vai ser replicado em todos os serviços.
API Gateway
Faz parte da comunicação entre os serviços. Por meio de um ponto de entrada o cliente acessa todos os microsserviços que forem necessários para receber a resposta. Ela fornece um proxy, uma fachada para as necessidades reais.
A desvantagem é que pode se tornar um ponto central de falhas.
Logs
É importante ter um sistema de logs trabalhando junto com os microsserviços. Através dos logs podemos identificar informações valiosas sobre nossa aplicação. Eles precisam ter um formato padrão para que possam ser compartilhados entre todos os serviços. Todos os logs devem ser agregados em um ponto onde possamos fazer consultas. Podemos também rastrear as chamadas através dos logs e também encontrar problemas.
Faz parte da comunicação entre os serviços. Por meio de um ponto de entrada o cliente acessa todos os microsserviços que forem necessários para receber a resposta. Ela fornece um proxy, uma fachada para as necessidades reais.
A desvantagem é que pode se tornar um ponto central de falhas.
Logs
É importante ter um sistema de logs trabalhando junto com os microsserviços. Através dos logs podemos identificar informações valiosas sobre nossa aplicação. Eles precisam ter um formato padrão para que possam ser compartilhados entre todos os serviços. Todos os logs devem ser agregados em um ponto onde possamos fazer consultas. Podemos também rastrear as chamadas através dos logs e também encontrar problemas.
Agregando métricas
Para conhecer os estados de cada microsserviço e também da aplicação em geral, precisamos de métricas. Podemos gerar métricas por meio de instrumentação, usando ferramentas específicas. As métricas nos ajudam a manter o sistema saudável, elas nos fornecem informações claras.
Para conhecer os estados de cada microsserviço e também da aplicação em geral, precisamos de métricas. Podemos gerar métricas por meio de instrumentação, usando ferramentas específicas. As métricas nos ajudam a manter o sistema saudável, elas nos fornecem informações claras.
Comentários
Postar um comentário