架构设计精粹之灾备

2021-05-17 创建
2021-05-17 更新
5分钟阅读时长

对于各行各业而言,数据和服务都始终是企业最为核心的财富。得益于云计算的蓬勃发展,灾备对于中小企业的门槛大大降低,越来越多的业务开始应用灾备策略。

那么,什么是灾备?一个良好的技术架构应该如何考虑灾备因素呢?

灾备与高可用

灾备是指容灾和备份,本质上是两个不同的概念:

  • 容灾:在物理距离相隔较远的两地或者多地建立功能相同的数据中心(也有称为 机房),同时互相之间可以进行健康检查和功能切换。当某一中心因意外(自然灾害、人为失误等因素)停止工作时,另一中心能够及时接管,从而保障业务的正常运作。
  • 备份:针对业务核心数据制作一份或者多份副本,防止数据丢失,保障数据安全。

高可用是和容灾相关的另一常用词汇,与高并发经常一同出现,但本质上也是两个不同的概念:

  • 高并发:指代服务请求量很大,通常要考虑的是:负载均衡、横向扩容、数据分片、缓存系统、消息队列等优化手段。
  • 高可用:不同于高并发,高可用这个维度与业务量无关。指代为了应对突发场景,通常选择在不同的数据中心部署同一功能的服务,以便进行故障切换。

冷备与多活

对业务核心数据来说,有且只有冷备。所有数据副本均是冷备,用于当故障发生时候能够及时还原。

对业务核心服务来说,冷备和多活是两种不同的方式。冷备是作为业务服务的副本运行但实际上没有任何流量,仅当灾难发生的时候,用于主备切换从而顶替主服务处理业务流量。多活则是一种更加先进的方式,它不搁置任一数据中心,而在每个数据中心均正常运行业务服务,这也是所谓“”的意思。

多活相对于冷备来说,资源利用率能够得到极大提升。但多活对于业务本身的改造挑战非常大,不是所有业务都能够应用多活架构。

架构演进

让我们站在架构演进的角度来看待整个发展过程。

单机房架构

主流互联网业务的服务端架构大致分为三层:

  • 接入层:接收业务流量。接入层的代表组件是Apache、Nginx等,主要负责域名解析、反向代理、负载均衡等网关能力。
  • 服务层:处理业务逻辑。服务层的代表组件是SpringBoot、Dubbo等,主要负责处理复杂的业务逻辑。
  • 存储层:存储业务数据。存储层的代表组件是MySQL、Redis等,主要存储业务核心数据、提供分布式缓存。

而在实际的生产环境中,每一层组件均会采用不同的集群策略:

  • 接入层:接入层是无状态层。因此通常会部署多个实例组成集群。集群中的每一个实例均接收业务流量,解决高并发的需求;另一方面,若集群中的某一个实例宕机则业务流量能够自动转移到其它健康实例,解决高可用的需求。
  • 服务层:服务层是无状态层。因此同样会部署多个业务服务实例,兼顾高并发和高可用。
  • 存储层:存储层是有状态层。以MySQL为例,通常采用主从集群架构,主从之间采用同步复制,并对业务提供读写分离的能力。读写分离能够有效均衡业务的写操作和读操作对DB的压力,解决一定程度的高并发需求;另一方面,当主节点宕机时从节点能够被提升为主节点继续提供服务,解决一定程度的高可用需求。

至此,单机房的高并发和高可用架构雏形基本完成。然而,现实生活中往往存在各种天灾人祸,例如:机房网络故障、机房整体断电、人为误操作等等,这类事故的发生概率虽然极小,但万一遇到,会对企业造成不可恢复的巨大财富损失。

因此,现代互联网架构尤其是公有云架构通常会扩展新的机房。

同城双机房架构

同城双机房架构是目前主流的性价比极高的灾备方案。所谓同城,指代两个可用机房的物理距离相近,位于同一座城市。例如:字节跳动国内自建的核心机房位于河北廊坊和河北怀来两地,同属于河北省。双机房之间通过高速专线连通网络,由于双机房距离相近,网络延时极低对业务可以忽略不计,因此也非常适合存储层组件的同步复制。

当主机房灾难发生时,通过快速的DNS切换将业务流量迅速导入副机房。同时对于存储层的组件来说,将副机房的备份停止并切换为主。理论上,整体业务能够在分钟级别恢复并且能够保障数据不丢失。

同城双机房双活架构

同城双机房架构包含数据中心和灾难备份中心,正常情况下数据中心提供业务流量,灾难备份中心不提供业务流量,仅当灾难发生时通过DNS切换的方式将业务流量转移至灾难备份中心。该架构主要存在如下问题:

  1. 灾难备份中心长期处于冷备状态,资源利用率非常低。
  2. 灾难备份中心由于长期未投入使用,可能随着业务迭代而逐步埋入隐患,导致真正需要灾备切换时候没有成功激活。

同城双机房双活架构是对同城双机房架构的进阶做法,双机房均是活跃的数据中心,同时提供业务流量。对于无状态的接入层和服务层来说无需任何改造,而对于有状态的存储层来说需要进行一定改造:

这是双活架构的常见做法,无状态的接入层和服务层双活部署,有状态的存储层主备部署。这样一来,无论是哪个数据中心出现灾难,都可以快速切换到另外一个数据中心继续提供服务。

但是该架构也存在一个问题:双机房存储层强依赖于网络高速专线,假如专线故障,那么同步将会中断,形成孤岛。此时,存储层的备份机房无法正常工作,业务流量需要全量切换到主机房。

两地三中心

两地三中心是在同城双机房架构的基础上引入一个异地灾备中心,所谓三中心指数据中心、同城灾备中心和异地灾备中心。异地灾备由于地理位置相隔较远,因此技术上无法采用同步复制,而需要采用异步复制。

异地灾备能够防止更加严重的灾害,例如地震、水灾、战争等。不过由于异地灾备中心通常采用异步复制技术来备份业务核心数据,因此在灾害发生的时候通常会伴随少量的数据丢失情况。

参考

  1. 阿里云通用解决方案
  2. “两地三中心”和“双活”简介–容灾技术方案
  3. 同城双活与异地多活架构分析
  4. 高可用解决方案:同城双活?异地双活?异地多活?怎么实现?

总结

本文介绍了现代主流灾备架构的关键要素和具体实现。灾备毫无疑问是考验现代云上数据中心的核心指标,对于企业来说也是重要的生命线!

Avatar
吴国华 Go语言/微服务/后端/云原生/技术管理