Netflix时代之后Spring Cloud微服务的未来

来源：SpringForAll社区

如果有人会问你有关Spring Cloud的问题，那么你想到的第一件事可能就是Netflix OSS的支持。对Eureka，Zuul或Ribbon等工具的支持不仅由Spring提供，还由用于构建Apache Camel，Vert.x或Micronaut等微服务架构的其他流行框架提供。目前，Spring Cloud Netflix是Spring Cloud中最受欢迎的项目。它在GitHub上有大约3.2k的星星，而第二个最好的大约有1.4k。因此，Pivotal宣布大部分Spring Cloud Netflix模块正在进入维护模式，这是非常令人惊讶的。您可以通过Spencer Gibb https://spring.io/blog/2018/12/12/spring-cloud-greenwich-rc1-available-now 在Spring博客上发布的帖子中了解更多信息。好的，让我们对这些变化进行简短的总结。从Spring Cloud Greenwich发布开始Netflix OSS Archaius，Hystrix，Ribbon和Zuul正在进入维护模式。这意味着这些模块不会有任何新功能，Spring Cloud团队只会执行一些错误修复并修复安全问题。维护模式不包括仍支持的Eureka模块。对这些变化的解释非常简单。特别是其中两个。目前，Netflix并未积极开发Ribbon和Hystrix，尽管它们仍在大规模部署。此外，Hystrix已经被称为Atlas的遥测新解决方案所取代。Zuul的情况并不那么明显。Netflix已宣布于2018年5月开放Zuul 2。新版Zuul网关建立在Netty服务器之上，包括一些改进和新功能。您可以在Netflix博客https://medium.com/netflix-techblog/open-sourcing-zuul-2-82ea476cb2b3 上阅读更多相关信息。。尽管Netflix云团队做出了这一决定，但Spring Cloud团队已经放弃了Zuul模块的开发。我只能猜测它是由于早先决定在Spring Cloud系列中启动新模块而特别是因为它是基于微服务的架构中的API网关 - Spring Cloud Gateway。最后一块拼图是Eureka--一个发现服务器。它仍在发展，但这里的情况也很有趣。我将在本文的下一部分中对此进行描述。所有这些新闻激励我看一下Spring Cloud的现状，并讨论未来的一些潜在变化。作为掌握Spring Cloud的一本书的作者，我试图跟随该项目的演变以保持最新状态。还值得一提的是，我们的组织内部有微服务 - 当然是在Spring Boot和Spring Cloud之上构建的，使用Eureka，Zuul和Ribbon等模块。在本文中，我想讨论一些潜在的......对于诸如服务发现，分布式配置，客户端负载平衡和API网关等流行的微服务模式。

1.服务发现

Eureka是唯一一个尚未转移到维护模式的重要Spring Cloud Netflix模块。但是，我不会说它是积极开发的。Netflix维护的存储库中的最后一次提交是从1月11日开始的。前段时间他们已经开始研究Eureka 2，但看起来这些作品已被放弃，或者他们只是推迟了将未来的最新版本代码开源。在这里https://github.com/Netflix/eureka/tree/2.x 你可以找到一个有趣的评论：“2.x分支目前被冻结，因为我们已经对eureka2进行了一些内部更改，并且没有任何时间线来开源新的变更。” 所以，我们有两种可能性。也许，Netflix将决定将这些内部更改作为Eureka服务器的第2版开源。值得记住的是，Eureka是一个经过战争验证的解决方案，直接用于Scale by Netflix，可能还有许多其他组织通过Spring Cloud。第二个选项是选择另一个发现服务器。目前，Spring Cloud支持基于各种工具的发现：ZooKeeper，Consul，Alibaba Nacos，Kubernetes。事实上，Kubernetes基于etcd。Spring Cloud也正在开发对etcd的支持，但它还处于孵化阶段，目前还不知道它是否会被推广到官方发布中。在我看来，这些解决方案中有一位领导者--HashiCorp的领事。

Consul现在被描述为服务网格解决方案，提供具有服务发现，配置和分段功能的全功能控制平面。它可以用作基于微服务的体系结构中的发现服务器或键/值存储。与Consul的集成由Spring Cloud Consul项目实现。要为您的应用程序启用Consul客户端，您只需要在Maven中包含以下依赖项pom.xml：

<dependency>  <groupId>org.springframework.cloud</groupId>  <artifactId>spring-cloud-starter-consul-discovery</artifactId></dependency>

默认情况下，Spring尝试在地址localhost：8500上与Consul连接。如果您需要覆盖此地址，则应在其中设置适当的属性application.yml：

spring:    cloud:    consul:      host: 192.168.99.100      port: 8500

您可以使用作为Docker容器启动的Consul的本地实例轻松测试此解决方案：

$ docker run -d --name consul -p 8500:8500 consul

如您所见，使用Spring Cloud进行Consul发现实现非常简单 - 与Eureka相同。领事对Eureka有一个无可置疑的优势 - 它由HashiCorp持续维护和开发。它的受欢迎程度快速增长。它是HashiCorp最大的生态系统的一部分，包括Vault，Nomad和Terraform。与Eureka相比，Consul不仅可以用于服务发现，还可以用作基于微服务的体系结构中的配置服务器。

