consul线上安装和权限配置

安装路径：

/home/cube/consul

配置文件 （/home/cube/consul/config/config.json） ：

启动脚本：

注：server关闭一个节点，然后马上加入一个节点，至少保证有两个节点以上才行，当server低于两个的时候，整个注册服务会丢失数据，并且服务处于不可用状态。

关闭脚本最好不要kill进程，执行 consul leave 优雅关服务。

consul权限配置有个专门的acl模块，有一套比较强大的权限控制规则。

1 .在 /home/cube/consul/config/ 新建 acl_config.json 文件，server三个服务器都需要新建，文件内容为：

然后重新加载配置 ./consul reload

2 .生成token,这里生成的token需要依赖上面的acl_master_token子密钥。随机选一台服务器执行：

结果返回一个token

3 .配置生成的token ，后面的验证都是基于这个token来验证的，只是第一次生成token稍微麻烦点，以后的token管理可以在consul manager上管理。

在所有的server端的acl_config.json加上刚刚生成的token,新的acl_config.json为：

4 . 上面只是生成server端的token, 现在需要配置client端的token, 将上面的http请求的type类型改为client,然后重新生成token。

将生成的token，配置在我们的client端的acl_config.json:

5 . 可以关闭server端的8500端口，开发client端的8500端口。

6 . 访问 consul界面浏览器输入 http://114.112.101.159:8500/ui 会提示 Access Denied ,也就是没有权限访问，在设置界面输入上面的server端token，就能访问。

7 . 程序同样需要配置token才能进行服务的注册与发现。

当需要对某个服务进行详细的权限控制的时候，我们可以在界面的acl模块，详细配置某个数据中心的访问控制，以及路径下数据的详细控制。目前我们的业务还没有这样的复杂需求，暂时没有详细配置访问控制。

详细配置规则，参考： https://www.consul.io/docs/guides/acl.html#rule-specification

consul是google开源的一个使用go语言开发的服务发现、配置管理中心服务。内置了服务注册与发现框架（类似zookeeper）、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案。服务部署简单，只有一个可运行的二进制的包。每个节点都需要运行agent，他有两种运行模式server和client。每个节点为以下三种状态的一种：

上图来源于 Consul 官网，很好的解释了 Consul 的工作原理。consul是一个服务管理软件，主要功能如下：

有些人可能对服务注册和发现还没有概念，有些人可能使用过其他服务发现的工具，比如 ZooKeeper，etcd，会有一些先入为主的经验。本文谈一下 Consul 做服务发现的实践和原理。

下面这张图描述了服务发现的完整流程，先大致看一下：

首先需要有一个正常的 Consul 集群，有 Server，有 Leader。这里在服务器 Server1、Server2、Server3 上分别部署了 Consul Server。

假设他们选举了 Server2 上的 Consul Server 节点为 Leader。这些服务器上最好只部署 Consul 程序，以尽量维护 Consul Server 的稳定。

然后在服务器 Server4 和 Server5 上通过 Consul Client 分别注册 Service A、B、C，这里每个 Service 分别部署在了两个服务器上，这样可以避免 Service 的单点问题。

服务注册到 Consul 可以通过 HTTP API（8500 端口）的方式，也可以通过 Consul 配置文件的方式。

Consul Client 可以认为是无状态的，它将注册信息通过 RPC 转发到 Consul Server，服务信息保存在 Server 的各个节点中，并且通过 Raft 实现了强一致性。

最后在服务器 Server6 中 Program D 需要访问 Service B，这时候 Program D 首先访问本机 Consul Client 提供的 HTTP API，本机 Client 会将请求转发到 Consul Server。

Consul Server 查询到 Service B 当前的信息返回，最终 Program D 拿到了 Service B 的所有部署的 IP 和端口，然后就可以选择 Service B 的其中一个部署并向其发起请求了。

如果服务发现采用的是 DNS 方式，则 Program D 中直接使用 Service B 的服务发现域名，域名解析请求首先到达本机 DNS 代理，然后转发到本机 Consul Client，本机 Client 会将请求转发到 Consul Server。

