Prefácio
Agora, mais e mais empresas estão adotando a Spring Cloud. A Spring Boot é a próxima geração de estruturas da web e a Spring Cloud é líder nos microsserviços mais recentes e mais populares. Que motivo você tem que recusar? Muitos estudantes em Java também começaram a aprender ativamente a Spring Cloud. De fato, há outro problema aqui: embora todos tenham aprendido eureka, fita, hystrix, zuul, finge etc., ainda é difícil aplicá -lo a projetos reais.
A dificuldade dos microsserviços está na divisão de serviços. A estrutura é apenas uma ferramenta, e muitas pessoas a usarão. A divisão de serviços e a relação entre os serviços são coisas que precisam ser consideradas durante a divisão.
Hoje, um colega de classe me enviou um e -mail para me perguntar sobre as duas perguntas a seguir:
Aqui estão algumas respostas com base em minha própria experiência, apenas para referência:
Em relação à API na primeira pergunta está o controlador em cada microsserviço?
O que chamamos de API é na verdade uma interface, e a maioria deles é desenvolvida usando o Spring MVC, que é um método anotado no controlador. As anotações são as que costumamos usar:
Em relação à primeira pergunta, é necessário um projeto unificado para encapsular o controlador de outros microsserviços?
Na verdade, não há padrão fixo. A maior parte disso é encaminhada diretamente para seus serviços de negócios através do gateway da API
Pegue a categoria de negócios de sites de blogs como Yuantiandi como exemplo:
Existe uma função comercial. Quando vejo postagens específicas do blog, as informações que preciso retornar são as seguintes:
No momento, nossa interface para visualizar o artigo envolve realmente três partes dos dados, as informações do próprio artigo, as informações de comentários e as informações do autor.
Existem 3 serviços, serviços de usuário, serviços de blog e serviços de comentários
Portanto, a questão é que envolve a interação entre vários serviços antes. De fato, a mesma pergunta que o colega de classe acima me fez. Preciso ter um projeto unificado e montar outros serviços? Eles podem ser chamados um ao outro?
Eu recomendo duas maneiras de implementar isso:
1. O gateway da API encaminha diretamente para o serviço de blog
Nossa API é uma interface para obter informações sobre postagens no blog. O corpo principal deve ser o serviço do blog. Há uma interface para informações de postagem no blog no serviço de blog. Na interface, chamamos a interface de informações do usuário fornecida pelo Serviço de Usuário e também chamamos as informações de comentários da postagem no blog no serviço de comentários. Vamos ver o código pseudo:
@GetMapping ("/blog/detalhe/{id}") public bloginfo bloginfo (@pathvariable ("id") long id) {// obtenha blog blog blog = blogservice.getbyid (id); // Obter informações do usuário UserInfo userInfo = userFeignClient.getUserInfo (blog.getUserId ()); // Obtenha informações de comentários comentandoinfo comentandoInfo = commentFeignClient.getCommentInfo (id); Retorne monte todas as informações e retorne. }2. Adicione uma camada de serviço de agregação
A camada de serviço de coleta é o colega de classe acima, é necessário ter um projeto unificado para prestar serviços de montagem? Isso significa que nosso serviço de blog ainda fornece informações básicas no blog, e um serviço de agregação de negócios separado é adicionado para montar essas informações e devolvê -las ao chamador uniformemente. O pseudo-código é o seguinte:
@GetMapping ("/blog/detalhe/{id}") public bloginfo bloginfo (@pathvariable ("id") long id) {// obtenha blog blog blog = blogfeignClient.getbyId (id); // Obter informações do usuário UserInfo userInfo = userFeignClient.getUserInfo (blog.getUserId ()); // Obtenha informações de comentários comentandoinfo comentandoInfo = commentFeignClient.getCommentInfo (id); Retorne monte todas as informações e retorne. }Os dados são chamados remotamente, é claro que você pode chamá -los em paralelo aqui. Outra maneira é realizar a operação de agregação no gateway da API. Esta solução também é viável. Eu sugiro não fazer isso no gateway. O gateway da API é o mais simples possível e apenas para a frente. Adicionar a camada de serviço de agregação é uma boa escolha.
Se a sua governança de serviço for construída com o Dubbo, a camada de serviço de agregação também será um método melhor. A agregação de serviço DUBBO fornece a interface HTTP para chamadas externas.
3. O chamador obtém vários dados sozinho
Outra maneira é chamar a interface do blog, a interface de comentários e a interface do usuário. Dessa forma, a interface só precisa prestar atenção aos seus próprios dados e entregar o problema da montagem ao usuário. Isso geralmente é usado menos. É melhor retornar os dados ao chamador ao mesmo tempo e chamá -los repetidamente, especialmente no terminal móvel, que requer muitas solicitações e desperdícios de tráfego.
Resumir
Quanto a como montar os dados, você precisa decidir. Você pode colocar a montagem nos serviços comerciais correspondentes ou adicionar um serviço de agregação para montá -lo separadamente ou deixar o cliente montá -lo por si só.
Os serviços podem definitivamente ser chamados. Se eles não podem ser chamados, então qual é o sentido de separá -los? Use Feign para chamar a interface de serviço e você apenas o trata como uma chamada entre serviços.
Ok, o acima é o conteúdo inteiro deste artigo. Espero que o conteúdo deste artigo tenha certo valor de referência para o estudo ou trabalho de todos. Se você tiver alguma dúvida, pode deixar uma mensagem para se comunicar. Obrigado pelo seu apoio ao wulin.com.