2.分布式配置

Netflix Archaius是一个有趣的解决方案，用于管理微服务架构中的外部化配置。虽然它提供了一些有趣的功能，如动态和类型属性，或者支持动态数据源，如URL，JDBC或AWS DynamoDB，但Spring Cloud也决定将其转移到维护模式。然而，由于Pivotal团队和社区 - Spring Cloud Config完全创建的类似项目的存在，Spring Cloud Archaius的受欢迎程度有限。Spring Cloud Config支持多个源存储库，包括Git，JDBC，Vault或简单文件。您可以在我之前的帖子中找到许多使用此项目为您的微服务提供分布式配置的示例。今天，我不打算谈论它。我们将讨论另一种解决方案 - 也得到Spring Cloud的支持。正如我在上一节末尾提到的，Consul也可以用作配置服务器。如果您使用Eureka作为发现服务器，使用Spring Cloud Config作为配置服务器是很自然的选择，因为Eureka根本不提供此类功能。如果您决定使用Consul，情况就不是这样。现在选择两种解决方案是有意义的：Spring Cloud Consul Config和Spring Cloud Config。当然，它们都有其优点和缺点。例如，您可以使用Consul节点轻松构建集群，而使用Spring Cloud Config则必须依赖外部发现。现在，让我们看看如何使用Spring Cloud Consul来管理应用程序中的外部配置。要在应用程序端启用它，您只需要在Maven中包含以下依赖项pom.xml：

<dependency>  <groupId>org.springframework.cloud</groupId>  <artifactId>spring-cloud-starter-consul-config</artifactId></dependency>

与服务发现相同，如果要覆盖某些默认客户端设置，则需要设置属性spring.cloud.consul.*。但是，必须在内部提供这样的配置bootstrap.yml。

spring:    application:    name: callme-service  cloud:    consul:      host: 192.168.99.100      port: 8500

在Consul上创建的属性源名称应与bootstrap.yml内部config文件夹中提供的应用程序名称相同。您应该server.port使用值创建密钥0，以强制Spring Boot随机生成侦听端口号。假设您需要设置应用程序默认侦听端口，您应该进行以下配置。

启用动态端口号生成时，还需要覆盖应用程序实例ID，使其在单个计算机上保持唯一。如果在同一台计算机上运行单个服务的多个实例，则需要使用这些功能。我们将这样做callme-service，因此我们需要spring.cloud.consul.discovery.instance-id使用我们的值覆盖属性，如下所示。

然后，您应该在应用程序启动时看到以下日志.

3.API网关

Spring Cloud Netflix Zuul的继任者是Spring Cloud Gateway。这个项目大约在两年前开始，现在是第二个最受欢迎的Spring Cloud项目，在GitHub上有1.4k星。它提供了一个建立在Spring Ecosystem之上的API网关，包括：Spring 5，Spring Boot 2和Project Reactor。它在Netty上运行，不能与Tomcat或Jetty等传统的servlet容器一起使用。它允许定义路由，谓词和过滤器。API网关与每个Spring Cloud微服务相同，可以轻松地与基于Consul的服务发现集成。我们只需要在里面包含适当的依赖项pom.xml。我们将使用Spring Cloud库的最新开发版本 - 2.2.0.BUILD-SNAPSHOT。这是所需依赖项的列表:

<dependency>    <groupId>org.springframework.cloud</groupId>    <artifactId>spring-cloud-starter-consul-discovery</artifactId>    <version>2.2.0.BUILD-SNAPSHOT</version></dependency><dependency>    <groupId>org.springframework.cloud</groupId>    <artifactId>spring-cloud-starter-consul-config</artifactId>    <version>2.2.0.BUILD-SNAPSHOT</version></dependency><dependency>    <groupId>org.springframework.cloud</groupId>    <artifactId>spring-cloud-starter-gateway</artifactId>    <version>2.2.0.BUILD-SNAPSHOT</version></dependency>

Consul还将提供网关配置。因为我们有比模拟微服务更多的配置设置，我们将它存储为YAML文件。为了实现这一点，我们应该/config/gateway-service/data在Consul Key / Value上的路径下创建可用的YAML文件。下面显示的配置启用服务发现集成并定义到下游服务的路由。每条路由都包含在服务发现中注册的目标服务的名称，用于下游服务公开的呼叫端点的匹配路径和重写路径。以下配置由我们的API网关在启动时加载：

spring:  cloud:    gateway:      discovery:        locator:          enabled: true      routes:        - id: caller-service          uri: lb://caller-service          predicates:            - Path=/caller/**          filters:            - RewritePath=/caller/(?.*), /${path}        - id: callme-service          uri: lb://callme-service          predicates:            - Path=/callme/**          filters:            - RewritePath=/callme/(?.*), /${path}

这是Consul上可见的相同配置。

最后一步是强制gateway-service读取存储为YAML的配置。为此，我们需要将属性设置spring.cloud.consul.config.format为YAML。这是里面提供的完整配置bootstrap.yml。

