Arquitetura de microsserviços: implemente localmente com Java, Spring e MongoDB
Avalie esse Tutorial
"Os microsserviços são incríveis, e os aplicativos monométricos são malévolos."
Se você está lendo este artigo, você já o leu um milhão de vezes, e não serei eu que lhe direi o contrário!
Neste post, criaremos uma arquitetura de microsserviços usando o MongoDB.
O código fonte está disponível nestes dois repositórios.
Vamos usar as dependências Spring Boot e Spring Cloud para construir nossa arquitetura.
Precisamos de vários serviços para executar este projeto. Vamos falar sobre eles um por um.
Ao ler esta publicação, sugerimos que siga as instruções no arquivoREADME.md e inicie o serviço relacionado a cada seção.
O primeiro serviço de que precisamos é de um servidor de configuração.
Esse serviço nos permite armazenar todos os arquivos de configuração de nossos microsserviços em um único repositório, para que nossas configurações sejam fáceis de versionar e armazenar.
A configuração do nosso servidor de configuração é simples e direta ao ponto:
Ele nos permite localizar o repositório git que armazena nossa configuração de microsserviços e a ramificação que deve ser usada.
Observe que o único "truque" de que você precisa em seu projeto Spring Boot para iniciar um servidor de configuração é a anotação
@EnableConfigServer .Um registro de serviço é como uma lista telefônica para microsserviços. Ele monitora quais microsserviços estão em execução e onde estão localizados (endereço IP e porta). Outros serviços podem pesquisar essas informações para encontrar e se comunicar com os microsserviços de que precisam.
Um registro de serviço é útil porque permite o balanceamento de carga no lado do cliente e separa os provedores de serviços dos consumidores sem a necessidade de DNS.
Novamente, você não precisa de muito para poder iniciar um registro do serviço Spring Boot. A anotação
@EnableEurekaServerfaz toda a mágica acontecer.A configuração também vai ao ponto:
As duas últimas linhas impedem que o registro de serviço se registre para si mesmo e recupere o registro de si mesmo.
O serviço de gateway de API nos permite ter um único ponto de entrada para acessar todos os nossos microsserviços. É claro que você deve ter mais de um em produção, mas todos eles poderão se comunicar com todos os microsserviços e distribuir a carga de trabalho uniformemente balanceando a carga das consultas em seu pool de microsserviços.
Além disso, um gateway de API é útil para abordar preocupações transversais, como segurança, monitoramento, coleta de métricas e resiliência.
Quando nossos microsserviços são iniciados, eles se registram no registro de serviços. O gateway de API pode usar esse registro para localizar os microsserviços e distribuir as queries de acordo com sua configuração de roteamento.
Observe que nosso gateway de API é executado na porta 8080.
Finalmente, temos nossos microsserviços MongoDB.
Os microsserviços devem ser independentes uns dos outros. Por esse motivo, precisamos de duas instâncias do MongoDB: uma para cada microsserviço.
Observe que, nos arquivos de configuração dos serviços da empresa e do funcionário, eles estão sendo executados, respectivamente, nas portas 8081 e 8082.
Observe que os dois microsserviços estão conectados a dois clusters MongoDB diferentes para manter sua dependência. O serviço da empresa está usando o nó do MongoDB na porta 27017 e o serviço do funcionário está na porta 27018.
Naturalmente, isso é somente se você estiver executando tudo localmente. Na produção, eu recomendamos usar dois clusters no MongoDB Atlas. Você pode substituir o URI MongoDB pelas variáveis de ambiente (consulte README.md).
Neste ponto, você deve ter cinco serviços em execução:
- Um servidor de configuração na porta 8888
- Um registro de serviço na porta 8761
- Um gateway de API na porta 8080
- Dois microsserviços:
- serviço de empresa na porta 8081
- serviço de funcionário na porta 8082
E dois nós do MongoDB nas portas 27017 e 27018 ou dois clusters do MongoDB no MongoDB Atlas.
Observe que o serviço de funcionário envia consultas ao serviço da empresa para recuperar os detalhes da empresa dos funcionários.
Isso confirma que o registro de serviço está fazendo seu trabalho corretamente porque a URL contém apenas uma referência ao microsserviço da empresa, não a seu IP e porta diretos.
E voilà! Agora você tem uma arquitetura básica de microsserviço em execução que é fácil de usar para iniciar seu projeto.
Nessa arquitetura, pudemos integrar perfeitamente recursos adicionais para melhorar o desempenho e a capacidade de manutenção na produção. O cache seria essencial, especialmente com um número potencialmente grande de funcionários na mesma empresa, aliviando significativamente a carga do serviço da empresa.
A adição de um disjuntor Spring Cloud também poderia melhorar a resiliência na produção e um Spring Cloud Sleuth ajudaria no rastreamento distribuído e na configuração automática.
Em caso de dúvidas, acesse nosso website da comunidade de desenvolvedores, no qual os engenheiros do MongoDB e a MongoDB Community ajudarão você a colocar em prática sua próxima grande ideia com o MongoDB.
Principais comentários nos fóruns
Ainda não há comentários sobre este artigo.