分布式@架构师

Consul系列:让服务Running in anywhere

2023-04-15  本文已影响0人  1分贝

引言

随着微服务概念深入人心，越来越多的解决方案选择使用微服务架构，这类架构的共同点是服务数量多，因此种类繁多的服务之间如何互相访问就变成了一个很现实的问 题。目前比较流行的分布式存储比如:Consul, etcd, ZooKeeper，如何结合当前的业务场景，利用这些工具实现更加自动化的运维化方案、简化我们的流程呢?本文主要 给大家介绍在服务发现和配置管理方面的consul工具，同时也会为大家带来一些应用场景案例参考。

关于服务发现及Consul

将应用部署到集群时，服务IP或端口是动态分配的，用户访问时不知道后端的IP及端口，在访问这些服务时，使用一定的机制动态发现服务的IP及端口就是服务发现(ServiceDiscovery)。

Consul是一个服务发现和配置管理的工具，是具有分布式、高可用、高度可扩展的服务。

Consul的特性

节点

架构

image.png

Consul vs. Other Software

image.png

Consul部署

可以参考Consul系列:Consul Server部署及用法介绍.

集群运行

Consul可以运行client和server 两种节点模式，每个数据中心必须有一个server节点，但如果高可用，需要部署3个以上。其它Consul全部运行在client模式。客户端连接 会有一个非常轻的注册过程，运行健康检查并发给server节点。

#supervisor管理consul服务启动
[program:consul]
command=/usr/local/bin/consul agent -config-dir /home/项目用户/consul/conf -data-dir /home/项目用户/consul/data process_name=%(program_name)s
user=项目用户
numprocs=1
autostart=true
autorestart=true
startsecs=2
startretries=3
redirect_stderr=true
stdout_logfile_backups=10
stdout_logfile_maxbytes=300MB stdout_logfile=/home/项目用户/var/log/supervisor/s_%(program_name)s.log
#默认加载的config.json配置 {
"acl_token":"你的acl token", "bootstrap_expect":1, "client_addr":"0.0.0.0", "datacenter":"dc名称，一个数据中心统一使用一个", "enable_debug":false, "enable_syslog":false,
"log_level":"INFO", "node_name":"这里定义consul节点名称，通常建议hostname比较容易区分",, "raft_protocol":3,
"rejoin_after_leave":true,
"retry_interval":"3s", "retry_join":["server节点地址1","server节点地址2","....."], "server":true,
"ui":true
}

#supervisor管理consul服务启动
[program:consul]
command=/usr/local/bin/consul agent -config-dir /home/项目用户/consul/conf -data-dir /home/项目用户/consul/data process_name=%(program_name)s
user=项目用户
numprocs=1
autostart=true
autorestart=true
startsecs=2
startretries=3
redirect_stderr=true
stdout_logfile_backups=10
stdout_logfile_maxbytes=300MB
stdout_logfile=/home/项目用户/var/log/supervisor/s_%(program_name)s.log
#默认加载的config.json配置 {
"acl_token":"你的acl token", "bootstrap_expect":0, "client_addr":"0.0.0.0", "datacenter":"dc名称，一个数据中心统一使用一个", "enable_debug":false, "enable_syslog":false,
"log_level":"INFO", "node_name":"这里定义consul节点名称，通常建议hostname比较容易区分",, "raft_protocol":3,
"rejoin_after_leave":true,
"retry_interval":"3s", "retry_join":["server节点地址1","server节点地址2","....."], "server":false,
"ui":false
}

注册服务健康检查到Consul

Consul服务定义

Consul中的服务一种是可以在启动前就定义 ，提前写好定义服务的配置文件放置到 Consul配置的-config-dir指定目录中, 如果这种方式需要更新，需要使用重载命令 consul reload。另外一种是Consul api的方式来注册服务。注册服务的信息主要包含id, name, port, address, check每个服务可以由多个ip或者可以有多个端口的服务组 成。需要注意的是:每个服务可以有多个check，check可以是端口检查、http检查、脚本检查。其中检查脚本通常是自由做任何事情，以确定检查的状态。唯一的限制 是，该退出代码都必须遵守此约定:

注册服务通常是通过agent来注册，因为服务的健康检查与所在Consul agent是绑定的，如果 Consul agent所在宿主机挂掉，就认为这台主机上的服务也是挂的。

