目录
1、背景
2、Consul是什么
3、为什么选Consul
4、Consul的部署架构
5、Consul的读一致性模式
6、Consul的服务注册和健康检查
7、Quick Start
7.1 Consul的Java客户端
7.2 KV存储Quick Start
7.3 服务注册发现Quick Start
8、Spring Cloud Commons 中的服务注册和发现
8.1 服务发现DiscoveryClient
8.2 服务注册ServiceRegistry
9、Spring Cloud Consul 实现原理
9.1 SCC的自动注入
9.2 SCC应用配置原理
9.3 SCC服务注册原理
9.4 SCC服务发现原理
10、总结
1、背景
我们知道Spring Boot是为了解决Spring使用成本高的问题，Spring Cloud是为了解决分布式系统开发成本高的问题，而在分布式系统中，服务治理又是绕不开的话题，注册中心又是核心中心的核心。而Consul就是为了在云原生上构建注册中心而准备的，尽管这样定义Consul不够全面（Consul还有很多其他能力），但Consul提供的服务发现和注册的能力才是本文的重点。如你所知，Consul不是由Spring Cloud创建出来的新东西，而是出自HashiCorp公司之手，也是其明星产品之一，HashiCorp是一家位于美国加利福尼亚州旧金山的软件公司，专为企业提供云基础设施建设的解决方案，两位创始人都是技术出身（可以简单理解成程序员创业），而且HashiCorp在2021年12月已经上市。
这里给大家看看两位创始人创业初期的照片：
2、Consul是什么
没错，在讲Spring Cloud Consul（本文简称SCC）之前，我们要好好聊聊Consul（https://github.com/hashicorp/consul），Consul 采用 Golang 开发，是一个分布式、高可用性和支持多数据中心解决方案，用于分布式的基础架构连接和配置管理系统。可以看出Consul将自己定位成一个底层的基础设施（这个HashiCorp公司对自身的定位相符），支持两种核心能力：连接（注册中心）和配置（KV）。对了，Consul还支持服务网格（What is a service mesh? | Consul by HashiCorp），具有网络分段的能力，就是说你可以在同一个网段通过配置来隔离出多个集群来（逻辑上隔离），这很适合需要灵活构建多套环境的场景。
3、为什么选Consul
其实这一直是一个比较难回答的问题，在我所知道的开源软件中，能很容易回答“为什么要有XXX以及为什么选XXX？”这个问题就只有为数不多的几款产品（例如Spring、Netty、Nignx），因为这些开源软件都因为实用性、性能和扩展性暂时所向披靡。那回过头来，我们为什么选择Consul？其实Consul的官网给了一个比较全面的回答：Consul vs、Other Software | Consul by HashiCorp。从注册中心视角来说，Consul是一个基于云原生（可以K8S打通）、CP（CAP）、支持多数据中心的注册中心服务，按照创始人的话说：“Consul提供了很多能力，这些能力在业界上都有对应的相似实现，但具备所有这些能力的只有Consul，而且Consul的每种能力都能单独使用，Consul依赖的所有能力都是自己闭环的（换句话说就是Consul依赖的所有能力都是HashiCorp自家开源的产品）”。额外需要强调一点的是Consul支持DNS协议，这在使用DNS来发现服务的场景特别有用，因为服务调用方甚至不需要感知Consul的存在，这在支持一些老的系统很有效。
我们为啥要放弃ZooKeeper选择Consul？这其实很简单，ZooKeeper不是为注册中心而生，我们知道ZooKeeper是一个分布式协作框架，里面有临时节点和Watch机制，这常常被用来实现服务注册和发现的能力，但这毕竟是“曲线救国”，一些注册中心需要得能力ZooKeeper都没有现成的（比如各式各样的健康检查、合格的服务管理控制台等），而且ZooKeeper也不支持多数据中心。
Consul和Nacos该如何选？这我给不了太多的建议，毕竟我不认为Consul和Nacos比起来有太多的优势，假如你用Spring Cloud，那么选择Consul会更合适，而如果你用Spring Cloud Alibaba，但当然首选Nacos。还有的人会通过注册中心到底应该是AP还是CP来选择，根据我的经验来看，不管是AP或CP，只要出故障后短时间内能恢复，那么对线上服务都不会有太大的影响（注册中心大多数都有客户端缓存）。
然而从Spring Cloud的视角来说，它急于找出Eureka的替代品，Consul正好是合适的选择之一。
4、Consul的部署架构
如果你是一个解决分布式系统问题的系统，那你本身就得是分布式的，我们从Consul的官方架构图开始（为了让有些强迫症的人看起来更舒服，这里给出这张图片的来源地址：Consul Architecture | Consul by HashiCorp）：
这张图之所以看起来很复杂，是因为它画了两个数据中心，我们先看这张图的上半部分（即DATACENTER1），可以看出，在Consul集群中有两个角色，一个是Client，另一个是Server，但比较特殊的是，Client是需要单独部署的，一般和服务进程部署在一起，可以理解成服务网格中边车（Sidecar）的作用。我们通过图中两两之间的交互来理解该架构图：
Client->Server：Client（即Client Agent）和Server之间使用的是gRPC通信，有意思的是在Client配置中不需要配置Server的地址，而是配置一个网段，Server也是一样，他们之间可以通过LAN的UDP协议来发现同网段的彼此。
Client->Client：你肯定会感到奇怪，Client和Client也需要交互？没错，在Consul的架构设计中，所有角色都围绕着通过 Gossip 来达成共识，Gossip协议的另一个叫法是传染病或流行病协议，通过广播来通知周边节点，周边节点收到后也进行类似的广播，所以Gossip实现简单，并且有很高的可靠性，但也有缺点，例如容易产生事件风暴，而且达成一致的时间不确定等，抛开这些不说，这意味着Client和Client之间是可以传播和共享“知识”或“认知”的（比如关于活跃Server节点的信息），所以Consul号称任何节点挂了，都不影响Consul的使用。Consul 是通过底层的 Serf 来使用Gossip协议的（注意，Serf也是HashiCorp公司的产品），有关Serf的内容参见https://github.com/hashicorp/serf，本文不做过多介绍。采用Gossip还有一大好处，意味着我们可以动态的往集群中新增或删除节点，而不需用改集群的配置，他们会自动达成共识（发现或摘掉彼此），回想我们之前用ZooKeeper的客户端，使用时客户端一定要尽可能多的配置ZooKeeper Server（即Leader、Follower和Observer），以防止某些ZooKeeper Server节点挂掉导致该客户端无法连接ZooKeeper集群，而且在配置ZooKeeper集群时，需要配置彼此的地址（来决定哪些能投票和选举），在Consul中不存在这样的烦恼。
Server->Server：大多数分布式的存储系统都离不开通过分区和副本解决容量和可用性的问题，Consul的Server（即Server Agent）也不例外，但Consul中没有数据分区的概念，只有数据副本，这也意味着Consul和ZooKeeper一样，同一个数据中心的Consul Server节点存储了全量的数据。细心的读者在这里会发现一个矛盾点，Consul集群底层是Gossip协议，Gossip协议构建的系统一般是AP系统，为啥我们却说Consul是CP系统？这是因为Consul的Server使用Raft协议来选主，意味着Server节点要达成一致，必须要超过半数Server节点通过才行，所以Consul本质上是一个CP系统。
在实际使用过程中，是可以不部署Client Agent的（特别是你不需要Sidecar的时候），可以通过Consul提供的SDK直连Consul Server，这是因为不管是Client Agent还是ServerAgent都提供了相同的Rest接口，就是说我们可以通过HTTP/HTTPS直接访问Client Agent或者Server Agent。
注意，Consul提供了多数据中心的支持，并且提供了跨数据中心的查询，这也是为啥Consul的官方架构图中特意显示了两个数据中心（即上图的下半部分）。
5、Consul的读一致性模式
考虑到被使用的场景不同，Consul提供了三种读一致性模型（其行为会影响KV的读取和服务发现），这三种读一致性模型如下（详见Consistency Modes | Consul by HashiCorp）：
default- 默认几乎在所有情况下都是强一致的。但在选举新的领导者的小窗口期间，旧的领导者可能会为陈旧的值提供服务，所以此模式读取速度快但有可能读到旧值。
consistent- 此模式是强一致的。它要求领导者与一定数量的对等节点验证它仍然是领导者。这引入了到所有服务器节点的额外往返，由于增加了额外的往返行程而增加了延迟。大多数客户端不应该使用它，除非他们不能容忍过时的读取。
stale- 此模式允许任何服务器为读取提供服务，无论它是否是领导者。这意味着可以任意的读取过时的值；但是，结果通常不会落后领导者 50 毫秒。优势是非常快速和可扩展的读取，但具有更高的陈旧值的可能性。由于此模式允许在没有领导者的情况下进行读取，因此当集群不可用时仍然能够响应查询。
需要注意的是，这些模式是可以同时存在的，因为它并不是通过Consul Server的某项配置决定的，而是由客户端的请求参数决定的。
6、Consul的服务注册和健康检查
在Consul注册服务很简单，只需要提供如下信息（详见Register Services - Service Definitions | Consul by HashiCorp）：
其实只有【-name】这个参数是必须的（-address和-port默认将使用Consul Client Agent的地址和端），而【-tag】通常用于给服务添加特殊的属性（例如该服务属于的机房或者数据中心），所以，如下最简控制台命令就通过Consul Client Agent向Consul注册了一个名叫【myApp】的服务：
consul services register -name=myApp
这里需要关注下【-meta】和【-tag】的使用，meta其实是一个Map结构，而且有诸多限制，比如我们最多能定义64个键值对，键最多为128个ASCII字符，值最多512个字符。meta更多的用于描述服务的个性化属性，这些属性在不同服务之间是没关联的，而tag的更多的是描述一些跨服务的通用属性，例如所属机房和数据中心等。当然，我们在查询服务时，即可以通过meta来筛查，也可以通过tag来筛查。
服务发现的主要目标之一是提供可用（健康）服务的目录。为此，在服务注册时，我们可以自定义健康检查的方式，Consul针对不同的使用场景提供了多达8种的健康检查的方式（参见Monitor Services - Check Definitions | Consul by HashiCorp），我们这里列举其中四种：
HTTP + Interval：让Consul通过GET向指定的 URL发出 HTTP请求。服务的状态取决于 HTTP 响应代码：任何2xx代码都被视为通过，429的Too ManyRequests是警告，其他任何应答码都是失败。TCP + Interval：Consul将尝试通过TCP连接到指定的 IP/主机名和端口。服务的状态取决于连接尝试是否成功（即端口当前正在接受连接）。如果连接被接受，则状态为 success，否则状态为critical。Time to Live（TTL）： 这种健康检查保留给定 TTL 的最后一个已知状态，由应用自己主动上报自己的健康状态。gRPC + Interval ：这些检查适用于支持标准 gRPC 健康检查协议的应用程序。
我们可以根据自己的实际情况来选择合适的健康检查机制，这也是Consul的强大之处，像ZooKeeper这种非专属的注册中心是不具备这些能力的。
7、Quick Start
为了让大家对Consul有直观的认识，本文中将演示Consul的两种核心能力的quick start，即KV存储和注册中心（服务发现和注册），不管使用哪种能力，都需要部署Consul，有时间的读者可以直接跟随官网的介绍来start：Get Started | Consul - HashiCorp Learn。
如果读者本地安装了Docker环境，那么只需要在控制台输入如下命令即可部署一个可供学习或测试的Consul实例（参见Docker Hub）：
docker run -d --name=dev-consul -e CONSUL_BIND_INTERFACE=eth0 consul
当然，如果本地没有安装Docker，也可以去官网下载二进制包（Downloads | Consul by HashiCorp），下载完毕后，cd到consul的目录，执行如下命令即可（-bind中写自己本地的IP即可）：
consul agent -server -bootstrap -ui -data-dir /Users/xxx/documents/consul -node=agent1 -bind=xxx.xxx.xxx.xxx
注意，因为我们要访问本地的Consul控制台，所以记得加上【-ui】这个参数。
启动成功后，访问 http://localhost:8500/ 将出现类似如下Consul控制台界面：
因为我们要演示Consul的基本功能，所以先建一个Spring Cloud工程（建Spring Cloud工程的过程这里不再阐述，参见IDE自带的Spring Cloud项目创建过程或者Spring | Spring Quickstart Guide），并且我们假定咱们的应用名称为【my-spring-cloud-consul】，即application.yml配置成如下样子：
spring: application: name: my-spring-cloud-consul cloud: consul: host: localhost port: 8500 discovery: enabled: true heartbeat: enabled: true
注意，heartbeat需要设置成true，否则Consul会因为检查 /actuator/health 路径报404而在控制台上显示“All service checks failing”。
这里也给出该项目的pom.xml：
7.1 Consul的Java客户端
Consul有 ecwid 和 orbitz 两种常见的Java客户端，本文只介绍 ecwid，请确保项目中包含如下依赖：
由于我们本地已经启动了Consul Server，那么可以在项目中写个main方法来进行测试，这里先给大家演示一个监听key/valule变化的case：
System.out.println("开始演示KV监听机制"); ConsulClient localhostClient = new ConsulClient("localhost:8500"); String key = "com.my.app.foo"; // 给key设置一个值 localhostClient.setKVValue(key, "My Lover"); // 获取当前key的最新值和版本（consulIndex） Response
执行该程序后，可以在Consul的控制台将【com.my.app.foo】的值改掉，就可以在输出控制台看到更新后的值了。KV的操作相对比较简单，这里我们再演示一个服务注册和发现的例子，服务注册和发现的代码如下：
ConsulClient localhostClient = new ConsulClient("localhost:8500"); String serviceName = "myapp"; // register new service NewService newService01 = new NewService(); newService01.setId("myapp_01"); newService01.setName(serviceName); newService01.setTags(Arrays.asList("EU-West", "EU-East")); newService01.setPort(8080); localhostClient.agentServiceRegister(newService01); // register new service with associated health check NewService newService02 = new NewService(); newService02.setId("myapp_02"); newService02.setName(serviceName); newService02.setTags(Collections.singletonList("EU-East")); newService02.setPort(8080); // 添加一个健康检查 NewService.Check serviceCheck = new NewService.Check(); // 该地址由consul来回调检查 serviceCheck.setHttp("http://xxx.xxx.xxx.xxx:8080/hearth/check"); serviceCheck.setInterval("10s"); newService02.setCheck(serviceCheck); localhostClient.agentServiceRegister(newService02); System.out.println("注册完毕！！！");
上面已经注册了一个【myapp】的服务，下面我们开始演示如何监听服务：
ConsulClient localhostClient = new ConsulClient("localhost:8500"); String serviceName = "myapp"; // 基于服务名称查询所有健康的服务 HealthServicesRequest request = HealthServicesRequest.newBuilder() .setPassing(true) .setQueryParams(QueryParams.DEFAULT) .build(); Response> healthyServices = localhostClient.getHealthServices(serviceName, request); System.out.println(serviceName + "有" + healthyServices.getValue().size() + "个健康实例"); // 基于某个Tag查询所有健康的服务 HealthServicesRequest request1 = HealthServicesRequest.newBuilder() .setTag("EU-West") .setPassing(true) .setQueryParams(QueryParams.DEFAULT) .build(); Response> healthyServices1 = localhostClient.getHealthServices("myapp", request1); System.out.println(serviceName + "有" + healthyServices1.getValue().size() + "个健康实例"); // 查询所有的名为myapp的实例（包括健康检查没过的） Response> myappServices = localhostClient.getCatalogService(serviceName, CatalogServiceRequest.newBuilder() .setQueryParams(QueryParams.DEFAULT).build()); System.out.println(serviceName + "一共有" + myappServices.getValue().size() + "个实例"); // 查询所有的服务（包括健康检查没过的） Response
其实我们不难发现，不管是KV还是服务发现，Consul都提供了【长轮训+版本】来监听变化的机制。
7.2 KV存储Quick Start
接下面我们演示Spring Cloud项目如何使用Consul，先看看KV存储，需要注意一点，Consul的目标并不是成为一个旗舰型的配置系统或者KV高速存储系统，所以请不要把Consul当做Apollo或者Redis来使用，Consul的目标是管理分布式系统的少量应用配置。
本文中将展示如何通过一个Spring应用来获取Consul的KV配置，并且我们在Consul控制台修改该配置后，Spring应用能获取到最新的配置。话不多说我们立马开始，我们点击Consul控制台左侧的【Key/Value】，新加一个名为【config/my-spring-cloud-consul/abc】的变量，其值为【my lover】，如下图：
需要注意的是，如果想在Spring Cloud应用中读取到对应的KV配置，那么这个Key的前缀一定是【config/[Spring应用名称/]】。点击【Save】按钮保存后，这个KV配置就创建成功了。
那么我们在Spring Cloud中如何读取该配置呢？直接Show代码吧：
@RefreshScope@RestController@RequestMapping("/mzz")public class HomeController { @Value("${abc}") private String abc = "abc"; @RequestMapping("/getLatestAbc") public String getLatestAbc() { return abc; }}
可以看出，我们在控制器中定义了一个abc的变量（正好和Consul中的config/my-spring-cloud-consul/abc对应），启动该Spring Cloud应用后，我们访问 http://localhost:8080/mzz/getLatestAbc 就可以看到返回abc的最新值了，如果你在Consul控制台中修改config/my-spring-cloud-consul/abc的值，重新访问 http://localhost:8080/mzz/getLatestAbc 可以发现能返回修改后的值（注意，一定要使用@RefreshScope）。
7.3 服务注册发现Quick Start
使用Spring Cloud Consul进行服务注册很简单，只要在我们启动类上打上一个@EnableDiscoveryClient注解即可（新版本已经将这个注解废弃），如下：
@EnableDiscoveryClient@SpringBootApplicationpublic class SpringCloudConsulApplication { public static void main(String[] args) { SpringApplication.run(SpringCloudConsulApplication.class, args); }}
启动后，我们就可以在Consul控制台看到如下信息：
说明服务注册成功！！
8、Spring Cloud Commons 中的服务注册和发现
Spring Cloud Commons 以两个库的形式提供功能：Spring Cloud Context 和 Spring Cloud Commons。Spring Cloud Context 为 Spring Cloud 应用程序的 ApplicationContext 提供实用程序和特殊服务（引导上下文、加密、刷新范围和环境端点）。Spring Cloud Commons 是一组抽象和通用类，用于不同的 Spring Cloud 实现（例如 Spring Cloud Netflix 与 Spring Cloud Consul）。
为啥突然提到Spring Cloud Commons？Spring Cloud Commons 是 Spring Cloud 核心基础库类，而SCC的服务发现和注册和 Spring Cloud Commons 中的 spring-cloud-commons 库实现息息相关。
spring-cloud-commons 库主要包含三个特性（摘自官网）：
服务发现客户端 DiscoveryClient 接口
服务注册 ServiceRegistry 接口
用服务发现客户端（DiscoveryClient）解析主机名的 RestTemplate 实现（其中包含LoadBalance的实现）
8.1 服务发现DiscoveryClient 我们先来看下 DiscoveryClient 接口的定义：
public interface DiscoveryClient extends Ordered {int DEFAULT_ORDER = 0;String description();List
（为了减少行数，去掉了注释，有兴趣的读者还可以去看看 ServiceInstance 接口的定义）可以看到其核心方法就是通过服务ID（serviceId）来返回该服务的所有实例（一般是返回健康可用的实例）列表，如果你是要实现服务发现的能力，只要你只要实现DiscoveryClient 接口，并将该实现类通过Spring Boot的Auto-configuration机制注入到Spring容器中，那么你的服务发现能力就能被（例如给LoadBalance）使用。所以，如果你想从一个注册中心中找可用的服务，那么你可以这样用：
public class SomeLoadBalance {@Autowireprivate DiscoveryClient discoveryClient; ..、...}
那如果我有多个注册中心呢？别忘了 DiscoveryClient 继承自 Ordered，我们可以自定义各个注册中心的 DiscoveryClient 实现类的顺序，所以如果是多个注册中心，那么我们可以这么用：
public class SomeLoadBalance {@Autowireprivate List
Spring会默认把 getOrder() 值较小（优先级较高）的放在列表中的前面，然后可以通过优先级来找某个服务的实例，例如当我们有两个机房A（主）和B（备），A机房的应用优先调用A机房的基础服务（即同机房调用），但A机房的应用为了容灾还连接了B机房的基础服务，我们可以把A机房的 DiscoveryClient 实例优先级调整的比B机房的DiscoveryClient高（即A机房的DiscoveryClient 实例返回的 order 值比B机房的小），这样一旦A机房的基础服务可用，A机房的应用就不会调到B机房的基础服务，而如果A机房的基础服务出现故障，那么从A机房的基础服务中就无法找到可用的，我们可以让其去寻找B机房的基础服务。
如果只是简单的服务发现，spring-cloud-commons 提供了 DiscoveryClient 接口的基础实现类 SimpleDiscoveryClient，有了 SimpleDiscoveryClient 我们就可以通过配置文件来配置服务发现了，如何配置参见：Cloud Native Applications
8.2 服务注册ServiceRegistry
我们接下来再聊聊服务注册，让我们看看 ServiceRegistry 接口的定义：
public interface ServiceRegistry
可以看到，该泛型接口可以注册一个 Registration 接口的实现类的对象，而这个 Registration 其实和前面说的服务发现接口（DiscoveryClient）中用到的服务实例接口 ServiceInstance 有着非常紧密的联系：
public interface Registration extends ServiceInstance {}
ServiceRegistry 接口包含了注册、注销等核心能力的定义，如果要实现自定义服务注册的能力，方法和实现自定义服务发现一样，通过 Auto-configuration 机制即可，这里不再阐述。
这里还有个问题没有解释，为啥我们能做到一启动应用就自动将自己注册（要关闭默认的自动注册行为可以设置 @EnableDiscoveryClient(autoRegister=false) 或者 spring.cloud.service-registry.auto-registration.enabled 设置成 false）？为了对服务注册进行生命周期管理，spring-cloud-commons 提供了抽象类 AbstractAutoServiceRegistration，AbstractAutoServiceRegistration 实现了 ApplicationListener
public abstract class AbstractAutoServiceRegistration
9、Spring Cloud Consul 实现原理
前面说了这么多，现在总算轮到我们开始讨论SCC的原理了。
9.1 SCC的自动注入
我们知道，要和Spring Boot应用打通，最常用的方式就是Auto-configuration，SCC也不例外，其 spring-cloud-starter-consul-discovery 模块主要就是干这个事情，需要注意的是，如果按照官方文档（Spring Cloud Consul）说的只依赖 spring-cloud-starter-consul-discovery 是没开启Consul的KV配置能力的，因为配置能力在 spring-cloud-starter-consul-config 模块中，所以如果嫌麻烦，我们可以在项目中直接依赖 spring-cloud-starter-consul-all 这个jar！
9.2 SCC应用配置原理当我们依赖 spring-cloud-starter-consul-config 时，主要是依赖 spring-cloud-consul-config 这模块，老规矩，我们从 spring.factories 入手：
# Auto Configurationorg.springframework.boot.autoconfigure.EnableAutoConfiguration=org.springframework.cloud.consul.config.ConsulConfigAutoConfiguration# Bootstrap Configurationorg.springframework.cloud.bootstrap.BootstrapConfiguration=org.springframework.cloud.consul.config.ConsulConfigBootstrapConfiguration
我们一眼就看出核心关键是 ConsulConfigAutoConfiguration，其实现如下：
@Configuration@ConditionalOnConsulEnabled@ConditionalOnProperty(name = "spring.cloud.consul.config.enabled", matchIfMissing = true)public class ConsulConfigAutoConfiguration {public static final String CONFIG_WATCH_TASK_SCHEDULER_NAME = "configWatchTaskScheduler";@Configuration@ConditionalOnClass(RefreshEndpoint.class)protected static class ConsulRefreshConfiguration {@Bean@ConditionalOnProperty(name = "spring.cloud.consul.config.watch.enabled", matchIfMissing = true)public ConfigWatch configWatch(ConsulConfigProperties properties,ConsulPropertySourceLocator locator, ConsulClient consul,@Qualifier(CONFIG_WATCH_TASK_SCHEDULER_NAME) TaskScheduler taskScheduler) {return new ConfigWatch(properties, consul, locator.getContextIndexes(),taskScheduler);}@Bean(name = CONFIG_WATCH_TASK_SCHEDULER_NAME)@ConditionalOnProperty(name = "spring.cloud.consul.config.watch.enabled", matchIfMissing = true)public TaskScheduler configWatchTaskScheduler() {return new ThreadPoolTaskScheduler();}}}
同样，我们可以通过将总开关 spring.cloud.consul.config.enabled 设置成 false 来关闭该功能，配置更新被后的原理是SCC使用Consul的Java SDK来进行长轮训Watch配置的变更，以保证配置能实时更新，但需要注意的一点是，如果要保证配置变更的实时感知，ConfigWatch 中用到的两个配置需要额外关注，即定时任务的间隔时间 spring.cloud.consul.config.watch.delay（默认1000ms）要足够小，长轮训等待时间 spring.cloud.consul.config.watch.waitTime (默认55s) 可以配置的长一点（保持默认即可），因为用的是 scheduleWithFixedDelay，所以极端情况下配置更新了最长在 spring.cloud.consul.config.watch.delay 内无法感知。
有兴趣的读者可以去看：org.springframework.cloud.consul.config.ConfigWatch的实现，这里不再阐述。
9.3 SCC服务注册原理spring-cloud-starter-consul-discovery 主要目的之一就是依赖 spring-cloud-consul-discovery ，而 spring-cloud-consul-discovery 模块的 spring.factories 文件内容如下：
org.springframework.boot.autoconfigure.EnableAutoConfiguration=org.springframework.cloud.consul.discovery.RibbonConsulAutoConfiguration,org.springframework.cloud.consul.discovery.configclient.ConsulConfigServerAutoConfiguration,org.springframework.cloud.consul.serviceregistry.ConsulAutoServiceRegistrationAutoConfiguration,org.springframework.cloud.consul.serviceregistry.ConsulServiceRegistryAutoConfiguration,org.springframework.cloud.consul.discovery.ConsulDiscoveryClientConfiguration,org.springframework.cloud.consul.discovery.ConsulCatalogWatchAutoConfiguration, org.springframework.cloud.consul.support.ConsulHeartbeatAutoConfigurationorg.springframework.cloud.bootstrap.BootstrapConfiguration=org.springframework.cloud.consul.discovery.configclient.ConsulDiscoveryClientConfigServiceBootstrapConfiguration
我们先来看看和服务注册相关的两个AutoConfiguration，即 ConsulServiceRegistryAutoConfiguration 和 ConsulAutoServiceRegistrationAutoConfiguration，直接show code，先看 ConsulServiceRegistryAutoConfiguration 的实现：
@Configuration@ConditionalOnConsulEnabled // spring.cloud.consul.enabled 不为false且存在ConsulClient类@ConditionalOnProperty(value = "spring.cloud.service-registry.enabled", matchIfMissing = true)@AutoConfigureBefore(ServiceRegistryAutoConfiguration.class)public class ConsulServiceRegistryAutoConfiguration {@Bean@ConditionalOnMissingBeanpublic ConsulServiceRegistry consulServiceRegistry(ConsulClient consulClient,ConsulDiscoveryProperties properties, HeartbeatProperties heartbeatProperties,@Autowired(required = false) TtlScheduler ttlScheduler) {return new ConsulServiceRegistry(consulClient, properties, ttlScheduler,heartbeatProperties);}@Bean@ConditionalOnMissingBeanpublic HeartbeatProperties heartbeatProperties() {// 注意，默认HeartbeatProperties#ttlValue 是30秒（因为Consul的健康检查的TTL模式默认就30秒），但并不意味着我们主动上报心跳间隔是30秒（你不可能去踩点），// 所以这里SCC有自己的算法，默认会20秒上报一次（参见HeartbeatProperties#computeHearbeatInterval()）return new HeartbeatProperties();}@Bean@ConditionalOnMissingBeanpublic ConsulDiscoveryProperties consulDiscoveryProperties(InetUtils inetUtils) {return new ConsulDiscoveryProperties(inetUtils);}}
从代码可以看出，ConsulServiceRegistryAutoConfiguration 构建了心跳、服务发现配置和服务注册（含服务发现）的三个Bean，而且仅仅在 spring.cloud.consul.enabled 和 spring.cloud.service-registry.enabled 不为false且存在ConsulClient类时才去自动装配。其中的 TtlScheduler 入参就是TTL的定时任务实现。
而需要注意的一点是，该 AutoConfiguration 是在 ServiceRegistryAutoConfiguration 之前来构建的（因为有@AutoConfigureBefore），这是因为 ServiceRegistryAutoConfiguration 是 spring-cloud-common 中用来自动装载所有ServiceRegistry的，所以需要在它之前先把Consul的ServiceRegistry构建出来，这也是为什么要拆成 ConsulServiceRegistryAutoConfiguration 和 ConsulAutoServiceRegistrationAutoConfiguration 两个 AutoConfiguration 的原因。
看完 ConsulServiceRegistryAutoConfiguration 后我们接下来看看 ConsulAutoServiceRegistrationAutoConfiguration 做了什么事情：
@Configuration@ConditionalOnBean(AutoServiceRegistrationProperties.class)@ConditionalOnMissingBean(type = "org.springframework.cloud.consul.discovery.ConsulLifecycle")@ConditionalOnConsulEnabled // 这里和 ConsulServiceRegistryAutoConfiguration 保持一致@ConditionalOnProperty(value = "spring.cloud.service-registry.auto-registration.enabled", matchIfMissing = true)@AutoConfigureAfter({ AutoServiceRegistrationConfiguration.class,ConsulServiceRegistryAutoConfiguration.class })public class ConsulAutoServiceRegistrationAutoConfiguration {@AutowiredAutoServiceRegistrationProperties autoServiceRegistrationProperties;@Bean@ConditionalOnMissingBeanpublic ConsulAutoServiceRegistration consulAutoServiceRegistration(ConsulServiceRegistry registry,AutoServiceRegistrationProperties autoServiceRegistrationProperties,ConsulDiscoveryProperties properties,ConsulAutoRegistration consulRegistration) {return new ConsulAutoServiceRegistration(registry,autoServiceRegistrationProperties, properties, consulRegistration);}@Beanpublic ConsulAutoServiceRegistrationListener consulAutoServiceRegistrationListener(ConsulAutoServiceRegistration registration) {return new ConsulAutoServiceRegistrationListener(registration);}@Bean@ConditionalOnMissingBeanpublic ConsulAutoRegistration consulRegistration(AutoServiceRegistrationProperties autoServiceRegistrationProperties,ConsulDiscoveryProperties properties, ApplicationContext applicationContext,ObjectProvider> registrationCustomizers,ObjectProvider> managementRegistrationCustomizers,HeartbeatProperties heartbeatProperties) {return ConsulAutoRegistration.registration(autoServiceRegistrationProperties,properties, applicationContext, registrationCustomizers.getIfAvailable(),managementRegistrationCustomizers.getIfAvailable(), heartbeatProperties);}@Configuration@ConditionalOnClass(ServletContext.class)protected static class ConsulServletConfiguration {@Beanpublic ConsulRegistrationCustomizer servletConsulCustomizer(ObjectProvider
这里我们也可以发现，当spring.cloud.service-registry.auto-registration.enabled 为 false 时，就不会去自动注册自己的服务了。
那么，SCC在启动时往Consul Server 注册了哪些内容？根据我们之前的分析，SCC肯定有 Registration 的实现，即 ConsulRegistration 和 ConsulAutoRegistration，其中 ConsulAutoRegistration 又是 ConsulRegistration 的子类，ConsulAutoRegistration#registration() 方法实现如下：
public static ConsulAutoRegistration registration(AutoServiceRegistrationProperties autoServiceRegistrationProperties,ConsulDiscoveryProperties properties, ApplicationContext context,List
从上述代码可知，我们可以通过实现 ConsulRegistrationCustomizer 接口并注入到Spring容器中来增加我们注册前的自定义行为，比如新增我们自己的tag或者meta数据， ConsulRegistrationCustomizer 实现如下：
public interface ConsulRegistrationCustomizer {void customize(ConsulRegistration registration);}
可以看到入参是 ConsulRegistration 对象，你可以为所欲为了。
9.4 SCC服务发现原理
org.springframework.boot.autoconfigure.EnableAutoConfiguration=org.springframework.cloud.consul.discovery.RibbonConsulAutoConfiguration,org.springframework.cloud.consul.discovery.configclient.ConsulConfigServerAutoConfiguration,org.springframework.cloud.consul.discovery.ConsulDiscoveryClientConfiguration,org.springframework.cloud.consul.discovery.ConsulCatalogWatchAutoConfiguration,
这是前面出现过的 spring-cloud-consul-discovery 的 spring.factories 文件的部分内容，可以看出和服务发现相关的是4个 AutoConfiguration，我们重点看看 ConsulDiscoveryClientConfiguration 和 ConsulCatalogWatchAutoConfiguration 两个 AutoConfiguration。
ConsulDiscoveryClientConfiguration 的代码量很少，它主要是构造 ConsulDiscoveryClient，ConsulDiscoveryClient 里面包装了 ecwid 的 ConsulClient，代码如下：
public class ConsulDiscoveryClient implements DiscoveryClient {private static final Log log = LogFactory.getLog(ConsulDiscoveryClient.class);private final ConsulClient client;private final ConsulDiscoveryProperties properties; ..、...}
还记得咱们之前聊到的 spring-cloud-commons 中的服务发现扩展接口 DiscoveryClient 吗？ConsulDiscoveryClient 就是其实现类，那我们直接看看 ConsulDiscoveryClient 的实现吧：
public class ConsulDiscoveryClient implements DiscoveryClient {private static final Log log = LogFactory.getLog(ConsulDiscoveryClient.class);private final ConsulClient client;private final ConsulDiscoveryProperties properties;public ConsulDiscoveryClient(ConsulClient client,ConsulDiscoveryProperties properties) {this.client = client;this.properties = properties;}@Overridepublic String description() {return "Spring Cloud Consul Discovery Client";}@Overridepublic List
整体实现非常的简单，这里不做过多阐述。
接下来是 ConsulCatalogWatchAutoConfiguration，该 AutoConfiguration 实现如下：
@Configuration@ConditionalOnConsulEnabled@ConditionalOnProperty(value = "spring.cloud.consul.discovery.catalog-services-watch.enabled", matchIfMissing = true)@ConditionalOnDiscoveryEnabled@AutoConfigureAfter({ ConsulDiscoveryClientConfiguration.class })public class ConsulCatalogWatchAutoConfiguration {public static final String CATALOG_WATCH_TASK_SCHEDULER_NAME = "catalogWatchTaskScheduler";@Bean@ConditionalOnMissingBeanpublic ConsulCatalogWatch consulCatalogWatch(ConsulDiscoveryProperties discoveryProperties, ConsulClient consulClient,@Qualifier(CATALOG_WATCH_TASK_SCHEDULER_NAME) TaskScheduler taskScheduler) {return new ConsulCatalogWatch(discoveryProperties, consulClient, taskScheduler);}@Bean(name = CATALOG_WATCH_TASK_SCHEDULER_NAME)public TaskScheduler catalogWatchTaskScheduler() {return new ThreadPoolTaskScheduler();}}
可以发现其实现和之前讲配置时提到的 ConsulConfigAutoConfiguration 很像，核心就是构造 ConsulCatalogWatch，当然我们可以通过将 spring.cloud.consul.discovery.catalog-services-watch.enabled 设置成 false 来关闭该功能，ConsulCatalogWatch 顾名思义就是用来监控（服务）目录的，ConsulCatalogWatch 内部会初始化一个定时任务来长轮训监听所有服务的变化，并将该变化通过Spring的Event发出来，其实现如下：
public class ConsulCatalogWatchimplements ApplicationEventPublisherAware, SmartLifecycle {private static final Log log = LogFactory.getLog(ConsulDiscoveryClient.class);private final ConsulDiscoveryProperties properties;private final ConsulClient consul;private final TaskScheduler taskScheduler;private final AtomicReference
仅仅是为了在服务发生变更时发布 HeartbeatEvent ？需要知道的是，这个 HeartbeatEvent 在SCC 和 spring-cloud-commons 内部都是没有消费的，特意翻了下 ConsulCatalogWatch 的提交记录：
果然，主要是给 Zuul 这种上游框架对服务变更做出反应用的，记住一点，这里只是把变更的版本通知出去了，至于变更内容是什么还是需要上游框架去拉一次的。还有，如果真要做到实时通知，spring.cloud.consul.discovery.catalogServicesWatchDelay（默认1000毫秒） 的值要配置的足够小，而 spring.cloud.consul.discovery.catalogServicesWatchTimeout（默认2秒） 的值，因为用的是 scheduleWithFixedDelay，所以极端情况下配置更新了最长在 spring.cloud.consul.discovery.catalogServicesWatchDelay 内无法感知。
10、总结
本文较详细的介绍了Consul、Spring Cloud Commons 和 SCC 之间的关系以及 SCC 的实现原理，希望读者能有所收获，如果有阐述有误的地方也欢迎指正。