转载

Netflix时代之后Spring云微服务的未来--DZone微服务

如果有人问你关于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 在 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博客上阅读有关它们的更多信息。

尽管Netflix云团队做出了这一决定，但Spring Cloud团队已经放弃了Zuul模块的开发。我只能猜测这是因为早先决定在Spring Cloud系列中启动了一个专门用于API网关的Spring Cloud Gateway新模块。

最后一块拼图是Eureka：这是一个发现服务器。它仍在开发中，但这里的情况也很有趣。我将在本文的下一部分中对此进行描述。

所有这些消息激励我看一下Spring Cloud的现状，并讨论未来可能发生的一些变化。作为Mastering Spring Cloud的一本书的作者，我试图跟随该项目的发展以保持最新状态。值得一提的是，我们的组织内部还有微服务 - 当然是使用Eureka，Zuul和Ribbon等模块构建在Spring Boot和Spring Cloud之上。在本文中，我想讨论一些流行的微服务模式，如服务发现，分布式配置，客户端负载平衡和API网关。

服务发现

Eureka是唯一尚未转移到维护模式的重要Spring Cloud Netflix模块。但是，我不会说它是积极开发的。Netflix维护的存储库中的最后一次提交是从1月11日开始的。前段时间，他们已经开始研究Eureka 2，但似乎这项工作已被放弃，或者他们只是推迟了最新版本的开源。

在这里您可以找到一个有趣的评论：“2.x分支目前被冻结，因为我们已经对eureka2进行了一些内部更改，并且没有任何时间来开源新的变更。”所以，我们有两种可能性。也许，Netflix将决定将这些内部更改作为Eureka服务器的第2版开源。值得记住的是，Eureka是Netflix直接大规模使用的经过实战验证的解决方案，也可能是许多其他组织通过Spring Cloud实现验证过的。

第二个选项是选择另一个发现服务器。目前，Spring Cloud支持基于各种工具的发现：ZooKeeper，Consul，Alibaba Nacos和Kubernetes。事实上，Kubernetes基于etcd。Spring Cloud也正在开发对etcd的支持，但它还处于孵化阶段，目前还不知道它是否会被推广到官方发布列车。在我看来，这些解决方案中有一个领导者--HashiCorp的Consul。

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一样。Consul对Eureka有一个无可置疑的优势 - 它由HashiCorp持续维护和开发。它的受欢迎程度快速增长。它是HashiCorp最大的生态系统的一部分，包括Vault，Nomad和Terraform。与Eureka相比，Consul不仅可以用于服务发现，还可以用作基于微服务的体系结构中的配置服务器。

分布式配置

Netflix Archaius是一个有趣的解决方案，用于管理微服务架构中的外部化配置。虽然它提供了一些有趣的功能，如动态和类型属性，或者支持动态数据源，如URL，JDBC或AWS DynamoDB，但Spring Cloud也决定将其转移到维护模式。然而，由于Pivotal团队和社区 - Spring Cloud Config完全创建的类似项目的存在，Spring Cloud Archaius的受欢迎程度有限。

Spring Cloud Config支持多个源存储库，包括Git，JDBC，Vault或简单文件。您可以在我之前的帖子中找到许多使用此项目为您的微服务提供分布式配置的示例。今天，我不打算谈论它。

正如我在上一节末尾提到的，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随机生成侦听端口号。如果需要设置应用程序的默认侦听端口，则应使用以下配置: key 是config/callme-service/server.port 值是0。

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文件。为此，我们应该在Consul的Key / Value的/config/gateway-service/data路径下创建一个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}

最后一步是强制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

客户端负载均衡器

在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;
 }

总结

下图说明了样本系统的架构：

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

Netflix时代之后Spring云微服务的未来--DZone微服务