consul的架构图

consul部署架构.png

每个数据中心可以视为一个地区（北上广），每个数据中心内存在一个LAN Gossip池，它包含数据中心的所有成员——client和server。
LAN池用于以下几个目的：
1、成员关系运行，client自动发现server，减少配置量
2、分布式的故障检测，允许故障检测的工作由整个集群承担，而不是集中在少数server上
3、 Gossip池允许可靠和快速的事件广播，比如leader选举。

多个数据中心根据consul
keygen构成一个集群，一个集群存在唯一一个WAN Gossip池，所有的server都（应）加入 WAN Gossip池，不论是哪个数据中心的。WAN池提供的成员关系，允许server执行跨数据中心请求。

＃一、 consul集群的部署方式
无client模式的consul集群，三个server角色，他们的ip地址分别是192.168.10.16，192.168.10.17，192.168.10.18。
启动命令为：

consul agent -server -ui -config-dir=/etc/consul

三个节点的名称分别为xh-jvm-01t ，xh-jvm-02t ，xh-jvm-03t。
下面以xh-jvm-01t为例，看下启动的配置参数：

[root@xh-jvm-01t ~]# cat /etc/consul/consul.json 
{
  "datacenter": "dc1",
  "addresses" : {
    "http": "192.168.10.16",
    "dns" : "192.168.10.16"
  },
  "bind_addr": "192.168.10.16",
  "node_name": "xh-jvm-01t",
  "rejoin_after_leave": true,
  "domain": "consul",
  "retry_join": [ "192.168.10.16", "192.168.10.17", "192.168.10.18"],
  "server": true,
  "bootstrap_expect": 3,
  "verify_incoming": false,
  "verify_outgoing": false,
  "data_dir": "/opt/consul",
  "disable_remote_exec": false
}

＃二、consul的停止和启动
killall consul
nohup /bin/consul agent -server -ui -config-dir=/etc/consul 2>&1 >/tmp/consul.log &

PS:遇到杀掉consul进程，立马又重新开启了一个consul进程的怪事。
后来发现rc.local里的启动命令是start consul，想要杀掉它，必须stop consul。

三、consul集群的加入和退出

1、查看集群状态：
consul operator raft list-peers

2、退出集群
consul operator raft remove-peer -id=192.168.10.16:8500

3、查看members状态
consul members

Node Address Status Type Build Protocol DC Segment
xh-jvm-01t 192.168.10.16:8500 alive server 1.4.0 2 dc1 <all>
xh-jvm-02t 192.168.10.17:8500 alive server 1.4.0 2 dc1 <default>
xh-jvm-03t 192.168.10.18:8500 alive server 1.4.0 2 dc1 <default>
xh-jvm-04t 192.168.10.19:8500 alive client 1.4.0 2 dc1 <default>

参考：https://blog.csdn.net/chenchong08/article/details/77885989

四、client的作用

1、最普适最简单的方案：

consul集群中的client.png

2、如果你不想在每个主机部署Consul Client，还有一个多路注册的方案可供选择。

consul集群中的client负载均衡.png

这个架构的优势：
Consul节点服务器与应用服务器隔离，互相干扰少；
不用每台主机都部署Consul，方便Consul的集中管理；
某个Consul Client挂掉的情况下，注册到其上的服务仍有机会被访问到；

但也需要注意其缺点：
引入更多技术栈：负载均衡的实现，不仅要考虑Consul Client的负载均衡，还要考虑负载均衡本身的单点问题。
Client的节点数量：单个Client如果注册的服务太多，负载较重，需要有个算法（比如hash一致）合理分配每个Client上的服务数量，以及确定Client的总体数量。
服务发现要过滤掉重复的注册，因为注册到了多个节点会认为是多个部署（DNS接口不会有这个问题）

3、实际部署过程中，在服务节点数量不多的情况下，有些未加入client角色。

不管是client还是server，都是consul集群中的一个节点，在consul中，不存在传统的server管理client这样的概念，它们之间是平等的，client与server具体的区别如下：

Client：这种模式下，所有注册到当前节点的服务会被转发到SERVER，本身是不持久化这些信息。

Server：功能和client都一样，唯一不同的是，它会把所有的信息持久化的本地，这样遇到故障，信息是可以被保留的。

Server-leader：负责同步注册的信息给其它的SERVER，同时也负责各个节点的健康监测

参考：https://blog.csdn.net/j3T9Z7H/article/details/83629334
https://www.zhihu.com/question/68005259

五、spring cloud 结合consul集群

consul节点有多个，导致程序的配置项不固定，需要与具体的机器环境变量一致。
当然，还有一种办法是：在每个虚拟机上安装一个client角色的consul，这样每个spring cloud的配置项
spring:
--application:
----name: assist-service
--cloud:
----consul:
------host: localhost
------port: 8500

1、在机器设置环境变量
export CONFIG_SERVICE_ENABLED=true
export CONFIG_SERVICE_PORT=8500
export CONFIG_SERVICE_HOST=192.168.10.16
export CONFIG_SCHEDULE_ENABLED=true
2、spring cloud配置项