Spring Cloud Consul综合整理

部分资料来自

该项目经过自动配置和Spring环境以及其余Spring编程模型习惯用法提供了Spring Boot应用程序的Consul集成。 经过一些简单的注释，您能够快速启用和配置应用程序内的通用模式，并使用基于Consul的组件构建大型分布式系统。 提供的模式包括服务发现，控制总线和配置。 智能路由（Zuul）和客户端负载平衡（功能区），断路器（Hystrix）经过与Spring Cloud Netflix集成提供。

在上个月咱们知道 Eureka 2.X 遇到困难中止开发了，但其实对国内的用户影响甚小，一方面国内大都使用的是 Eureka 1.X 系列，另外一方面 Spring Cloud 支持不少服务发现的软件，Eureka 只是其中之一，下面是 Spring Cloud 支持的服务发现软件以及特性对比： Feature euerka Consul zookeeper etcd 服务健康检查 可配支持 服务状态，内存，硬盘等 (弱)长链接，keepalive 链接心跳 多数据中心 — 支持 — — kv 存储服务 — 支持 支持 支持 一致性 — raft paxos raft cap ap ca cp cp 使用接口(多语言能力) http（sidecar） 支持 http 和 dns 客户端 http/grpc watch 支持 支持 long polling/大部分增量 全量/支持long polling 支持 支持 long polling 自身监控 metrics metrics — metrics 安全 — acl /https acl https 支持（弱） spring cloud 集成 已支持 已支持 已支持 已支持 Consul 介绍

Consul 是 HashiCorp 公司推出的开源工具，用于实现分布式系统的服务发现与配置。与其它分布式服务注册与发现的方案，Consul 的方案更“一站式”，内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案，再也不须要依赖其它工具（好比 ZooKeeper 等）。使用起来也较为简单。Consul 使用 Go 语言编写，所以具备自然可移植性(支持Linux、windows和Mac OS X)；安装包仅包含一个可执行文件，方便部署，与 Docker 等轻量级容器可无缝配合。

Consul 的优点：

使用 Raft 算法来保证一致性, 比复杂的 Paxos 算法更直接. 相比较而言, zookeeper 采用的是 Paxos, 而 etcd 使用的则是 Raft。 支持多数据中心，内外网的服务采用不一样的端口进行监听。 多数据中心集群能够避免单数据中心的单点故障,而其部署则须要考虑网络延迟, 分片等状况等。 zookeeper 和 etcd 均不提供多数据中心功能的支持。 支持健康检查。 etcd 不提供此功能。 支持 http 和 dns 协议接口。 zookeeper 的集成较为复杂, etcd 只支持 http 协议。 官方提供 web 管理界面, etcd 无此功能。 综合比较, Consul 做为服务注册和配置管理的新星, 比较值得关注和研究。

特性：

服务发现 健康检查 Key/Value 存储 多数据中心

Consul 角色

client: 客户端, 无状态, 将 HTTP 和 DNS 接口请求转发给局域网内的服务端集群。 server: 服务端, 保存配置信息, 高可用集群, 在局域网内与本地客户端通信, 经过广域网与其它数据中心通信。 每一个数据中心的 server 数量推荐为 3 个或是 5 个。

Consul 客户端、服务端还支持夸中心的使用，更加提升了它的高可用性。

Consul 工做原理：

一、当 Producer 启动的时候，会向 Consul 发送一个 post 请求，告诉 Consul 本身的 IP 和 Port 二、Consul 接收到 Producer 的注册后，每隔10s（默认）会向 Producer 发送一个健康检查的请求，检验Producer是否健康 三、当 Consumer 发送 GET 方式请求 /api/address 到 Producer 时，会先从 Consul 中拿到一个存储服务 IP 和 Port 的临时表，从表中拿到 Producer 的 IP 和 Port 后再发送 GET 方式请求 /api/address 四、该临时表每隔10s会更新，只包含有经过了健康检查的 Producer

Spring Cloud Consul 项目是针对 Consul 的服务治理实现。Consul 是一个分布式高可用的系统，它包含多个组件，可是做为一个总体，在微服务架构中为咱们的基础设施提供服务发现和服务配置的工具。 Consul VS Eureka