Consul Server 查询到 Service B 当前的信息返回，最终 Program D 拿到了 Service B 的某个部署的 IP 和端口。

图中描述的部署架构笔者认为是最普适最简单的方案，从某些默认配置或设计上看也是官方希望使用者采用的方案，比如 8500 端口默认监听 127.0.0.1，当然有些同学不赞同，后边会提到其他方案。

consul必须启动agent才能使用，有两种启动模式server和client，还有一个官方自带的web ui。server用与持久化服务信息，集群官方建议3或5个节点。client只用与于server交互。ui可以查看集群情况的。

server模式启动如下：

参数解释：

client启动如下：

client节点可以有多个，自己根据服务指定即可。

ui启动如下:

参数解释：

集群创建完成后：

使用一些常用的命令检查集群的状态：

可以在raft：stat看到此节点的状态是Fllower或者leader

新加入一个节点有几种方式；

访问ui：

http://192.168.1.198:8500/ui

端口：

8300：consul agent服务relplaction、rpc（client-server）

8301：lan gossip

8302：wan gossip

8500：http api端口

8600：DNS服务端口

输入 consul agent -dev

在浏览器中输入 www.localhost:8500 就可以启动web查看

consul注册服务，有三种方式，

方式一：通过配置文件的方式静态注册

创建文件夹/etc/consul.d

.d代表有许多配置文件在里面

vim /etc/consul.d/jetty.json 内容如下：

重启consul，并将配置文件的路径给consul（指定参数：-config-dir /etc/consul.d）

方式二：通过HTTP API接口来动态注册

直接调用/v1/agent/service/register接口注册即可，需要注意的是：http method为PUT提交方式。如：

注意，这种方式，和上面的注册方式有一点不一样，body的参数，是上面service的值，这点需要注意

方式三：使用程序实现服务的注册和发现（Java）

首先加入consul client的依赖

服务发现

consul支持两种方式实现服务发现，一种是通过http API来查询有哪些服务，另外一种是通过consul agent 自带的DNS（8600端口），域名是以NAME.service.consul的形式给出，NAME即在定义的服务配置文件中，服务的名称。DNS方式可以通过check的方式检查服务。

服务间的通信协议

Consul使用gossip协议管理成员关系、广播消息到整个集群，他有两个gossip pool（LAN pool和WAN pool），LAN pool是同一个数据中心内部通信的，WAN pool是多个数据中心通信的，LAN pool有多个，WAN pool只有一个。

https://www.toutiao.com/a6639493728086000142/?tt_from=weixin&utm_campaign=client_share&wxshare_count=1&timestamp=1546144777&app=news_article&utm_source=weixin&iid=55667270026&utm_medium=toutiao_android&group_id=6639493728086000142

如何用Consul打造d性可扩展的PaaS平台

杜威，程序员，混迹互联网研发和运维近十年。《Linux系统案例精解》合著者之一。目前就职亮风台，专注DevOps、云计算、大数据等相关领域。

应用背景

HiAR 是亮风台打造的新一代增强现实(AR)开发平台，提供简单易用、功能强大、跨平台的 AR 服务。让广大开发者可以轻松使用最前沿的计算机视觉技术、计算机图形学技术，快速搭建个性化的 AR 应用。

云服务是HiAR平台中重要的基础设施。无论从高可用，还是到可扩展，服务发现都发挥着不可或缺的作用。在没有使用服务发现之前，我们遇到的几个痛点：

◆ 系统添加一个服务节点，我们需要手工修改Nginx/LVS的配置文件、修改DNS记录。

◆ 应用服务发布新版本，我们还是需要手工修改Nginx的配置文件把节点下线、等待发布成功后，再次修改Nginx的配置文件把服务上线。

◆ 尽管后来我们对上面两种场景的运维做了改进，编写脚本把过程改良为半自动半手动的方式，但还不是很方便，而结合服务注册就可以做到全自动。

◆ 内网DNS出了故障，我们需要对DNS服务进行维护。

