Consul简介及环境搭建

Posted 2023-02-25

参考技术A Consul是由HashiCorp基于Go语言开发的支持多数据中心的分布式高可用服务发布和注册软件, 采用Raft算法保持服务的一致性, 且支持健康检查.
和Eureka的侵入式服务中心不同的是, Consul是以独立的软件形式运行, 对项目侵入性小, 更方便部署.

上图为多机房数据中心部署, 每个数据中心至少三台Consul, 一台LEADER, 另外的两台是FOLLOWER.

代理是Consul集群上每个成员的守护进程, 它是由consul agent命令开始运行. 代理能够以客户端或服务器模式运行. 由于所有节点都必须运行代理, 所以将节点引用为客户端或服务器更为简单, 但还有其他实例的代理. 所有代理可以运行DNS或HTTP接口, 并负责运行检查和保持服务同步.

客户端可以将所有RPC请求转发到服务器的代理. 客户端是相对无状态的. 客户端执行的唯一后台活动是LANgossip池. 它消耗最小的资源开销和少量的网络带宽.

服务器端是具有扩展的功能的代理, 它主要参与维护集群状态, 响应RPC查询, 与其他数据中心交换WAN gossip, 以及向leader节点或远程数据中心转发查询.

虽然数据中心的定义似乎很明显, 但仍有一些细微的细节必须考虑. 比如说, 在EC2中, 多个可用中心 (EC2和AZ是AWS里的概念, 不了解的话可以去看看AWS文档) 是否应该被认为是一个单个的数据中心呢? 我们将一个数据中心定义为一个私有, 低延迟和高带宽的网络环境, 这不包括通过公共互联网的通信. 但是为了我们的目的, 单个EC2区域内的多个可用区域将被视为单个数据中心的一部分.

在我们的文档中, "一致性"的意思是对于被选举出的leader以及事物的顺序的认同. 因为这些事件被应用到有限状态机上, 我们对一致性的定义又暗含了复制备份的状态机的一致性.

consul是建立在Serf之上的, 它提供了一个完整的gossip协议, 用在很多地方. Serf提供了成员管理, 故障检测和事件广播的功能. Gossip的节点到节点之间的通信使用了UDP协议.

指在同一局域网或数据中心的节点上的LAN Gossip池. Client到Server会通过Lan Gossip, 所有的节点都在Gossip pool中

指包含服务器的WAN Gossip池, 这些服务器在不同的数据中心, 通过网络进行通信.

以开发模式启动: 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 查看, 其中部分选项如下:

按照惯例, 我们将配置文件放在/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如下:

其他两台服务器中server目录下的配置文件config.json如下:

代理服务器中agent目录下的config.json如下:

这样, 首先启动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: 什么是bootstrap模式?

A: 使用该模式启动的server端会自动把自己选择为leader, 在搭建集群时为了方便会预先设置一台服务器为bootstrap启动