容器下的两地三中心建设-技术圈

1. 关于两地三中心

如上图，两地三中心的架构，是为了提高系统的容错、容灾的能力。当一个数据中心不可用时，能够将关键业务的流量切换到其他数据中心，可以抵御城市级的自然灾害。

两地指的是，地理上不同的两座城市，而三中心指的是:

如上图，两地三中心架构的前提是，各个机房是互联互通的。因此，我们需要搭建一个低延时的环形网络。光纤的长度，通常在 50 KM 以上。如果租用了运营商的专线，延时可以高一点，但通常不会超过 20 ms。如果是同城光纤，延时只有 3 ms 左右。

我们需要在机房间距、延时二者之间进行取舍:

在同城的两个机房之间，网络延时很低，数据一致性很高。而异地机房，由于距离很远，可以租用专线与另外两个机房互联，避免过高的延时。

如上图，是用户访问应用时的流量走向:

没有经过流量冲击的路径是不可靠的。即使做了高可用、容灾，如果没有常态化的演练，系统也不会具备应对的能力。

因此，在多机房建设时，非常重要的一点就是，让更多机房获得访问流量。这里选择的是，两个异地的机房作为日常主要的流量机房，原因如下:

这里可能会有一个疑问，在机房外，DNS 对流量进行了一次切分，在机房内，LB 又对流量进行了一次切分，原因如下:

如上图，有状态应用和无状态应用的分层，使得服务架构更加清晰。由无状态应用对外提供服务，而有状态应用为无状态应用提供服务。

这里的有状态应用，使用的是虚拟机部署的高可用服务，或者直接购买厂商的云服务中间件。

如上图，无状态应用基于 Kubernetes 提供运行时环境。得益于其强大的弹性与自愈能力，我们只需要关注于对各种云原生组件的使用，对参数的调优，即可满足大部分的业务需求。

对于无状态应用，我们通常会采用 Ingress 或 NodePort 的方式，对外暴露服务。两者的区别主要在于:

Kubernetes 并不是保证服务 100% 可用，而是一旦服务异常时，能够快速利用空闲资源新建。同时，Kubernetes 还面临集群升级、主机维护等问题，因此，对于一些低频变更、对稳定性要求高的服务，我们采用的是虚拟机部署。

比如这里的 LB，LB 是一个影响面很大的应用，而且数量不会很多，我们通常会采用高可用的模式，部署在几台虚拟机上。

Harbor 的高可用通常有两种方式:

这里采用的是 Harbor 共享存储高可用 + dragonFly 的方式。在非主要流量机房，部署高可用的 Harbor，通过 dragonFly 分发镜像到各个机房，机房中的主机通过 dfget 配置 mirror 拉取镜像。如下图:

使用 dragonFly 分发镜像，能减少同一个镜像，多副本应用实例部署时的拉取次数，节省专线的带宽。

相较于国外使用 PostgreSQL，国内使用 MySQL 特别多。MHA（Master High Availability）是一套成熟的 MySQL 解决方案。在 MySQL 发生故障时，MHA 能在 30 秒以内完成数据库的故障切换操作，同时最大程度的保障数据一致性。

Redis 集群通过分片来实现数据共享，并提供复制和故障转移。相较于哨兵模式只有一个 master，集群模式有多个 master，具有高的可用性。

本篇主要是简单总结了一下两地三中心的架构。所写即所见的抽象，并不能完全尽述细节。主要内容如下：