Tuesday, August 18, 2015

用 consul + consul-template + registrator + nginx 打造真正可动态扩展的服务架构

在互联网应用领域,服务的动态性需求十分常见,这就对服务的自动发现和可动态扩展提出了很高的要求。
Docker 的出现,以及微服务架构的兴起,让众多开源项目开始关注在松耦合的架构前提下,如何基于 Docker 实现一套真正可动态扩展的服务架构。

基本需求

基本的需求包括:
  • 服务启动后要能自动被发现(vs 传统需要手动进行注册);
  • 负载要能动态在可用的服务实例上进行均衡(vs 传统需要静态写入配置);
  • 服务规模要方便进行快速调整(vs 传统需要较长时间的手动调整)。

相关项目

服务发现

服务发现的项目已经有不少,包括之前介绍的 consul,以及 skydnsserf、以及主要关注一致性的强大的 zookeeper 等。
这些项目各有优缺点,功能上大同小异,都是要通过某种机制来获取服务信息,然后通过维护一套(分布式)数据库来存储服务的信息。这也是为什么 etcd 受到大家关注和集成。
在这里,选用 HashiCorp 公司的 consul 作为服务发现的管理端,它的简介可以参考 这里

服务注册

服务注册的手段有很多,当然,从发起方是谁可以分为两大类,主动注册还是被动探测。
主动注册,顾名思义,服务启动后,向指定的服务发现管理端的 API 发送请求,给出自身的相关信息。这样做,对管理端的要求简单了很多,但意味着服务自身要完成注册工作,并且极端情况下,管理端比较难探测出真正存活的服务。
被动探测,则是服务发现管理端通过某种机制来探测存活的服务。这样可以获取真实的服务情况,但如何探测是个很难设计的点,特别当服务类型比较复杂的时候。
以上两种,都对网络连通性要求较高。从短期看,主动注册方式会比较容易实现一些,应用情形更广泛;但长期维护上,被动探测方式应该是更高效的设计。
这里,我们选用 gliderlabs 的 registrator,它可以通过跟本地的 docker 引擎通信,来获取本地启动的容器信息,并且注册到指定的服务发现管理端。

配置更新

服务被调整后,负载均衡器要想动态重新分配负载,就需要通过配置来获取更新。这样的方案也有不少,基本上都是要安装一些本地 agent 来监听服务发现管理端的信息,生成新的配置,并执行更新命令。
HashiCorp 公司 的consul-template,可以通过监听 consul 的注册信息,来完成本地应用的配置更新。

负载均衡

负载均衡对性能要求很高,其实并不是软件所擅长的领域,但软件方案胜在成本低、维护方便。包括 lvshaproxy 都是很优秀的设计方案。
这里,我们选用 nginx。nginx 不仅是个强大的 web 代理服务器,同时在负载均衡方面表现也不俗。更关键的,新版本的 nginx 对在线升级支持做到了极致。实时配置更新更是不在话下,可以保证服务的连续性。

实验过程

准备工作

首先,从 这里 下载模板文件。
主要内容如下:
#backend web application, scale this with docker-compose scale web=3
web:
  image: yeasy/simple-web:latest
  environment:
    SERVICE_80_NAME: http
    SERVICE_NAME: web
    SERVICE_TAGS: backend
  ports:
  - "80"

#load balancer will automatically update the config using consul-template
lb:
  image: yeasy/nginx-consul-template:latest
  hostname: lb
  links:
  - consulserver:consul
  ports:
  - "80:80"

consulserver:
  image: gliderlabs/consul-server:latest
  hostname: consulserver
  ports:
  - "8300"
  - "8400"
  - "8500:8500"
  - "53"
  command: -data-dir /tmp/consul -bootstrap -client 0.0.0.0

# listen on local docker sock to register the container with public ports to the consul service
registrator:
  image: gliderlabs/registrator:master
  hostname: registrator
  links:
  - consulserver:consul
  volumes:
  - "/var/run/docker.sock:/tmp/docker.sock"
  command: -internal consul://consul:8500
如果没有安装 docker 和 docker-compose,需要先进行安装,以 ubuntu 系统为例。
$ curl -sSL https://get.docker.com/ | sh
$ sudo pip install docker-compose

执行

docker-compose 模板所在目录,执行
$ sudo docker-compose up
相关镜像即可自动被下载,下载完毕后,容器就启动起来了。
访问 http://localhost 可以看到一个 web 页面,提示实际访问的目标地址。
多次刷新,可以看到目标地址没有变化,这是因为,目前我们只有一个 web 后端服务器。
2015-08-18 03:37:58: 6 requests from <LOCAL: 172.17.1.150> to WebServer <172.17.1.148>
调整后端为 3 个服务器。
$ sudo docker-compose scale web=3
然后,再次访问 http://localhost,多次刷新,可以看到访问的实际目标地址发生了变化,新启动的 web 服务器被自动注册,并且 nginx 自动对它们进行了负载均衡。
2015-08-18 03:37:58: 6 requests from <LOCAL: 172.17.1.150> to WebServer <172.17.1.148>
2015-08-18 03:38:17: 5 requests from <LOCAL: 172.17.1.150> to WebServer <172.17.1.152>
2015-08-18 03:38:20: 5 requests from <LOCAL: 172.17.1.150> to WebServer <172.17.1.153>

Tuesday, August 04, 2015

Consul 简介

概述

Consul 是一套开源的分布式服务发现和配置管理系统,由 HashiCorp 公司用 Go 语言开发。
它具有很多优点。包括: 基于 raft 协议,比较简洁; 支持健康检查, 同时支持 HTTP 和 DNS 协议 支持跨数据中心的 WAN 集群 提供图形界面 跨平台,支持 Linux、Mac、Windows

安装

从 www.consul.io/downloads.html 下载二进制文件到本地即可。
consul 在每个节点上都只需要相同的单一二进制文件,部署十分简单。

基本概念

agent

组成 consul 集群的每个成员上都要运行一个 agent,可以通过 consul agent 命令来启动。agent 可以运行在 server 状态或者 client 状态。自然的,运行在 server 状态的节点被称为 server 节点;运行在 client 状态的节点被称为 client 节点。

client 节点

负责转发所有的 RPC 到 server 节点。本身无状态,且轻量级,因此,可以部署大量的 client 节点。

server 节点

负责组成 cluster 的复杂工作(选举、状态维护、转发请求到 lead),以及 consul 提供的服务(响应 RCP 请求)。考虑到容错和收敛,一般部署 3 ~ 5 个比较合适。
第一个节点:
$ consul agent -data-dir=/tmp/consul -server -bootstrap-expect 1 -bind $IP
其他节点:
$ consul agent -data-dir=/tmp/consul -server -join $IP
通过 $IP:8500/v1/catalog/nodes 可以访问到注册上的节点。

Gossip

基于 Serf 实现的 gossip 协议,负责成员、失败探测、事件广播等。通过 UDP 实现各个节点之间的消息。分为 LAN 上的和 WAN 上的两种情形。

架构

consul architecture

相关项目

registrator

可以监听主机上的容器信息,并把有暴露端口的容器注册到给定的 consul/etcd 等服务上。

consul-template

可以监听 consul 服务的内容变化,并根据变化实时更新应用的配置文件。