Consul概念和知识点、问题点
什么是Consul？
Consul是HashiCorp公司推出的开源工具，Consul由Go语言开发，部署起来非常容易，只需要极少的可执行程序和配置文件，具有绿色、轻量级的特点。Consul是分布式的、高可用的、 可横向扩展的用于实现分布式系统的服务发现与配置。
Consul具有哪些特点?
与其他分布式服务注册与发现的方案相比，Consul的方案更“一站式”，内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案，不再需要依赖其他工具（比如ZooKeeper等），使用起来也较为简单。
- 服务发现（Service Discovery）：
Consul提供了通过DNS或者HTTP接口的方式来注册服务和发现服务。一些外部的服务通过Consul很容易的找到它所依赖的服务。 - 健康检查（Health Checking）：Consul的Client可以提供任意数量的健康检查，既可以与给定的服务相关联(“webserver是否返回200 OK”)，也可以与本地节点相关联(“内存利用率是否低于90%”)。操作员可以使用这些信息来监视集群的健康状况，服务发现组件可以使用这些信息将流量从不健康的主机路由出去。
- Key/Value存储：应用程序可以根据自己的需要使用Consul提供的Key/Value存储。 Consul提供了简单易用的HTTP接口，结合其他工具可以实现动态配置、功能标记、领袖选举等等功能。
- 安全服务通信：Consul可以为服务生成和分发TLS证书，以建立相互的TLS连接。意图可用于定义允许哪些服务通信。服务分割可以很容易地进行管理，其目的是可以实时更改的，而不是使用复杂的网络拓扑和静态防火墙规则。
- 多数据中心：Consul支持开箱即用的多数据中心. 这意味着用户不需要担心需要建立额外的抽象层让业务扩展到多个区域。
Consul的几个概念
client
client表示consul的client模式，就是客户端模式。是consul节点的一种模式，这种模式下，所有注册到当前节点的服务会被转发到server，本身是不持久化这些信息。
server
server表示consul的server模式，表明这个consul是个server，这种模式下，功能和client都一样，唯一不同的是，它会把所有的信息持久化的本地，这样遇到故障，信息是可以被保留的。
server-leader
中间那个server下面有leader的字眼，表明这个server是它们的老大，它和其它server不一样的一点是，它需要负责同步注册的信息给其它的server，同时也要负责各个节点的健康监测。
其它信息
其它信息包括它们之间的通信方式，还有一些协议信息，算法。它们是用于保证节点之间的数据同步，实时性要求等等一系列集群问题的解决。这些有兴趣的自己看看官方文档。
主要参数说明
-advertise： 通知展现地址用来改变我们给集群中的其他节点展现的地址，默认情况下-bind地址就是展现地址，然而也存在一些路由地址是不能受约束的，这时候会激活一个不同的地址来供应，如果这个地址不能路由，这个路由将不能被加入集群
-bootstrap： 用来控制一个server是否在bootstrap模式，在一个datacenter中只能有一个server处于bootstrap模式，当一个server处于bootstrap模式时，可以自己选举为raft leader，在一个节点的模式下这种方式很重要，否则在集群中的一致性不能保证，不推荐在集群中应用这个标识
-bootstrap-expect： 在一个datacenter中期望提供的server节点数目，当该值提供的时候，consul一直等到达到指定sever数目的时候才会引导整个集群，该标记不能和bootstrap公用（推荐使用的方式）
-bind： 该地址用来在集群内部的通讯，集群内的所有节点到地址都必须是可达的，默认是0.0.0.0，这意味着Consulo会使用第一个可用的私有IP地址，Consul可以使用TCP和UDP并且可以使用共同的端口，如果存在防火墙，这两者协议必须是允许的。
-client： consul绑定在哪个client地址上，这个地址提供HTTP、DNS、RPC等服务，默认是127.0.0.1，只允许回路连接。RPC地址用于Consul命令，比如Consul members可以查询当前运行的Consul代理
-config-file： 明确的指定要加载哪个配置文件，文件下的所有配置会合并在一起进行加载
-config-dir： 配置文件目录，里面所有以.json结尾的文件都会被加载
-data-dir： 提供一个目录用来存放agent的状态，所有的agent允许都需要该目录，该目录必须是稳定的，系统重启后都继续存在
-dc： 该标记控制agent运行的datacenter的名称，默认是dc1
-encrypt： 指定secret key，使consul在通讯时进行加密，key可以通过consul keygen生成，同一个集群中的节点必须使用相同的key
-http-port： HTTP API侦听端口,默认端口8500，可以在环境变量中进行设置，非常有用，可以用于与Consul进行通讯
-join： 加入一个已经启动的agent的ip地址，可以多次指定多个agent的地址。如果consul不能加入任何指定的地址中，则agent会启动失败，默认agent启动时不会加入任何节点。
-retry-join： 和join类似，但是允许你在第一次失败后进行尝试。
-retry-interval： 两次join之间的时间间隔，默认是30s
-retry-max： 尝试重复join的次数，默认是0，也就是无限次尝试
-log-level： consul agent启动后显示的日志信息级别。默认是info，可选：trace、debug、info、warn、err。跟踪 调试 详情 警告 错误，可以通过Consul monitor使用任何级别，也可以通过重启加载新的配置级别
-node： 节点在集群中的名称，在一个集群中必须是唯一的，默认是该节点的主机名（代表一个机器）
-pid-file： 提供一个路径来存放pid文件，可以使用该文件进行SIGINT/SIGHUP(关闭/更新)agent
-protocol： consul使用的协议版本 consul -v
-rejoin： 使consul忽略先前的离开，在再次启动后仍旧尝试加入集群中。
-server： 定义agent运行在server模式还是Client模式，提供时即为Server端，每个集群至少有一个server并且每台机器上不要超过5个dataceter.所有服务器采用一致性算法Raft保证数据一致,确保在故障的情况下的可用性。
-syslog： 开启系统日志功能，只在linux/osx上生效
-ui-dir： 提供存放web ui资源的路径，该目录必须是可读的
5个端口的作用
- 8300：集群内数据的读写和复制，仅TCP
- 8301：单个数据中心gossip协议（流言协议）同时使用TCP和UDP通信通讯
- 8302：跨数据中心gossip协议（流言协议）同时使用TCP和UDP通信通讯
- 8500：提供获取服务列表、注册服务、注销服务等HTTP接口，提供UI服务，仅TCP
- 8600：采用DNS协议提供服务发现功能
Consul的反熵
这里首先介绍跟服务和健康检查紧密相关的两个部件：Agent和Catalog。
Agent
Agent存在于Consul的每一个节点中，负责维护注册到其上的服务和健康检查，以及执行这些健康检查，更新本地服务的健康信息。
Catalog
Catalog存在于Server 节点，聚合了各个Agent采集的信息，包括服务、健康检查、相关的节点，以及它们对应的状态，服务发现就是基于Catalog来做的。
然而Catalog中这些信息的字段要比Agent维护的少很多，因为Catelog只是一个视图，它没有关于服务、健康检查和节点的设置项信息。
当服务或健康检查在Agent注册后，信息就会通知到Catalog中；当Agent中根据健康检查的服务状态发生变化时，状态也会通知到Catalog中；当服务或健康检查从Agent中消失后，Catalog中也会移除相对应的信息。Agent负责注册到其上的服务及健康检查，Catalog负责聚合集群各个Agent的数据用于服务发现，Agent同步最新数据到Catalog，各个Agent的数据不断收敛到Catalog，从而实现集群的有序运作
知识点、问题点
服务注册到节点后，其他节点为什么没有同步？
Consul与ZooKeeper、etcd有区别：ZooKeeper利用临时节点的机制，业务服务启动时创建临时节点，节点在服务就在，节点不存在服务就不存在；etcd利用TTL机制，业务服务启动时创建键值对，定时更新ttl，ttl过期则服务不可用。ZooKeeper和etcd的键值存储都是强一致性的，也就是说键值对会自动同步到多个节点，只要在某个节点上存在就可以认为对应的业务服务是可用的。Consul业务服务的可用状态是由注册到的Agent来维护的，Agent如果不能正常工作了，则无法确定服务的真实状态，并且Consul是相当稳定了，Agent挂掉的情况下大概率服务器的状态也可能是不好的，此时屏蔽掉此节点上的服务是合理的。Consul也确实是这样设计的，DNS接口会自动屏蔽挂掉节点上的服务，HTTP API也认为挂掉节点上的服务不是passing的。
鉴于Consul健康检查的这种机制，同时避免单点故障，所有的业务服务应该部署多份，并注册到不同的Consul节点。部署多份可能会给你的设计带来一些挑战，因为调用方同时访问多个服务实例可能会由于会话不共享导致状态不一致，这个有许多成熟的解决方案，可以去查询，这里不做说明。
如果节点挂了健康检查能不能转移到别的节点？
上边提到健康检查是由服务注册到的Agent来处理的，那么如果这个Agent挂掉了，会不会有别的Agent来接管健康检查呢？答案是否定的。
从问题产生的原因来看，在应用于生产环境之前，肯定需要对各种场景进行测试，没有问题才会上线，所以显而易见的问题可以屏蔽掉。
因为分布式系统的状态同步是比较复杂的，同时不要忘了服务部署了多份，挂掉一个不应该影响系统的快速恢复，所以没必要去做这个接管。
能不能直接注册到Server？（是否只有Server节点就够了？）
首先Server的节点数量不是越多越好，3个或者5个是推荐的数量，数量越多数据同步的处理越慢（强一致性）；然后每个节点可以注册的服务数量是有上限的，这个受限于软硬件的处理能力。所以如果你的服务只有10个左右，只有Server问题是不大的，但是这时候有没有必要使用Consul呢？因此正常使用Consul的时候还是要有Client才好，这也符合Consul的反熵设计。
参考文献：