spring:  application:    name: gateway-service  cloud:    consul:      host: 192.168.99.100      config:        format: YAML

4.客户端负载均衡器

在2.2.0.BUILD-SNAPSHOTSpring Cloud Commons 版本中，Ribbon仍然是HTTP客户端的主要自动配置负载均衡器。虽然Spring Cloud团队已宣布Spring Cloud Load Balancer将成为Ribbon的继承者，但我们目前在文档和网络上找不到关于该项目的许多信息。我们可能期望与Netflix Ribbon相同的任何配置对我们来说都是透明的，特别是如果我们使用发现客户端。目前，spring-cloud-loadbalancer模块是Spring Cloud Commons项目的一部分。您可以通过声明以下依赖项将其直接包含在您的应用程序中pom.xml：

<dependency>    <groupId>org.springframework.cloud</groupId>    <artifactId>spring-cloud-loadbalancer</artifactId>    <version>2.2.0.BUILD-SNAPSHOT</version></dependency>

出于测试目的，排除与spring-cloud-starter-consul-discovery 启动器一起包含的一些Netflix模块是值得的。现在，我们确信Ribbon不在后台用作负载均衡器。这是我为示例应用程序设置的排除列表：

<dependency>    <groupId>org.springframework.cloud</groupId>    <artifactId>spring-cloud-starter-consul-discovery</artifactId>    <version>2.2.0.BUILD-SNAPSHOT</version>    <exclusions>        <exclusion>            <groupId>org.springframework.cloud</groupId>            <artifactId>spring-cloud-netflix-core</artifactId>        </exclusion>        <exclusion>            <groupId>org.springframework.cloud</groupId>            <artifactId>spring-cloud-starter-netflix-archaius</artifactId>        </exclusion>        <exclusion>            <groupId>com.netflix.ribbon</groupId>            <artifactId>ribbon</artifactId>        </exclusion>        <exclusion>            <groupId>com.netflix.ribbon</groupId>            <artifactId>ribbon-core</artifactId>        </exclusion>        <exclusion>            <groupId>com.netflix.ribbon</groupId>            <artifactId>ribbon-httpclient</artifactId>        </exclusion>        <exclusion>            <groupId>com.netflix.ribbon</groupId>            <artifactId>ribbon-loadbalancer</artifactId>        </exclusion>    </exclusions></dependency>

把我的榜样当成一个操场。当然，有针对性的方法会更容易。首先，我们应该用我们的main或配置类注释@LoadBalancerClient。与往常一样，客户端的名称应与在注册表中注册的目标服务的名称相同。注释还应包含具有客户端配置的类

@SpringBootApplication@LoadBalancerClients({    @LoadBalancerClient(name = "callme-service", configuration = ClientConfiguration.class)})public class CallerApplication {    public static void main(String[] args) {        SpringApplication.run(CallerApplication.class, args);    }    @Bean    RestTemplate template() {        return new RestTemplate();    }}

这是我们的负载均衡器配置类。它包含单个声明@Bean。我选择了RoundRobinLoadBalancer类型。

public class ClientConfiguration {
    @Bean    public RoundRobinLoadBalancer roundRobinContextLoadBalancer(LoadBalancerClientFactory clientFactory, Environment env) {        String serviceId = clientFactory.getName(env);        return new RoundRobinLoadBalancer(serviceId, clientFactory                .getLazyProvider(serviceId, ServiceInstanceSupplier.class), -1);    }
}

最后，这是caller-service控制器的实现。它LoadBalancerClientFactory直接用于查找可用实例的列表callme-service。然后，它选择单个实例，获取其主机和端口，并将其设置为目标URL。

@RestController@RequestMapping("/caller")public class CallerController {
    @Autowired    Environment environment;    @Autowired    RestTemplate template;    @Autowired    LoadBalancerClientFactory clientFactory;
    @GetMapping    public String call() {        RoundRobinLoadBalancer lb = clientFactory.getInstance("callme-service", RoundRobinLoadBalancer.class);        ServiceInstance instance = lb.choose().block().getServer();        String url = "http://" + instance.getHost() + ":" + instance.getPort() + "/callme";        String callmeResponse = template.getForObject(url, String.class);        return "I'm Caller running on port " + environment.getProperty("local.server.port")                + " calling-> " + callmeResponse;    }
}

5.摘要

下图说明了样本系统的体系结构。我们有两个实例callme-service，一个实例caller-service，它使用Spring Cloud Balancer查找可用实例列表callme-service。端口是动态生成的。API网关从外部客户端隐藏了我们系统的复杂性。它在端口8080上可用，并根据请求上下文路径将请求转发到下游。

启动后，您应该在Consul节点上注册所有微服务。

现在，您可以尝试caller-service通过网关公开的端点 ：http：// localhost：8080 / caller。你应该这样：

示例应用程序源代码可在存储库https://github.com/piomin/sample-spring-cloud-microservices-future.git中的 GitHub上获得。

原文链接：https://piotrminkowski.wordpress.com/2019/04/05/the-future-of-spring-cloud-microservices-after-netflix-era/ 作者：PiotrMińkowski 译者：Yunooa