注册服务及健康检查

{
    "service": {
        "name": "test",
        "tags": ["test service"],
        "port": 31030,
        "address": "10.10.169.72",
        "id": "test",
        "check": {
            "id": "api",
            "http": "http://10.10.169.72:31030",
            "interval": "3s"
        }
    }
}

# cat http.json 
{
    "service": {
        "name": "web",
        "tags": ["test web site"],
        "port": 8099,
        "check": {
            "id": "web",
            "name": "web on port 8099",
            "tcp": "localhost:8099",
            "interval": "10s",
            "timeout": "1s"
        }
    }
}

注意:

服务发现

Consul启动后，并且服务集群状态正常，就可以对外提供DNS或者HTTP API来查询服务了。

http api

Consul dns服务发现

Consul自带一套dns 服务，所以可以处理简单的服务发现。通过dig命令查询Consul dns中的服务解析, critical的服务不会解析。

案例分享

haproxy配合Consul dns实现服务发现

haproxy做为PaaS平台服务的负载均衡服务，对外服务;配置backend服务时，配置的是Consul中的服务域名。

这里有个坑，原来使用haproxy 1.5版本, 后端服务使用域名时，启动后只解析一次(和nginx类似)，这时如果解析到的服务挂掉，访问haproxy页面时会503。查询官网得知haproxy 1.6支持了动态dns 域名解析的配置，后升级为haproxy 1.6。

下面是动态DNS解析相关的配置内容:

resolvers consuldns
  nameserver dns1 127.0.0.1:53 
  resolve_retries 200 
  timeout retry 1s 
  hold valid 10s
frontend uq
  balance leastconn
  cookie JSESSIONID prefix
  bind 0.0.0.0:10000 accept-proxy 
  capture request header Host len 128 
  option httplog
  log-format %si:%sp\ %ci\ %ft\ %hrl\%r\ %ST\ %B\ %Tt 

  # 自定义ACL(路由)策略
acl host_uq-xyteam hdr_dom(host) -i test.x.example.com
use_backend test if host_test

#自定义转发的realserver地址
backend test
  server test test.service.consul:10000 resolvers mydns maxconn 50000 check inter 2000 rise 2 fall 100

用户访问haproxy就会动态解析访问后端Consul中的服务。

基于Consul dns，实现推送服务的高可用切换

推送的unipush服务最初是基于常见的haproxy来做高可用的及入口的统一。为了减轻架构复杂度和更加的自动化，实现自动的阔缩容，通过将推送服务注册到Consul来做健康检查，并且去掉haproxy使用consul dns作为轻量级的代理。配置如下:

# cat service.json
{
    "service": {
        "name": "test_recv",
        "port": 30121,
        "check": {
            "id": "up",
            "name": "up on port 30121",
            "tcp": "42.186.52.150:30121",
            "interval": "60s",
            "timeout": "30s"
        }
    }
}

正常情况该域名会解析到所有的test服务地址，如果一旦发生个别服务异常、节点故障等情况，dns会立即将故障服务节点踢出解析。

root@localhost:~$ dig @127.0.0.1 -p 53 test_recv.service.consul
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @127.0.0.1 -p 53 test_recv.service.consul ; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16206
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION: 
;test_recv.service.consul. IN A

;; ANSWER SECTION:
test_recv.service.consul. 0 IN A 10.192.4.163 
test_recv.service.consul. 0 IN A 10.192.4.150 
test_recv.service.consul. 0 IN A 10.192.4.240

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) 
;; WHEN: Sat Nov 17 12:20:29 2018 
;; MSG SIZE rcvd: 93

基于Consul template，实现服务配置文件动态渲染

日常运维中由于各种情况，我们少不了会对各类服务的配置文件进行变更。例如服务迁移、增加配置参数项等。利用consul，我们可以使用K/V、services等等集群内的数据信息渲染我们的配置文件内容。 实时监听unipush_recv这个service的变化，一旦出现变化，立即触发渲染,例如新增、故障等等。

实时监听unipush_recv这个service的变化，一旦出现变化，立即触发渲染,例如新增、故障等等。

