1. 关于两地三中心
如上图，两地三中心的架构，是为了提高系统的容错、容灾的能力。当一个数据中心不可用时，能够将关键业务的流量切换到其他数据中心，可以抵御城市级的自然灾害。两地指的是，地理上不同的两座城市，而三中心指的是:
- 生产中心
- 同城灾备中心
- 异地灾备中心
2. 机房的网络连接
如上图，两地三中心架构的前提是，各个机房是互联互通的。因此，我们需要搭建一个低延时的环形网络。光纤的长度，通常在 50 KM 以上。如果租用了运营商的专线，延时可以高一点，但通常不会超过 20 ms。如果是同城光纤，延时只有 3 ms 左右。我们需要在机房间距、延时二者之间进行取舍:
- 机房间距离越远，容灾能力越强，但光纤会更长，延时会更高
- 机房间距离越短，容灾能力越差，但光纤会越短，延时会很低
在同城的两个机房之间，网络延时很低，数据一致性很高。而异地机房，由于距离很远，可以租用专线与另外两个机房互联，避免过高的延时。
3. 应用流量的分发
如上图，是用户访问应用时的流量走向:
3.1 为什么是异地机房承载流量
没有经过流量冲击的路径是不可靠的。即使做了高可用、容灾，如果没有常态化的演练，系统也不会具备应对的能力。因此，在多机房建设时，非常重要的一点就是，让更多机房获得访问流量。这里选择的是，两个异地的机房作为日常主要的流量机房，原因如下:
- 更好演练灾难发生时的状况
- 租用专线之后，异地机房延时能满足要求
- 有足够预算购买专线带宽
3.2 为什么 DNS 之后，还有一层 LB
这里可能会有一个疑问，在机房外，DNS 对流量进行了一次切分，在机房内，LB 又对流量进行了一次切分，原因如下:
- DNS 生效慢，增加一层 LB 能更快切换流量
- 准确控制分配至各机房的流量比例
- 支持按机房灰度发布应用的版本
4. 有状态与无状态的分层
如上图，有状态应用和无状态应用的分层，使得服务架构更加清晰。由无状态应用对外提供服务，而有状态应用为无状态应用提供服务。这里的有状态应用，使用的是虚拟机部署的高可用服务，或者直接购买厂商的云服务中间件。
4.1 无状态应用
如上图，无状态应用基于 Kubernetes 提供运行时环境。得益于其强大的弹性与自愈能力，我们只需要关注于对各种云原生组件的使用，对参数的调优，即可满足大部分的业务需求。对于无状态应用，我们通常会采用 Ingress 或 NodePort 的方式，对外暴露服务。两者的区别主要在于:
- 支持的服务数量。每个 NodePort 会占用一个端口
- 功能差异。Ingress 能提供 Host、灰度、子 Path 路径等功能
- 组件数量。Ingress 需要更多组件支撑
- 运维成本。Ingress 更新时，影响面更大，运维成本高
- 迁移成本。NodePort 可能会发生端口冲突
Kubernetes 并不是保证服务 100% 可用，而是一旦服务异常时，能够快速利用空闲资源新建。同时，Kubernetes 还面临集群升级、主机维护等问题，因此，对于一些低频变更、对稳定性要求高的服务，我们采用的是虚拟机部署。比如这里的 LB，LB 是一个影响面很大的应用，而且数量不会很多，我们通常会采用高可用的模式，部署在几台虚拟机上。
4.2 有状态应用
- 镜像仓库
Harbor 的高可用通常有两种方式:
这里采用的是 Harbor 共享存储高可用 + dragonFly 的方式。在非主要流量机房，部署高可用的 Harbor，通过 dragonFly 分发镜像到各个机房，机房中的主机通过 dfget 配置 mirror 拉取镜像。如下图:
使用 dragonFly 分发镜像，能减少同一个镜像，多副本应用实例部署时的拉取次数，节省专线的带宽。
- MySQL 多机房 MHA 高可用
相较于国外使用 PostgreSQL，国内使用 MySQL 特别多。MHA（Master High Availability）是一套成熟的 MySQL 解决方案。在 MySQL 发生故障时，MHA 能在 30 秒以内完成数据库的故障切换操作，同时最大程度的保障数据一致性。
- Redis 多机房集群模式
Redis 集群通过分片来实现数据共享，并提供复制和故障转移。相较于哨兵模式只有一个 master，集群模式有多个 master，具有高的可用性。
5. 总结
本篇主要是简单总结了一下两地三中心的架构。所写即所见的抽象，并不能完全尽述细节。主要内容如下：
- 两地三中心的要点，是要构建一个环形的互联互通机房网络
- 有状态应用采用虚拟机部署，无状态应用采用 Kubernetes 部署
- 访问流量，先通过 DNS 切分到机房，在机房中再通过 LB 切分到各个集群