Eureka 是一个服务发现工具。该体系结构主要是客户端/服务器，每一个数据中心有一组 Eureka 服务器，一般每一个可用区域一个。一般 Eureka 的客户使用嵌入式 SDK 来注册和发现服务。对于非本地集成的客户，官方提供的 Eureka 一些 REST 操做 API，其它语言可使用这些 API 来实现对 Eureka Server 的操做从而实现一个非 jvm 语言的 Eureka Client。

Eureka 提供了一个弱一致的服务视图，尽量的提供服务可用性。当客户端向服务器注册时，该服务器将尝试复制到其它服务器，但不提供保证复制完成。服务注册的生存时间（TTL）较短，要求客户端对服务器心跳检测。不健康的服务或节点中止心跳，致使它们超时并从注册表中删除。服务发现能够路由到注册的任何服务，因为心跳检测机制有时间间隔，可能会致使部分服务不可用。这个简化的模型容许简单的群集管理和高可扩展性。

Consul 提供了一些列特性，包括更丰富的健康检查，键值对存储以及多数据中心。Consul 须要每一个数据中心都有一套服务，以及每一个客户端的 agent，相似于使用像 Ribbon 这样的服务。Consul agent 容许大多数应用程序成为 Consul 不知情者，经过配置文件执行服务注册并经过 DNS 或负载平衡器 sidecars 发现。

Consul 提供强大的一致性保证，由于服务器使用 Raft 协议复制状态 。Consul 支持丰富的健康检查，包括 TCP，HTTP，Nagios / Sensu 兼容脚本或基于 Eureka 的 TTL。客户端节点参与基于 Gossip 协议的健康检查，该检查分发健康检查工做，而不像集中式心跳检测那样成为可扩展性挑战。发现请求被路由到选举出来的 leader，这使他们默认状况下强一致性。容许客户端过期读取取使任何服务器处理他们的请求，从而实现像 Eureka 这样的线性可伸缩性。

Consul 强烈的一致性意味着它能够做为领导选举和集群协调的锁定服务。Eureka 不提供相似的保证，而且一般须要为须要执行协调或具备更强一致性需求的服务运行 ZooKeeper。

Consul 提供了支持面向服务的体系结构所需的一系列功能。这包括服务发现，还包括丰富的运行情况检查，锁定，密钥/值，多数据中心联合，事件系统和 ACL。Consul 和 consul-template 和 envconsul 等工具生态系统都试图尽可能减小集成所需的应用程序更改，以免须要经过 SDK 进行本地集成。Eureka 是一个更大的 Netflix OSS 套件的一部分，该套件预计应用程序相对均匀且紧密集成。所以 Eureka 只解决了一小部分问题，能够和 ZooKeeper 等其它工具能够一块儿使用。

Consul 强一致性(C)带来的是：

服务注册相比 Eureka 会稍慢一些。由于 Consul 的 raft 协议要求必须过半数的节点都写入成功才认为注册成功 Leader 挂掉时，从新选举期间整个 Consul 不可用。保证了强一致性但牺牲了可用性。

Eureka 保证高可用(A)和最终一致性：

服务注册相对要快，由于不须要等注册信息 replicate 到其它节点，也不保证注册信息是否 replicate 成功 当数据出现不一致时，虽然 A, B 上的注册信息不彻底相同，但每一个 Eureka 节点依然可以正常对外提供服务，这会出现查询服务信息时若是请求 A 查不到，但请求 B 就能查到。如此保证了可用性但牺牲了一致性。

其它方面，eureka 就是个 servlet 程序，跑在 servlet 容器中; Consul 则是 go 编写而成。 安装Consul

安装文档 Consul代理

全部Spring Cloud Consul应用程序都必须使用Consul Agent客户端。 默认状况下，代理客户端应位于localhost:8500。 有关如何启动代理客户端以及如何链接到Consul Agent Server群集的详细信息，请参阅代理文档。 对于开发，在安装了consul以后，您可使用如下命令启动Consul Agent：

Linux

./src/main/bash/local_run_consul.sh

