Spring Cloud在Netflix后时代的走向？

如果有人问你关于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，但似乎这项工作已被放弃，或者他们只是推迟了最新版本的开源。

第二个选项是选择另一个发现服务器。目前，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>

您可以使用作为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的受欢迎程度有限。

如果您使用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上可用，并根据请求上下文路径将请求转发到下游。

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

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

读者福利：

分享免费学习资料

针对于Java程序员，我这边准备免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）

为什么某些人会一直比你优秀，是因为他本身就很优秀还一直在持续努力变得更优秀，而你是不是还在满足于现状内心在窃喜！希望读到这的您能点个小赞和关注下我，以后还会更新技术干货，谢谢您的支持！

资料领取方式：加入Java技术交流群 963944895 ，私信管理员即可免费领取