Consul简介及环境搭建
Consul简介
Consul是由HashiCorp基于Go语言开发的支持多数据中心的分布式高可用服务发布和注册软件, 采用Raft算法保持服务的一致性, 且支持健康检查.
和Eureka的侵入式服务中心不同的是, Consul是以独立的软件形式运行, 对项目侵入性小, 更方便部署.
Consul架构
上图为多机房数据中心部署, 每个数据中心至少三台Consul, 一台LEADER, 另外的两台是FOLLOWER.
Consul术语
代理(agent)
代理是Consul集群上每个成员的守护进程, 它是由consul agent命令开始运行. 代理能够以客户端或服务器模式运行. 由于所有节点都必须运行代理, 所以将节点引用为客户端或服务器更为简单, 但还有其他实例的代理. 所有代理可以运行DNS或HTTP接口, 并负责运行检查和保持服务同步.
客户端
客户端可以将所有RPC请求转发到服务器的代理. 客户端是相对无状态的. 客户端执行的唯一后台活动是LANgossip池. 它消耗最小的资源开销和少量的网络带宽.
服务器
服务器端是具有扩展的功能的代理, 它主要参与维护集群状态, 响应RPC查询, 与其他数据中心交换WAN gossip, 以及向leader节点或远程数据中心转发查询.
数据中心
虽然数据中心的定义似乎很明显, 但仍有一些细微的细节必须考虑. 比如说, 在EC2中, 多个可用中心 (EC2和AZ是AWS里的概念, 不了解的话可以去看看AWS文档) 是否应该被认为是一个单个的数据中心呢? 我们将一个数据中心定义为一个私有, 低延迟和高带宽的网络环境, 这不包括通过公共互联网的通信. 但是为了我们的目的, 单个EC2区域内的多个可用区域将被视为单个数据中心的一部分.
一致性
在我们的文档中, "一致性"的意思是对于被选举出的leader以及事物的顺序的认同. 因为这些事件被应用到有限状态机上, 我们对一致性的定义又暗含了复制备份的状态机的一致性.
Gossip
consul是建立在Serf之上的, 它提供了一个完整的gossip协议, 用在很多地方. Serf提供了成员管理, 故障检测和事件广播的功能. Gossip的节点到节点之间的通信使用了UDP协议.
Lan Gossip
指在同一局域网或数据中心的节点上的LAN Gossip池. Client到Server会通过Lan Gossip, 所有的节点都在Gossip pool中
Wan Gossip
指包含服务器的WAN Gossip池, 这些服务器在不同的数据中心, 通过网络进行通信.
Consul使用
devlopment模式
以开发模式启动: consul agent -dev, 如果需要Web界面的话加-ui即可, 集群的LAN服务默认启动在8301端口上, WAN服务默认启动在8302端口上, Web服务默认端口是8500, DNS服务默认端口是8600, gRPC服务默认端口是8502
默认是以server角色启动的, 启动后用consul members可以查看服务下的节点信息, 或者通过HTTP接口请求http://localhost:8500/v1/catalog/nodes也可以看到节点信息数据以json形式返回.
使用dig命令可以查看consul中DNS服务的一些信息, 命令如: dig @127.0.0.1 -p 8600 nodeName
注册服务
一般情况下consul会在启动时通过参数的形式进行配置, 但这样子比较麻烦, 我们通过在/etc/consul.d目录下来新建配置文件的形式, 在每次启动时加载配置文件来进行启动.
consul的配置信息可以在 https://www.consul.io/docs/agent/options.html 查看, 其中部分选项如下:
-advertise: 通知展现地址用来改变我们给集群中的其他节点展现的地址, 一般情况下-bind地址就是展现地址
-bootstrap: 用来控制一个server是否在bootstrap模式, 在一个datacenter中只能有一个server处于bootstrap模式, 当一个server处于bootstrap模式时, 可以自己选举为raft leader.
-bootstrap-expect: 在一个datacenter中期望提供的server节点数目, 当该值提供的时候, consul一直等到达到指定sever数目的时候才会引导整个集群, 该标记不能和bootstrap公用
-bind: 该地址用来在集群内部的通讯, 集群内的所有节点到地址都必须是可达的, 默认是0.0.0.0
-client: consul绑定在哪个client地址上, 这个地址提供HTTP、DNS、RPC等服务, 默认是127.0.0.1
-config-file: 明确的指定要加载哪个配置文件
-config-dir: 配置文件目录, 里面所有以.json结尾的文件都会被加载
-data-dir: 提供一个目录用来存放agent的状态, 所有的agent允许都需要该目录, 该目录必须是稳定的, 系统重启后都继续存在
-dc: 该标记控制agent允许的datacenter的名称, 默认是dc1
-encrypt: 指定secret key, 使consul在通讯时进行加密, key可以通过consul keygen生成, 同一个集群中的节点必须使用相同的key
-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.
-node: 节点在集群中的名称, 在一个集群中必须是唯一的, 默认是该节点的主机名
-protocol: consul使用的协议版本
-rejoin: 使consul忽略先前的离开, 在再次启动后仍旧尝试加入集群中.
-server: 定义agent运行在server模式, 每个集群至少有一个server, 建议每个集群的server不要超过5个
-syslog: 开启系统日志功能, 只在linux/osx上生效
-pid-file: 提供一个路径来存放pid文件, 可以使用该文件进行SIGINT/SIGHUP(关闭/更新)agent
按照惯例, 我们将配置文件放在/etc/consul.d/目录下, 分别在几个机器上创建该目录. 在以bootstrap模式启动的server1上, 我们创建/etc/consul.d/bootstrap和/etc/consul.d/server目录, 在server2和server3上我们创建/etc/consul.d/server目录, 在agent上, 我们创建/etc/consul.d/agent目录.
server1的bootstrap目录下的配置文件config.json如下:
{
"bootstrap": true,
"server": true,
"datacenter": "sh",
"data_dir": "/tmp/consul",
"advertise_addr":"192.168.11.11",
"encrypt": "aHN+s49W3Qyr73tjCayjCw==",
"log_level": "INFO",
"enable_syslog": true
}
其他两台服务器中server目录下的配置文件config.json如下:
{
"bootstrap": false,
"server": true,
"datacenter": "sh",
"data_dir": "/tmp/consul",
"advertise_addr":"192.168.33.10",
"encrypt": "aHN+s49W3Qyr73tjCayjCw==",
"log_level": "INFO",
"enable_syslog": true,
"start_join": ["192.168.33.33","10.29.34.216","192.168.11.11"]
}
代理服务器中agent目录下的config.json如下:
{
"server": true,
"datacenter": "sh",
"data_dir": "/tmp/consul",
"ui" : true,
"encrypt": "aHN+s49W3Qyr73tjCayjCw==",
"log_level": "INFO",
"advertise_addr":"10.29.34.216",
"addresses": {
"http": "0.0.0.0"
},
"enable_syslog": true
}
这样, 首先启动server1上的consul: consul agent -config-dir /etc/consul.d/bootstrap, 然后依次启动server2, server3上的consul:consul agent -config-dir /etc/consul.d/server. 这样, 三个consul server就组成了一个cluster. 此时server1上的consul运行在bootstrap状态下. 可以在不与server2以及server3商议的情况下直接执行决议, 此时我们终结server1上运行的consul, 并执行consul agent -config-dir /etc/consul.d/server, 让server1以普通server的身份重新加入cluster. 最后启动agent模式 consul agent -config-dir /etc/consul.d/agent.
** 注意: encrypt可以使用consul keygen命令来生成, 所有服务器上需要配置一样, 如果因为哪里配置错误导致启动失败, 修改后还报失败的话, 可以尝试删除$data_dir/serf/local.keyring后重新启动 **
发现服务
在需要部署服务的机器上同样创建/etc/consul.d/, 然后把不同的服务分开不同的目录, 或者就直接在此目录下创建json配置文件, 如: web1.json, web2.json等.
然后再通过consul agent指定配置文件的方式启动服务, 可以直接在配置文件中指定要注册的服务, 也可以在启动后使用consul join命令来主动注册服务, 这样再次登录到web管理界面就可以发现我们新建的服务了.
Q&A
Q: 什么是bootstrap模式?
A: 使用该模式启动的server端会自动把自己选择为leader, 在搭建集群时为了方便会预先设置一台服务器为bootstrap启动
