Prefacio
Ahora, cada vez más empresas están adoptando Spring Cloud. Spring Boot es la próxima generación de marcos web y Spring Cloud es el líder en los microservicios más recientes y populares. ¿Qué razón tienes que rechazar? Muchos estudiantes en Java también han comenzado a aprender activamente Spring Cloud. De hecho, hay otro problema aquí: aunque todos han aprendido Eureka, Ribbon, Hystrix, Zuul, Feign, etc., es difícil aplicarlo a proyectos reales.
La dificultad de los microservicios radica en la división de los servicios. El marco es solo una herramienta, y muchas personas la usarán. La división del servicio y la relación entre los servicios son cosas que deben considerarse durante la división.
Hoy un compañero de clase me envió un correo electrónico para preguntarme sobre las siguientes dos preguntas:
Aquí hay algunas respuestas basadas en mi propia experiencia, solo como referencia:
Con respecto a la API en la primera pregunta, ¿el controlador está bajo cada microservicio?
Lo que llamamos API es en realidad una interfaz, y la mayoría de ellos se desarrollan utilizando Spring MVC, que es un método anotado en el controlador. Las anotaciones son las que a menudo usamos:
Con respecto a la primera pregunta, ¿requiere un proyecto unificado para encapsular el controlador de otros microservicios?
En realidad no hay un patrón fijo. La mayor parte de esto se envía directamente a sus servicios comerciales a través de la puerta de enlace API
Tome la categoría comercial de sitios web de blogs como Yuantiandi como ejemplo:
Hay una función comercial. Cuando veo publicaciones de blog específicas, la información que necesito devolver es la siguiente:
En este momento, nuestra interfaz para ver el artículo realmente involucra tres partes de los datos, la información del artículo en sí, la información de comentarios y la información del autor.
Hay 3 servicios, servicios de usuarios, servicios de blog y servicios de comentarios.
Entonces, la pregunta es que implica la interacción entre múltiples servicios antes. De hecho, la misma pregunta que me hizo el compañero de clase anterior. ¿Necesito tener un proyecto unificado y ensamblar otros servicios? ¿Se pueden llamar entre sí?
Recomiendo dos formas de implementar esto:
1. La API Gateway reenvía directamente al servicio de blog
Nuestra API es una interfaz para obtener información de publicaciones de blog. El cuerpo principal debe ser el servicio de blog. Hay una interfaz para la información de la publicación de blog en el servicio de blog. En la interfaz, llamamos a la interfaz de información del usuario proporcionada por el servicio de usuario, y también llamamos a la información de comentarios de la publicación del blog en el servicio de comentarios. Veamos el código pseudo:
@Getmapping ("/blog/detalle/{id}") public BlogInfo BlogInfo (@PathVariable ("ID") Long Id) {// Obtener información de blog Blog Blog = BlogService.getById (id); // Obtener información de usuario userInfo userInfo = userFeignClient.getUserInfo (Blog.getuserId ()); // Obtener información de comentarios CommentInfo CommentInfo = commentfeignClient.getCommentInfo (id); Devolver ensamble toda la información y devolución. }2. Agregue una capa de servicio de agregación
La capa de servicio de recolección es el compañero de clase anterior, ¿es necesario tener un proyecto unificado para realizar servicios de ensamblaje? Esto significa que nuestro servicio de blog todavía proporciona información básica en el blog, y se agrega un servicio de agregación comercial separada para ensamblar esta información y devolverla a la persona que llama de manera uniforme. El pseudo-código es el siguiente:
@GetMapping ("/blog/detalle/{id}") público bloginfo BlogInfo (@PathVariable ("ID") Long Id) {// Obtener información de blog Blog Blog = BlogfeIgnClient.getById (id); // Obtener información de usuario userInfo userInfo = userFeignClient.getUserInfo (Blog.getuserId ()); // Obtener información de comentarios CommentInfo CommentInfo = commentfeignClient.getCommentInfo (id); Devolver ensamble toda la información y devolución. }Los datos se llaman remotamente, por supuesto, puede llamarlo en paralelo aquí. Otra forma es realizar la operación de agregación en la puerta de enlace API. Esta solución también es factible. Sugiero no hacerlo en la puerta de entrada. La puerta de enlace API es lo más simple posible y solo hacia adelante. Agregar la capa de servicio de agregación es una buena opción.
Si su gobierno de servicio está construido con Dubbo, la capa de servicio de agregación también es un mejor método. Dubbo Service Aggregation proporciona la interfaz HTTP a llamadas externas.
3. La persona que llama obtiene varios datos por sí mismo
Otra forma es llamar a la interfaz del blog, la interfaz de comentarios y la interfaz de usuario. De esta manera, la interfaz solo necesita prestar atención a sus propios datos y entregar el problema de ensamblaje al usuario. Esto generalmente se usa menos. Es mejor devolver los datos a la persona que llama a la vez y llamarlos repetidamente, especialmente en la terminal móvil, lo que requiere demasiadas solicitudes y tráfico de desechos.
Resumir
En cuanto a cómo ensamblar los datos, debe decidirlo usted mismo. Puede colocar el ensamblaje en los servicios comerciales correspondientes, o agregar un servicio de agregación para ensamblarlo por separado, o dejar que el cliente lo ensamble solo.
Los servicios definitivamente pueden llamarse entre sí. Si no pueden llamarse, ¿cuál es el punto de romperlos? Use Feign para llamar a la interfaz de servicio, y simplemente la tratará como una llamada entre los servicios.
De acuerdo, lo anterior es todo el contenido de este artículo. Espero que el contenido de este artículo tenga cierto valor de referencia para el estudio o el trabajo de todos. Si tiene alguna pregunta, puede dejar un mensaje para comunicarse. Gracias por su apoyo a Wulin.com.