简介
下面两个章节中的内容，可以帮助用户部署一个由consul打造的安全可靠的数据中心。如果用户希望将这个用户中心投入生产环境使用，建议从头到尾仔细阅读这份文档，它们将帮助您成功建立和维护健康的数据中心，这篇文档涵盖以下几个内容：
- 基础架构建议
- 搭建数据中心
- 备份数据中心状态
- 保护数据中心安全
- 配置网络
- 多个数据中心配置
Consul 参考架构
基础设置要求
Consul 服务端
Consul服务端代理（Agent）维护集群状态，响应RPC查询，并处理所有写入操作。由于Consul服务端代理承担了大部分繁重的工作，因此服务器主机配置对于Consul集群的整体性能就比较关键了，下面列举了推荐的服务器配置：
| 规格 | CPU | 内存 | 磁盘 | 典型的云示例配置 |
|---|---|---|---|---|
| Small | 2-4 core | 8-16 GB RAM | 50GB | AWS: m5.large, m5.xlarge；Azure: Standard_D2_v3, Standard_D4_v3；GCP: n2-standard-2, n2-standard-4 |
| Large | 8-16 core | 32-64 GB RAM | 100GB | AWS: m5.2xlarge, m5.4xlarge；Azure: Standard_D8_v3, Standard_D16_v3；GCP: n2-standard-8, n2-standard-16 |
硬件配置考量
- 小规格配置适用于大多数小型生产环境或开发/测试环境
- 大规格配置适用于负载较高的生产环境
此处需要注意，对于大型工作负载，请确保磁盘支持大量 IOPS，以跟上 Raft 日志的更新速度。
基础架构图
数据中心设计
用户可以在单个物理数据中心、或跨多个数据中心部署Consul集群（通常是3或5台服务器，加上客户端代理）。对于运行时高读写的大型集群，将服务器部署在同物理地址可以提高性能；在云环境中，用户可以跨多个可用区域（zone）部署一个数据中心，例如每个可用区域对应一台单一的主机。Consul还可以通过WAN连接单独的集群组成多数据中心。
单数据中心
对于部署在同一个数据中心中的应用程序，我们建议使用一个Consul集群。Consul支持传统的三层架构应用，同样也支持微服务，搭建一个集群通常是3或5台机器，用户可以在可用性和性能间寻找平衡。
单个数据中心的节点（node）数建议不超过5000个，对于读写频繁的集群，可能需要进一步减少最大节点数，这具体取决KV对的数量以及监控数据的数量。当用户添加更多的客户端机器时，Gossip协议执行的时间会更长、
对于写负载高的集群，推荐使用硬件升级垂直扩展，并使用低延迟存储。
服务标签（Service Tag）可帮助用户对集群中的内容进行查询
多数据中心
用户可以通过WAN链接加入在不同数据中心中运行相同服务的Consul集群。集群间独立运行，仅通过8302端口上的WAN通信，除非通过命令行或者API明确配置，否则Consul服务器将仅从其本地数据中心返回结果。Consul不会在多个数据中心之间复制数据，但是用户可以使用consul-replicate工具定期同步KV数据。
比较好的实践是启用TLS服务名称检查，以避免代理意外交叉连接。
Consul的预查询（prepared queries）允许客户端在某一数据中心发生故障后，去另一个数据中心发现服务。例如本地数据中心dc1中的payment服务下线了，则预查询使用户能能访问到离该数据中心地理位置最近的其他正常服务。
默认情况下，预查询首先会在本地数据中心解析。它们不支持查询KV数据，但是可以使用ACLs。
网络连接
局域网Gossip发生在单个数据中心中的所有代理之间，每个代理均向其成员列表中的随机代理定期发送探测。客户端和服务端代理都参与了Gossip协议。初识探测通过UDP每秒发送一次，如果节点在200ms内未确认，代理将使用TCPping通，如果TCP探测失败（10s超时），它会要求其他随机节点向这个节点发送探测（称为间接探测），如果还是没有获得有关该节点的响应，则会将该代理标记为已关闭。
代理的状态直接影响服务发现结果，如果代理关闭，则它正在监控的服务也会标记为关闭。
此外，代理还通过TCP定期执行完整状态同步，这将使每个代理了解其周围的成员列表（包括节点名称、IP地址和运行状况），相对于上述标准Gossip协议，这些操作开销比较昂贵，时间通常在30s到5m之间，具体时间根据集群大小而定。
Consul涉及到的服务和端口如下所示：
| 名称 | 端口 | 标志位 | 描述 |
|---|---|---|---|
| Server RPC | 8300 | / | 服务端接收其他代理的请求，仅TCP连接 |
| Serf LAN | 8301 | / | 用于处理局域网中的Gossip协议，所有代理都需要，TCP和UDP连接 |
| Serf WAN | 8302 | -1禁用 | 服务端传递Gossip协议，TCP和UDP连接 |
| HTTP API | 8500 | -1禁用 | 客户端访问Http请求，仅TCP连接 |
| DNS Interface | 8600 | -1禁用 | / |
部署指南
这篇文章涵盖了Consul安装部署的细节，此章节与上一个章节关联，此处强烈建议用户先熟悉Consul的整体架构，为了提供高可用的单集群体系结构，建议将Consul服务器代理部署在多台主机上，Consul的参考体系架构如下：
下载Consul
登录Consul二进制文件下载页面，选择对应版本的Consul服务：https://releases.hashicorp.com/consul/
安装Consul
解压zip包，将Consul二进制文件移动到/usr/local/bin/目录下，检验一下Consul命令是否可用：
unzip consul_${CONSUL_VERSION}_linux_amd64.zip
sudo chown root:root consul
sudo mv consul /usr/local/bin/
consul --version
开启Consul的命令补全功能：
consul -autocomplete-install
complete -C /usr/local/bin/consul consul
创建一个非特权系统用户运行Consul并创建其数据目录：
sudo useradd --system --home /etc/consul.d --shell /bin/false consul
sudo mkdir --parents /opt/consul
sudo chown --recursive consul:consul /opt/consul
配置systemd（系统服务设置）
在/etc/systemd/system/consul.service中创建Consul服务文件
sudo touch /etc/systemd/system/consul.service
在配置文件中添加配置：
[Unit]
Description="HashiCorp Consul - A service mesh solution"
Documentation=https://www.consul.io/
Requires=network-online.target
After=network-online.target
ConditionFileNotEmpty=/etc/consul.d/consul.hcl
[Service]
Type=notify
User=consul
Group=consul
ExecStart=/usr/local/bin/consul agent -config-dir=/etc/consul.d/
ExecReload=/usr/local/bin/consul reload
KillMode=process
Restart=on-failure
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target
systemd配置项详解：
| 配置项 | 作用域 | 描述 |
|---|---|---|
| Description | Unit | 自定义字符串描述Consul服务名 |
| Document | Unit | 关联到Consul文档 |
| Requires | Unit | 服务启动前依赖的其他服务 |
| After | Unit | 服务启动完毕前依赖的其他服务 |
| ConditionFileNotEmpty | Unit | 依赖的配置项文件 |
| User、Group | Service | 启动Consul的服务和组 |
| ExecStart | Service | 启动Consul指令 |
| ExecReload | Service | 重启Consul指令 |
| KillMode | Service | 指定如何结束该进程 |
| Restart | Service | 重启服务机制 |
| LimitNOFILE | Service | 文件描述符上限 |
| WantedBy | Install | / |
配置Consul（服务端）
Consul有默认配置项，在配置文件中仅需设置需要自定义的配置项，配置项可以从多个配置文件中读取，并顺序加载。
整体配置
创建一个配置文件/etc/consul.d/consul.hcl：
sudo mkdir --parents /etc/consul.d
sudo touch /etc/consul.d/consul.hcl
sudo chown --recursive consul:consul /etc/consul.d
sudo chmod 640 /etc/consul.d/consul.hcl
在配置文件中添加：
datacenter = "dc1"
data_dir = "/opt/consul"
encrypt = "Luj2FZWwlt8475wD1WtwUQ=="
| 配置项 | 描述 |
|---|---|
| datacenter | 运行代理的数据中心 |
| data_dir | 代理存储状态的数据目录 |
| encrypt | 对Consul网络流量进行加密的密钥 |
自动加入集群
retry_join参数允许用户配置Consul代理，通过DNS地址、IP地址或Cloud Auto-join自动形成集群，这样就无需手动配置Consul节点加入集群。
retry_join = ["172.16.0.11"]
| 配置项 | 描述 |
|---|---|
| retry_join | 启动时需要加入的另一个代理的地址 |
性能配置
性能配置允许调整Consul中不同子系统的性能。
performance {
raft_multiplier = 1
}
度量指标（Telemetry）配置
度量指标为Consul指定了各种配置，将度量标准发布到上游系统。
服务端配置
server = true
bootstrap_expect = 3
| 配置项 | 描述 |
|---|---|
| server | 用于表示该Consul服务是服务端模式还是客户端模式 |
| bootstrap_expect | 用于表示数据中心预期的服务器数量 |
控制台UI配置
Consul具有基于Web的控制台界面，用户可以通过图形界面轻松查看所有服务、节点和其他信息
ui = true
配置Consul（客户端）
Consul客户端代理配置是Consul服务端代理的子集，按实际需要配置。
启动Consul
使用systemctl命令控制systemd托管服务。
sudo systemctl enable consul
sudo systemctl start consul
sudo systemctl status consul
数据中心备份
在生产环境中创建服务器备份是非常重要的，备份为服务器提供了一种从故障（网络问题、人员失误或磁盘损坏）中恢复的机制。所有服务器在提交写请求之前，都会先写入-data-dir，客户端代理也可以使用相同的路径来保存本地状态，但一般不太必要，通常情况仅需备份服务端的Raft存储状态。
Consul可以使用命令行或者API执行快照（Snapshot）命令，快照命名可以保存执行时间点上的服务器状态，其中包含：
- KV条目（KV entries）
- 服务目录（the service catalog）
- 查询语句（prepared queries）
- 会话（sessions）
- 访问控制列表（ACLs）
默认情况下，所有快照均使用一致性模式（consistent mode）拍摄，在该模式下，请求将转发给领导者（leader），领导者在拍摄快照之前会验证服务是否仍在运行，如果数据中心降级或者没有领导者，则快照不会保存，为了减轻领导者的负载，可以使用弱一致性模式（stale consistency mode）。
这将负载分散到各个节点上，会损失一部分一致性，微量的最近的写入信息会遗漏，省略的写操作通常限于从恢复点开始到最近100ms或更短时间内的写入数据，这通常适用于灾难恢复了。
创建数据备份
保存快照命令有许多配置选项，在生产环境中，为了提高安全性，用户需要配置ACL令牌和客户端证书，使用默认配置（包含一致性模式）保存快照命令如下：
consul snapshot save backup.snap
备份内容会保存在执行命令的目录中，可以使用inspect子命令查看备份文件的元数据：
$ consul snapshot inspect backup.snap
ID 2-1182-1542056499724
Size 4115
Index 1182
Term 2
Version 1
接下来，使用弱一致性模式保存快照：
consul snapshot save -stale backup.snap
一旦配置了ACL或者代理证书，需要将它们作为环境变量或标志传递：
export CONSUL_HTTP_TOKEN=
consul snapshot save -stale -ca-file= backup.snap
在上面的示例中，我们将令牌设置为环境变量，将证书文件设置为命令行标志。
对于生产环境，应该将快照命令或API编写为脚本定期运行，除了日常备份之外，还有几种情况需要手动执行保存快照。一个是在升级前执行备份；另一个是在数据中心失去仲裁，在服务器状态发散前执行备份。在实际操作过程中，不需要为每台服务器都执行备份，备份的文件可以保存在挂载的文件系统或者使用云存储（例如Amazon S3）。
从备份中恢复
执行下述操作，Raft协议可确保所有服务器恢复到相同状态：
consul snapshot restore backup.snap
和save子命令一样，restore子命令也有许多配置项。