{{range service "unipush_recv"}}   server {{.Node}} {{.Address}}:{{.Port}} maxconn 50000 check inter 2s addr {{.Address}} port {{.Port}}{{end}}
listen niepush_4
....

渲染后的内容，会将定义的变量用对应的service信息进行填充。

server test-up02 10.192.4.240:30121 maxconn 50000 check inter 2s addr 10.192.4.240 port 30121 
server test-up04 10.192.4.150:30121 maxconn 50000 check inter 2s addr 10.192.4.150 port 30121 
server test-up06 10.192.4.147:30121 maxconn 50000 check inter 2s addr 10.192.4.147 port 30121
......

最后在渲染后指定后续的处理逻辑:reload重载。

[program:consul-template]
command=/usr/local/bin/consul-template -consul-addr 127.0.0.1:8500 -template "/home/test/haproxy/conf/test_recv.ctmpl:/home/test/haproxy/conf/test_recv.conf:haproxy reload"
process_name=%(program_name)s
user=test
numprocs=1
autostart=true
autorestart=true
startsecs=2
startretries=3
redirect_stderr=true
stdout_logfile_backups=10
stdout_logfile_maxbytes=300MB
stdout_logfile=/home/test/var/log/supervisor/s_%(program_name)s.log stderr_logfile=/home/test/var/log/supervisor/s_%(program_name)s.log

同样不仅限于service，包括例如可以使用K/V的渲染，利用WEB UI界面可修改的K/V的特性,提供产品同学自助的文件变更&服务更新生效的功能。根据不同的场景、利用 consul的watch、template、check、service等功能组合出业务更加自动化的运维方案。

Consul监控

Consul开放了API可以直接获取Consul集群性能数据，可以脚本化拿到后进行渲染，效果如下：


image.png

Consul告警

Consul的服务相关问题都会有日志记录，所有重要的一点就是做日志监控，并且将日志中的error信息进行告警，效果如下：


image.png

访问安全控制

WEB UI

web ui一般采用apache+web ui的模式，从apache这里设置用户密码认证&ssl证书，再转发到一个web ui接口，这个web ui接口进行白名单限制。


image.png

API

采用防火墙限制端口(8300/8301/8302)处理.

Consul实践遇到的坑

调用deregistry接口删除Consul服务后，诡异的出现了

初期进行http api 调试测试时，注册了一些服务到Consul, 后来想删除就调用，ip:8500/v1/catalog/deregister 接口进行删除，调用该接口返回成功。但过一会儿去web ui查询， 发现刚才删除的服务还在，后来查询官方文档，原来server端catalog和 agent端都有deregister接口，我们的服务都是通过agent注册的，所以在catalog 删除不 生效，只能通过agent的 deregistry接口来删除。

总的来说目前已经尝试的有两种解决方案:

清理Consul持久化数据异常

测试Consul server服务的高可用，先停止其中一台Consul server节点的容器，并清理Consul 的持久化数据，其它服务的Consul节点正常，达到预期结果，后来尝试恢复 这个Consul server,恢复后发现从Consul ui查发现 少了一些服务节点，查询过后，正好是清理数据的这台Consul server上的服务在 Consul 中消失了，因此又重新在这个 节点进行相应的服务注册才真正恢复正常。

健康检查状态码的坑

健康检查脚本中使用grep检查结果内容，如果匹配则正常，不匹配为异常，例如: echo result|grep ok,有一次，一个服务节点异常，grep也没有匹配，当时认为这样就不 会被解析了，后来发现这个服务ip还是会被解析，查询问题发现grep 不匹配的error code 为1 ，code 1 只是warning ,还是会被解析，所以修改检查脚本内容，如果不匹 配，手动返回error code 2,之后这个异常服务才不解析。

使用registrator自动注册的坑

推送服务这边通常注册时候，为了和cmdb信息统一，registrator 默认的注册规则是服务名注册为 Consul中的service id。service和check id如果是不同的端口服务，不 能一样，否则在Consul同一个节点上就有可能同一个服务被注册多次，实际上是同 个服务不同实例，影响例如服务未注册上，检查的是其它进程端口等。不同的节点上的 service id或check id可以相同，同一台节点上的service的id不能一样，统一check之间的id也不能一样。

同一个节点设置为相同的id:


image.png

同一个节点设置为不同的id:


image.png

Consul agent节点异常

