Spring Cloud Edgware新特性之一:解决Eureka中Jersey 1.x版本过旧的问题-不使用Jersey

Spring Cloud是当前炙手可热的微服务开发框架。它的功能强大,组件丰富,设计优雅。目前Spring Cloud还在不断发展之中。

Spring Cloud即将发布Spring Cloud Edgware 版本。该版本解决了不少Bug,新增了不少新特性,本系列博客将为大家详细阐述在Spring Cloud Edgware中新增的特性。

为了让描述更加的贴合实际,本文将结合笔者所在团队遇到的实际情况进行讲解。

背景

Eureka服务器与客户端之间默认使用Jersey 1.x 进行基于HTTP协议的交互。然而我们团队,需使用docker-client (https://github.com/docker-java/docker-java) 。这货只支持Jersey 2.x ,而Jersey 1.x与2.x并不兼容。

寻求方案

于是,我们团队面临如下几种选择:

  • 使用Eureka提供的eureka-client-jersey2 模块,即使用Jersey 2.x 来代替Jersey 1.x https://github.com/Netflix/eureka/tree/master/eureka-client-jersey2 。然而,这种方式不够稳妥,原因是eureka-client-jersey2 是由社区提供,并非由Eureka官方团队维护,并且已经很久不更新了。
  • 放弃使用docker-client ,使用其他的Docker客户端,例如https://github.com/spotify/docker-client (该项目支持Jersey 1.x以及Jersey 2.x)。
  • 升级Spring Cloud Netflix 到1.4.x,即:Spring Cloud Edgware 【笔者认为的最佳方案】。

本文探讨的就是在Spring Cloud Edgware 中Eureka的点点滴滴。

废弃Eureka Client的Jersey

Spring Cloud Edgware 中,Jersey并非必选。可为Eureka Client禁用掉Jersey,转而使用我们想要的HTTP客户端,例如RestTemplate。只需将Jersey的包从依赖中删除,Spring Cloud就会自动配置一个基于Spring RestTemplate 的传输客户端。操作如下:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka</artifactId>
    <exclusions>
        <exclusion>
            <groupId>com.sun.jersey</groupId>
            <artifactId>jersey-client</artifactId>
        </exclusion>
        <exclusion>
            <groupId>com.sun.jersey</groupId>
            <artifactId>jersey-core</artifactId>
        </exclusion>
        <exclusion>
            <groupId>com.sun.jersey.contribs</groupId>
            <artifactId>jersey-apache-client4</artifactId>
        </exclusion>
    </exclusions>
</dependency>

收益

简单的操作后,有两个好处:

  • 再也不用烦Jersery的版本冲突问题
  • 依赖减少了一些。

原理及代码

详见:https://github.com/spring-cloud/spring-cloud-netflix/issues/1849 。简单来说,就是Eureka提供了一个抽象,允许用户为Eureka Client定制自己的HTTP客户端,而不像老版本,强制使用Jersery。

本文链接: http://www.itmuch.com/spring-cloud/edgware-new-eureka-jersey1/
**版权声明: **本博客由周立创作,采用 CC BY 3.0 CN 许可协议。可*转载、引用,但需署名作者且注明文章出处。如转载至微信公众号,请在文末添加作者公众号二维码。

上一篇:MySQL InnoDB Lock Modes


下一篇:疑难杂症——EF+Automapper引发的查询效率问题解析