这将在端口8500上以服务器模式启动代理，其中浏览器可访问http://localhost:8500

window下安装

Consul 不一样于 Eureka 须要单独安装，访问Consul 官网下载 Consul 的最新版本，我这里是 consul_1.2.1。

根据不一样的系统类型选择不一样的安装包，从下图也能够看出 Consul 支持全部主流系统。

我这里以 Windows 为例，下载下来是一个 consul_1.2.1_windows_amd64.zip 的压缩包，解压是是一个 consul.exe 的执行文件。

cd 到对应的目录下，使用 cmd 启动 Consul

cd E:\soft\consul_1.2.1_windows_amd64 #cmd启动： consul agent -dev # -dev表示开发模式运行，另外还有-server表示服务模式运行

为了方便期间，能够在同级目录下建立一个 run.bat 脚原本启动，脚本内容以下：

consul agent -dev pause

启动结果以下：

启动成功以后访问：http://localhost:8500，能够看到 Consul 的管理界面

这样就意味着咱们的 Consul 服务启动成功了。 1.Consul服务发现

服务发现是基于微服务体系结构的关键原则之一。 尝试手动配置每一个客户端或某种形式的约定可能很是困难，而且可能很是脆弱。 Consul经过HTTP API和DNS提供服务发现服务。 Spring Cloud Consul利用HTTP API进行服务注册和发现。 这并不妨碍非Spring Cloud应用程序利用DNS接口。 Consul 代理服务器在群集中运行，该群集经过八卦协议进行通讯并使用Raft共识协议。 1.1如何添加consul

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

1.2注册consul

当客户向Consul注册时，它会提供有关自身的元数据，例如主机和端口，ID，名称和标签。 默认状况下会建立HTTP检查，Consul每10秒命中一次/ health端点。 若是运行情况检查失败，则将服务实例标记为严重。

Consul客户端

@SpringBootApplication @RestController public class Application {

@RequestMapping("/")
    public String home() {
        return "Hello world";
    }
 
    public static void main(String[] args) {
        new SpringApplicationBuilder(Application.class).web(true).run(args);
    }
 
}

（以上是一个普通的Spring Boot应用程序）。 若是Consul客户端位于localhost:8500之外的其余位置，则须要配置以查找客户端。如：

application.yml

spring: cloud: consul: host: localhost port: 8500

注意：若是您使用Spring Cloud Consul Config，则须要将上述值放在bootstrap.yml而不是application.yml中。

从Environment获取的默认服务名称，实例ID和端口分别是$ {spring.application.name}，Spring Context ID和$ {server.port}。

要禁用Consul Discovery Client，能够将spring.cloud.consul.discovery.enabled设置为false【客户端能够设置注册到 Consul 中，也能够不注册到 Consul 注册中心中，根据咱们的业务来选择，只须要在使用服务时经过 Consul 对外提供的接口获取服务信息便可】。

要禁用服务注册，能够将spring.cloud.consul.discovery.register设置为false。 1.3HTTP健康检测

Consul实例的运行情况检查默认为“/ health”，这是Spring Boot Actuator应用程序中有用端点的默认位置。 若是使用非默认上下文路径或servlet路径（例如server.servletPath = / foo）或管理端点路径（例如management.context-path = / admin），则须要更改这些，即便对于Actuator应用程序也是如此。 还能够配置Consul用于检查健康端点的时间间隔。 “10s”和“1m”分别表明10秒和1分钟。

综上健康检测是须要依赖Spring Boot Actuator。

如：

application.yml

spring: cloud: consul: discovery: healthCheckPath: ${management.context-path}/health healthCheckInterval: 15s

1.3.1元数据和Consul标签

Consul尚不支持服务元数据。 Spring Cloud的ServiceInstance有一个Map <String，String>元数据字段。 Spring Consul使用Consul标签来近似元数据，直到Consul正式支持元数据。 形式为key = value的标签将被拆分并分别用做Map键和值。 没有等号=的标签将用做键和值。

application.yml.

spring: cloud: consul: discovery: tags: foo=bar, baz