◆ 没有服务注册，限制了Docker的发挥，只能当轻量级虚拟机来用。

现在，有了服务发现，一切都变得简单有趣。增减服务节点可以自动更新Nginx/LVS的配置文件；DNS丢一边吧！用IP就好；接入Mesos+Docker玩d性扩展。

为什么选择 Consul

已经有很多文章对Zookeeper、etcd、Consul进行比较，这里就不重复类比了。没有什么比合适更重要！Consul 的运维成本低，部署简单、使用方便、五脏俱全，这对于中小型团队应该是性价比很高的。

在进入实战前，先看看 Consul 都有哪些特性。

◆ 服务注册。通过HTTP API或DNS，告诉服务注册中心有新的服务加入。

◆ 服务发现。通过HTTP API或DNS，可以知道目标服务的地址和端口。

◆ 健康检查。支持多种方式，HTTP、TCP、Docker、Shell脚本定制化监控。

◆ 配置模板。Consul Template 负责定期从服务注册中心获取信息，如果有变化自动更新配置文件并重新加载。

以上四点已经能满足很多企业的需求。当然这不是Consul的所有，Consul还有很多锦上添花的特性，比如：可视化Web界面、支持多数据中心。

实战经验

我们对Consul的使用可以归纳到四个方面：部署、应用、管理、升级。

部署

Consul Cluster有Server和Client两种角色。Server一般是3~5台，这也是官方推荐的。Consul Client就是需要进行服务注册或服务发现的节点。

Consul的部署简单、开箱即用，一个consul可执行文件，还没有乱七八糟的依赖。在官网下载编译好的Consul agent可执行文件，并上传到所有Server和Client角色的节点，便随时可启动consul agent了。

下面一起来看看，如何启动一个Consul集群(3台Server、1台Client)。

实验环境：

server01 192.168.1.11

server02 192.168.1.12

server03 192.168.1.13

client01 192.168.1.21

分别登录Server01、Server02、Server03，并启动agent。

[worker@server01 ~]$ consul agent -server -bootstrap-expect 2 -data-dir /tmp/consul -bind=192.168.1.11 -node=server01

[worker@server02 ~]$ consul agent -server -bootstrap-expect 2 -data-dir /tmp/consul -bind=192.168.1.12 -node=server02

[worker@server03 ~]$ consul agent -server -bootstrap-expect 2 -data-dir /tmp/consul -bind=192.168.1.13 -node=server03

新开窗口登录Server03，加入Server01、Server02的集群。

[worker@server03 ~]$ consul join 192.168.1.11 192.168.1.12

上面几步就完成了初始化Server节点，以后通过-rejoin参数启动，可以重新加入集群。

[worker@server01 ~]$ consul agent -server -bootstrap-expect 2 -data-dir /tmp/consul -bind=192.168.1.11 -node=server01 -rejoin

[worker@server02 ~]$ consul agent -server -bootstrap-expect 2 -data-dir /tmp/consul -bind=192.168.1.12 -node=server02 -rejoin

[worker@server03 ~]$ consul agent -server -bootstrap-expect 2 -data-dir /tmp/consul -bind=192.168.1.13 -node=server03 -rejoin

就这样三个Server节点部署完毕。接下来，部署Client节点，和Server节点一样，有初次启动、手工加入和重新加入集群三步。

[worker@client01 ~]$ consul agent -data-dir /tmp/consul -bind=192.168.1.21 -node=client01

还是在Client01上，新开一个登录窗口，加入Server01的集群。

[worker@client01 ~]$ consul join 192.168.1.11

Client01节点日后的维护，通过-rejoin参数启动，便可重新加入集群。

[worker@client01 ~]$ consul agent -data-dir /tmp/consul -bind=192.168.1.21 -node=client01 -rejoin

到这里为止，我们已经搭建好了一个Consul集群。然而，怎么进行服务注册和服务发现呢?这得跟实际需求紧密结合，在接下来的小节中进一步说明。

应用

Consul不是单独存在的。为了充分发挥Consul的优势，可以结合Nginx、LVS、Docker等工具来应用。

