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

运维 系统运维 系统 PaaS
Consul的运维成本低,部署简单、使用方便、五脏俱全,这对于中小型团队应该是性价比很高的。本文介绍具体的Consul应用过程和相应的步骤,供大家参考!

   作者介绍

[[162541]]
 

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

  应用背景

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

 

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

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

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

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

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

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

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

  为什么选择 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)。

  实验环境:

  1. server01 192.168.1.11 
  2.   server02 192.168.1.12 
  3.   server03 192.168.1.13 
  4.   client01 192.168.1.21 

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

  1. [worker@server01 ~]$ consul agent -server -bootstrap-expect 2 -data-dir /tmp/consul -bind=192.168.1.11 -node=server01 
  2.   [worker@server02 ~]$ consul agent -server -bootstrap-expect 2 -data-dir /tmp/consul -bind=192.168.1.12 -node=server02 
  3.   [worker@server03 ~]$ consul agent -server -bootstrap-expect 2 -data-dir /tmp/consul -bind=192.168.1.13 -node=server03 

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

  1. [worker@server03 ~]$ consul join 192.168.1.11 192.168.1.12 

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

  1. [worker@server01 ~]$ consul agent -server -bootstrap-expect 2 -data-dir /tmp/consul -bind=192.168.1.11 -node=server01 -rejoin 
  2.   [worker@server02 ~]$ consul agent -server -bootstrap-expect 2 -data-dir /tmp/consul -bind=192.168.1.12 -node=server02 -rejoin 
  3.   [worker@server03 ~]$ consul agent -server -bootstrap-expect 2 -data-dir /tmp/consul -bind=192.168.1.13 -node=server03 -rejoin 

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

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

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

  1. [worker@client01 ~]$ consul join 192.168.1.11 

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

  1. [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是粘合剂也是开关,让整个系统的运作起来,低成本的实现了弹性伸缩。

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

  运行Consul Template是实现弹性扩展的关键步骤:

  1. $ 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是该配置文件对应的模板。下面是模板在负载均衡上的代码片段:

  1. upstream test-cluster { 
  2.   ip_hash;{{range service "test"}} 
  3.   server {{.Address}}:{{.Port}};{{end}} 
  4.   } 

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

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

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

  1.     "service":  
  2.     { 
  3.         "name" : "test"
  4.         "port" : 9999, 
  5.         "check":  
  6.         { 
  7.           "tcp""127.0.0.1:9999"
  8.           "interval""10s" 
  9.         } 
  10.     } 

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

  1. $ 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的节点。

  结语

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

责任编辑:武晓燕 来源: 高效运维
相关推荐

2012-11-14 15:25:58

2023-04-18 08:21:23

KafkaApache预订应用

2015-11-03 16:43:01

容器编排容器环境可扩展

2023-07-26 16:20:36

云原生云计算

2024-03-12 12:22:16

2024-04-02 11:26:42

架构软件开发

2023-09-25 12:13:00

Android架构

2012-04-12 12:49:22

思科FlexPod架构NetApp

2015-04-14 09:31:10

AWSAWS PaaSSaaS可视化编排

2021-12-31 18:19:18

平台即服务PaaS云计算服务平台

2021-09-02 09:42:11

测试软件可扩展性开发

2018-01-31 07:09:57

数据中心虚拟化可扩展性

2009-06-10 16:56:12

可扩展GlassFisJavaEE6

2020-11-19 18:08:45

VMware

2015-02-06 09:17:18

PaaS安全控制测试ISSO

2022-07-07 14:10:59

PaaS亚马逊云科技云原生

2022-09-05 15:17:34

区块链比特币可扩展性

2015-08-18 13:25:12

PaaS服务架构动态扩展

2015-01-15 09:27:17

CloudFoundrPaaS开源
点赞
收藏

51CTO技术栈公众号