上面的配置将生成一个带有foo→bar和baz→baz的映射。 1.3.2使Consul实例ID惟一

默认状况下，consul实例注册的ID等于其Spring Application Context ID。 默认状况下，Spring Application Context ID为$ {spring.application.name}：逗号，分隔，配置文件：${server.port}。 对于大多数状况，这将容许一台服务的多个实例在一台计算机上运行。 若是须要进一步的惟一性，使用Spring Cloud能够经过在spring.cloud.consul.discovery.instanceId中提供惟一标识符来覆盖它。 例如：

application.yml.

spring: cloud: consul: discovery: instanceId: ${spring.application.name}:${vcap.application.instance_id:${spring.application.instance_id:${random.value}}}

1.4查找服务 1.4.1用Ribbon

Spring Cloud支持Feign（一个REST客户端构建器）和Spring RestTemplate，用于使用逻辑服务名称/ ID而不是物理URL查找服务。 Feign和发现感知RestTemplate都使用Ribbon进行客户端负载平衡。

若是您想使用RestTemplate访问服务STORES，只需在springboot主类中声明以下：

@LoadBalanced @Bean public RestTemplate loadbalancedRestTemplate() { new RestTemplate(); }

并像以下使用它（注意咱们使用Consul的STORES服务名称而不彻底限定域名）：

@Autowired RestTemplate restTemplate;

public String getFirstProduct() {
   return this.restTemplate.getForObject("https://STORES/products/1", String.class);
}

1.4.2 用DiscoveryClient

您还可使用org.springframework.cloud.client.discovery.DiscoveryClient，它为不特定于Netflix的发现客户端提供简单的API，例如：

@Autowired private DiscoveryClient discoveryClient;

public String serviceUrl() {
    List<ServiceInstance> list = discoveryClient.getInstances("STORES");
    if (list != null && list.size() > 0 ) {
        return list.get(0).getUri();
    }
    return null;
}

2.Consul失败重试

若是您但愿应用程序启动时偶尔可能没法使用领事代理，您能够要求它在失败后继续尝试。 您须要在类路径中添加spring-retry和spring-boot-starter-aop。 默认行为是重试6次，初始退避间隔为1000毫秒，指数乘数为1.1，以便后续退避。 您可使用spring.cloud.consul.retry.*配置属性配置这些属性（和其余属性）。 这适用于Spring Cloud Consul Config和Discovery注册。

<dependency> <groupId>org.springframework.retry</groupId> <artifactId>spring-retry</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-aop</artifactId> </dependency>

3.整合Hystrix的断路器

应用程序可使用Spring Cloud Netflix项目提供的Hystrix断路器，将此启动器包含在项目pom.xml中：spring-cloud-starter-hystrix。 Hystrix不依赖于Netflix Discovery Client。 @EnableHystrix注释应放在配置类（一般是springbooyt主类）上。 而后可使用@HystrixCommand对方法进行注释，以便经过断路器进行保护。 有关详细信息，请参阅文档。 4.Hystrix检测整合Turbine和Consul

Turbine（由Spring Cloud Netflix项目提供）聚合多个Hystrix指标流实例，所以仪表板能够显示聚合视图。 Turbine使用DiscoveryClient接口查找相关实例。 要将Turbine与Spring Cloud Consul一块儿使用，请以相似于如下示例的方式配置Turbine应用程序：

pom.xml.

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

请注意，Turbine依赖性不是startter。 turbine包括对Netflix Eureka的支持。

application.yml.

spring.application.name: turbine applications: consulhystrixclient1,consulhystrixclient2 turbine: aggregator: clusterConfig: ${applications} appConfig: ${applications}

clusterConfig和appConfig部分必须匹配，所以将逗号分隔的服务ID列表放入单独的配置属性中很是有用。

Turbine.java

@EnableTurbine @SpringBootApplication public class Turbine { public static void main(String[] args) { SpringApplication.run(DemoturbinecommonsApplication.class, args); } }

做者：盲目的拾荒者 来源：CSDN 原文：https://blog.csdn.net/niugang0920/article/details/81183783 版权声明：本文为博主原创文章，转载请附上博文连接！