Nginx、LVS是系统的基础组件，RecoService、FeatureService、SearchService是基于SOA的内部服务。前者向Consul集群发现服务，后者向Consul集群注册服务。Consul是粘合剂也是开关，让整个系统的运作起来，低成本的实现了d性伸缩。

接入层，用的是Nginx，负责反向代理和负载均衡。Nginx节点上跑两个Consul相关服务。一个是Consul Agent，做Consul Client；另外一个是Consul Template，做服务发现和配置更新。Consul Template负责定期查询本地Consul Agent，如果相关服务的注册信息有变化，则更新Nginx的配置文件并重新加载Nginx服务。

运行Consul Template是实现d性扩展的关键步骤：

$ consul-template -consul 127.0.0.1:8500 -template "/etc/nginx/conf/vhosts/test.ctmpl:/etc/nginx/conf/vhosts/test.conf:nginx -s reload"

上面这句命令中，test.conf是Nginx的虚拟主机配置文件，test.ctmpl是该配置文件对应的模板。下面是模板在负载均衡上的代码片段：

upstream test-cluster {

ip_hash{{range service "test"}}

server {{.Address}}:{{.Port}}{{end}}

}

逻辑层，基于SOA的内部服务集群。不同的内部服务集群之间通信需要做服务发现，这里引入LVS做服务发现。好处是不用在内部服务的代码里实现服务发现，而且规模大了还要做负载均衡。与接入层的Nginx类似，LVS也用Consul Template定期查询本地Consul Agent，更新相关配置文件，然后重载服务。

内部服务如何向服务中心注册?有两种方式，一是通过Consul的服务注册HTTP API，由服务自身在启动后调用API注册自己，二是通过在配置文件中定义服务的方式进行注册。建议使用后面一种方式来做服务注册。怎么办到的?请继续往下看 ：)

为项目添加一个配置文件consul.json，指定服务名称和服务端口，并加上健康检查，内容如下：

{

"service":

{

"name" : "test",

"port" : 9999,

"check":

{

"tcp": "127.0.0.1:9999",

"interval": "10s"

}

}

}

最后一步，对服务进行注册，需要在Consul agent启动时指定配置文件，如下：

$ consul agent -data-dir /tmp/consul -node=test -bind=192.168.1.21 -config-dir=/tmp/consul.json

管理

一是节点管理，也就是Consul进程的管理。由于Consul Agent本身不具备高可用能力，所以我们有必要对Consul进程进行接管，我们用的是Systemd，你也可以选择Supervisord或者Upstart这些进程管理工具。

二是集群管理，Consul提供了可视化管理界面。可以查看所有的服务和节点，以及它们的健康检测和当前状态。

升级

由于Consul关系到整个系统的正常运作，所以升级的时候还是要很小心。最好在测试环境试验多几次，再到生产环境升级。升级的状况可以归纳为下面三种，需要对号入座之后再进行升级。

◆ 特殊版本的升级。在upgrade-specific页面查看当前升级的版本是否有特殊说明。比如：0.5.1之前的版本直接升级到0.6版本，要借助工具consul-migrate进行数据迁移。

◆ 不兼容的升级。使用consul -v查看新版的向后兼容协议版本号，当出现与当前版本不兼容时，需要分两步升级。先通过参数-protocal=旧的协议版本号，把整个集群升级一次，再把启动命令中的参数-protocal去掉来重启所有节点。

◆ 标准的升级。如果上面两种情况都不是，那么恭喜你，你需要做的只是简单的标准升级。即：停止旧版本的agent，然后启动新版本的agent。PS：其实大多数情况都是标准升级。

升级节点的推荐顺序是，先升级Server的Follower节点，再升级Server的Leader节点，最后升级所有Client的节点。

结语

在系统中引入服务注册和发现，虽然是一发牵动全身的改造，但整个系统架构会因此受益，尤其是现代的微服务架构。相信很多系统都具备负载均衡、健康检查、心跳检测等能力，利用好服务发现，那么d性伸缩、服务高可用、灰度发布，自然是水到渠成的事情。

---