Please enable Javascript to view the contents

容器下的两地三中心建设

 ·  ☕ 4 分钟

1. 关于两地三中心

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

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

  • 生产中心
  • 同城灾备中心
  • 异地灾备中心

2. 机房的网络连接

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

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

  • 机房间距离越远,容灾能力越强,但光纤会更长,延时会更高
  • 机房间距离越短,容灾能力越差,但光纤会越短,延时会很低

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

3. 应用流量的分发

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

  1. 用户通过域名访问应用服务,通过智能 DNS 解析到地理上更近的机房 IP
  2. 在机房中,使用虚拟机部署有一个 LB 服务,对流量进行切分,一部分流量被切分到了另外一个机房
  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 的高可用通常有两种方式:

  1. 多个独立部署的 Harbor 实时同步。不同的 Harbor 实例之间,镜像可能不一致,有一定时延。
  2. 多个 Harbor 共享一个存储后端。多个 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 切分到各个集群

微信公众号
作者
微信公众号