La publicación de blog anterior construyó un marco Eureka+Ribbon+Hystrix. Aunque básicamente puede cumplir con llamadas entre servicios, el código se ve realmente feo. El cliente tiene que escribir una placa de restauración cada vez. Para hacer que las llamadas sean más hermosas y legibles, ahora estamos aprendiendo a usar Feign.
Feign incluye Ribbon e Hystrix, que gradualmente experimenta su importancia en el combate real. La llamada inclusión no es la inclusión física de los paquetes JAR de Feign, incluidos los paquetes JAR de cinta y Hystrix, sino la inclusión lógica de las funciones de Feign, incluidas las funciones de los otros dos. En resumen: Feign puede hacer cosas sobre la cinta y el hystrix, pero para usar las anotaciones traídas por la cinta y el hystrix, se debe introducir el paquete JAR correspondiente.
Caso 1:
Centro de registro de Eureka: https://github.com/yejingtao/forblog/tree/master/demo-eureka-register
Proveedor de servicios: https://github.com/yejingtao/forblog/tree/master/demo-feign-freeservice
Caller de servicio: https://github.com/yejingtao/forblog/tree/master/demo-freign-freeconsumer
El proveedor de servicios es una aplicación simple de eurekaclient+, que proporciona los siguientes métodos
@RestController @RequestMapping ("/Feign-Service") Public Class HelloserviceConTorller {private logger logger = loggerFactory.getLogger (this.getClass ()); privado vacío sleep (string metodName) {int sleepMintime = new Random (). NextInt (3000); logger.info ("HelloService"+MethodName+"SleepMintime:"+SleepMintime); intente {Thread.sleep (SleepMintime); } catch (InterruptedException e) {E.PrintStackTrace (); }} @RequestMapping (valor = "/servicio de servicio", método = requestmethod.get) public string helloservice (@RequestParam String Name) {sleep ("get"); return "helloserviceImpl name:"+nombre; } @RequestMapping (value = "/ServiceHead", método = requestmethod.head) public String HELLOSERVICE (@RequestHeader String Name, @RequestHeader String Password) {Sleep ("Header"); Return "Helloservicehead Nombre:"+nombre+"Contraseña:"+contraseña; } @RequestMapping (value = "/ServicePost", Method = requestmethod.post) public String HELLOSERVICE (@RequestBody UserDemo UserDemo) {Sleep ("Post"); return userDemo.ToString (); }} No se pueden omitir las siguientes anotaciones a las que se deben prestar atención.
@RequestParam: anotación que indica que el parámetro del método debe estar vinculado a un parámetro de solicitud web
@RequestBody: la anotación que indica un método de parámetro debe estar unido al cuerpo de la solicitud web.
@RequestHeader: anotación que indica que el parámetro del método debe estar vinculado a un encabezado de solicitud web.
Si faltan las anotaciones anteriores, aunque el servicio no informará un error después de que se ejecute, no puede obtener los parámetros de entrada.
Proyecto de servicio de servicio:
<Spendency> <MoupRupid> org.springframework.cloud </groupid> <artifactID> spring-ncloud-starter-feign </artifactid> </pepertency>
Feign solo depende aquí, no en cinta e hystrix.
aplicación.yml:
Servidor: Puerto: 9051 Spring: Aplicación: Nombre: Demo-Feign-FreeConsumer eureka: Client: ServiceUrl: Defaultzone: http: // peer1: 1111/eureka/, http: // peer2: 1112/eureka/feign: hytrix: habilitado: verdadero #Ribbon Timeout setting # cibbon: # Connect Timeout: 500 # # # 3000 # 3000 # 3000 # 3000 # 3000
La configuración de Hystrix me ha engañado durante mucho tiempo. La nube de primavera que utilicé es la versión SR1 de Dalston, que es más nueva que las versiones de otros materiales en Internet. Porque en la nueva versión, el soporte de Feign para Hystrix se desactiva de forma predeterminada, por lo que debe activar manualmente Feign.hystrix.enabled = True a través de la configuración, de modo que la rebaja del servicio y otras funciones sean efectivas.
Programa de arranque de aplicaciones
@SpringBootApplication @enableeurekaclient @enablefeignClients public class demOfeignApplication {public static void main (string [] args) {springapplication.run (demOfeignapplication.class, args); }} Tenga en cuenta que hay otra trampa aquí. Estoy usando @SpringBootApplication+ @EnseureeureKaclient en lugar de @SpringCloudApplication, porque este último contiene @enablecircuitbreaker, y @enablecircuitbreaker es el contenido en el paquete Hystrix. Mi POM no introduce Hystrix. Entonces Spring Cloud todavía tiene deficiencias a este respecto. No informará un error compilando directamente con @SpringCloudApplication, pero no se puede iniciar. Por supuesto, el protagonista aquí sigue siendo la anotación @enablefeignclients.
Código de cliente central
@FeignClient (name = "Demo-Feign-FreeService", fallback = demOfeignfallback.class) interfaz pública demOfeignService {@RequestMapping (value = "/Feign-Service/ServiceGet", método = requestMethod.get) String HELLSERVICE (@RequestParam ("Nombre") de cadena); @RequestMapping (value = "/Feign-Service/Servicehead", método = requestmethod.head) string helloService (@RequestHeader ("Nombre") Nombre de cadena, @RequestHeader ("Password") String Password); @RequestMapping (value = "/Feign-Service/ServicePost", método = requestmethod.post) string helloService (@RequestBody UserDemo UserDemo); } La anotación @feignclient define que la interfaz es un cliente fingente, el nombre especifica el nombre del servicio registrado en Eureka, y Fallback es la clase de implementación de la interfaz después de que el servicio se degrada.
@RequestMapping Especifica los métodos de solicitud de URL relativa y HTTP de la solicitud, que corresponde al servidor uno por uno. @RequestParam,
@RequestBody y las anotaciones @RequestHeader tienen más atributos de valor que los servidores. No se pueden omitir aquí. Deben informar explícitamente al cliente Feign cómo corresponder a los parámetros.
Código de servicio de rebaja:
@Component public class DemoFeignFallBack implementa DemOfeignService {@Override public String HELLOSERVICE (Nombre de cadena) {return "Get Error"; } @Override public String HELLOSERVICE (nombre de cadena, contraseña de cadena) {return "Error de cabeza"; } @Override public String HelloService (UserDemo UserDemo) {return "Post Error"; }} Descubrí que eliminé deliberadamente las anotaciones de @RequestParam, @RequestBody y @RequestHeader en los parámetros de entrada aquí, porque la importancia esencial de estas anotaciones es que Feign usa los parámetros a HTTP al hacer llamadas de microservicio, sino que la rebenado del servicio no hará que las solicitudes HTTP se puedan omitir aquí.
Código del controlador:
@RestController Public Class DemofeignController {@AUTOWIREDIRDIREDREDIRED DemoFeignService DemoFeignService; @RequestMapping (valor = "/test", método = requestmethod.get) public String DemoserviceTest () {StringBuffer sb = new StringBuffer (); sb.append (demofeignservice.helloService ("yuanyuan")); sb.append ("/n"); sb.append (demofeignservice.helloService ("yjt", "xixihaha")); sb.append ("/n"); sb.append (demOfeignService.helloService (New UserDemo ("Yejingtao", "123456"))); return sb.ToString (); }}Veamos el efecto:
Nuestro servicio no hizo tiempo, los tres métodos eran normales, pero la solicitud de la cabeza no obtuvo el valor de retorno. Esto está determinado por las características de la solicitud HTTP del método principal. La cabeza no devuelve el cuerpo del cuerpo de la respuesta, y generalmente se usa para las pruebas de conectividad.
Veamos otro set:
Los métodos de solicitud de cabeza y posterior se han procesado durante más de 2000 ms, y el servicio está degradado, y la implementación es reemplazada por la clase de procesamiento de retroceso.
En el caso de uno, siempre tenemos la sensación de que existe un código duplicado entre el proveedor de servicios y la persona que llama. ¿Se puede optimizar? Consulte el caso 2.
Caso 2:
Centro de registro de Eureka: https://github.com/yejingtao/forblog/tree/master/demo-eureka-register
API de interfaz: https://github.com/yeJingtao/forblog/tree/master/demo-feign-serviceapi
Proveedor de servicios: https://github.com/yejingtao/forblog/tree/master/demo-feign-serviceImpl
Caller de servicio: https://github.com/yejingtao/forblog/tree/master/demo-feign-apicconsumer
El mayor cambio en el caso 2 es escribir capacidades de servicio por separado en un proyecto API, y tanto la persona que llama como el proveedor POM confían en esta API.
API:
Interfaz pública HELLOSERVICE {@RequestMapping (valor = "/Feign-Service/ServiceGet", método = requestmethod.get) string helloservice (@RequestParam ("Nombre") Nombre de cadena); @RequestMapping (value = "/Feign-Service/Servicehead", método = requestmethod.head) string helloService (@RequestHeader ("Nombre") Nombre de cadena, @RequestHeader ("Password") String Password); @RequestMapping (value = "/Feign-Service/ServicePost", método = requestmethod.post) string helloService (@RequestBody UserDemo UserDemo); } Proveedor de servicios:
@RestController Class public HelloserviceConTorller implementa HELOSERVICE {private logger logger = loggerFactory.getLogger (this.getClass ()); privado vacío sleep (string metodName) {int sleepMintime = new Random (). NextInt (3000); logger.info ("HelloService"+MethodName+"SleepMintime:"+SleepMintime); intente {Thread.sleep (SleepMintime); } catch (InterruptedException e) {E.PrintStackTrace (); }} @Override public String HelloService (@RequestParam ("Nombre") Nombre de cadena) {Sleep ("Get"); return "helloserviceImpl name:"+nombre; } @Override public String HelloService (@RequestHeader ("Nombre") Nombre de cadena, @RequestHeader ("Password") String Password) {Sleep ("Header"); Return "Helloservicehead Nombre:"+nombre+"Contraseña:"+contraseña; } @Override public String HelloService (@RequestBody UserDemo UserDemo) {Sleep ("Post"); return userDemo.ToString (); }} Callador de servicio:
@FeignClient (name = "Demo-Feign-ServiceImpl", Fallback = FeignServiceFallBack.Class) Interfaz Public FeignService extiende HelloService {}Otros códigos permanecen básicamente sin cambios, y el efecto es el mismo.
Los dos estilos tienen sus propias ventajas y desventajas: Freestyle es más gratuito, y el nuevo método agregado al servidor no afectará el código del cliente. La desventaja es que las capacidades de servicio no están sincronizadas y los cambios en las capacidades de servicio causarán anormalidades; Las capacidades de servicio del cliente del servidor API de formato se sincronizan, pero los cambios en la interfaz requieren modificación del código en ambos lados, y debe considerarlo claramente al construirlos.
Lo anterior es todo el contenido de este artículo. Espero que sea útil para el aprendizaje de todos y espero que todos apoyen más a Wulin.com.