部署客户环境时遇到一个诡异的问题，有两个节点总是异常，健康检查这两个节点时好时坏，大部分时间是坏的，少部分时间显示正常状态。

排查问题时，发现主机之间响应时间很快，Consul server 与Consul agnet 之间的Consul端口都是可以通的。查询Consul server日志，看到 server 日志中有error:


image.png

以为是有端口漏开放了，telnet 测试后，发现Consul server到agent都是通的，谷歌下这个错误，发现有可能是因为没有开通udp端口导致的，后来又使用nmap测试 Consul相关的udp端口是不是开放的，测试后发现udp 果然没有开通。于是就向客户申请开通相应的udp端口，开通后，再进行测试，发现问题还是存在。

这就不得不再想其它办法，后来又查询异常的Consul agent节点日志发现，发现Consul agent 也报类似的错误,乍一看跟server端的日志是一样的，但仔细研究发现关键问 题，异常节点的agent报了很多访问其它agent节点8301端口的 time out的日志:


image.png

才发现agent不仅访问server, 还需要访问同级的其它agent 8301端口进行健康检查，后来开放8301所有Consul节点的端口访问后才正常。

比起另外两个同样流行的分布式存储etcd和ZooKeeper, Consul从设计上就考虑到了很多服务发现的需求, 比如说健康检查, 服务注册, DNS等。所以基于Consul来实现服
务发现的功能还是有很多的想象空间的。

更多思考

Q1:Consul, etcd, ZooKeeper能比较一下吗?为什么没有选用后两者呢?

A1:ZooKeeper 处理数据 不支持 resf api , 需要操作的时候比较繁琐，功能也比较单一，etcd 服务功能也相对单一，需要依赖其它 组件 配合使用Consul 本身自

Q2:就服务发现和zk相比，会有多大的延迟?

A2: 就服务发现来说，Consul 支持 api 和 dns 两个方式获取 服务， dns 解析基本无消耗。 api 操作的话，具体的数据我没有进行严格测试，但zk是java服务本身 需要的内存比较多，java gc 垃圾回收也会影响一些性能。Consul 是go 语言开发性能会有一些优势。

Q3: 这里问一个不是很相关的问题，怎么看待Docker和微服务更配这样的说法?

A3: 以前是所有功能集成到一个服务中，微服务本身需要拆分服务，需要部署、更新、维护的服务数量会几何增加，如果是传统的方式运维的话，操作起来就是个挑
战，Docker化之后，部署、迁移、交付都会变简单。

Q4:Consul最大承受多大规模，有瓶颈吗?

A4: 我没有针对 Consul服务 做过压力测试，我们一般是会对服务进行压力测试，就现在我们部署的集群规模而言，支持几百来的Consul 节点是没有问题的。理论 上可以更多。

Q5:内部的web服务怎么注册?用后台脚本周期性地检测web服务正常后，再请求接口注册服务吗?失败取消

A5: 如果 使用了 registrator ，docker服务启动时，添加相应的环境变量，就会自动注册到Consul，也会自动删除，不过registrator偶尔异常情况会有不同步的现 象，我们在 registrator 启动时添加同步参数定时同步,如果没有使用 registrator ，就需要自己处理注册和删除的逻辑，例如我们使用marathon /mesos 做为调试 的核心基础组件，可以监听marathon 的事件获取 容器实例 启动在哪，删除了哪些，就可以相应对 Consul做操作Consul 也支持异常服务定时清理，在注册添加时 添加DeregisterCriticalServiceAfter 参数 就可以

Q6:“每个数据中心必须有一个server节点，但如果高可用，需要部署3个以上”为啥一定要三个以上

A6: Consul server 节点也分为 leader 和 follower 节点，leader 选举一般为基数选举，1个就不是高可用了，所以最少3个，遵循2N+1 原则，支持宕机 N 个节
点。

Q7: Consul能够支撑多大的高并发系统?

A7: 这个问题跟上面的问题稍有些重合，其实高并发是指的业务，业务一般在 启动、停止、迁移 、或业务之间相互访问时 Consul 才会有些数据交互 ，Consul的健 康检查 和 访问都是分摊到每个宿主机上， Consul 的压力 对比业务来说可以忽略不计。

上一篇下一篇

猜你喜欢

热点阅读