数据时代全球每天新产生的数据达到 2.3EB，存量数据达到 33ZB，无论是传统企业还是新晋独角兽企业，都在基于大数据进行更快、更好的决策支持，从数据中孵化新的产品与服务，同时降低成本。可以说，数据就是生产力。一旦出现数据丢失问题，对于企业来说是毁灭性的，据 IDC 统计数据，有高达 84% 的企业在遭遇严重数据丢失后的 2~3 年内退出了市场，随着企业对数据依赖程度的递增，这个比例会变得更高。在数字化信息化时代，没有哪个组织能够从无法快速恢复的数据灾难中全身而退。

图片来源于 medium

在过去几年里，黑天鹅事件层出不穷，机房大面积断电、整个可用区不可用等意外时有发生。就在 2021 年 3 月 9 日，欧洲最大公有云服务提供商 OVH Cloud 由于一场大火导致整个 IDC 被毁灭，数百万的网站不可用。在 2015 年的天津大爆炸事件中，腾讯亚洲最大的 IDC 离毁灭仅仅只有 1.5 公里，更不用提因为各种人为操作失败导致的数据丢失。

极端情况下全站持续不可用已经成为一个现实问题，在数据容灾领域，唯一能确定的就是数据的易失性。所以，各大公司都在构建自己的数据容灾体系。

BACKUP 是数据容灾的黄金法则，一切数据都是通过备份提升冗余度来容灾。数据的重要程度、恢复的时效性，决定了数据的备份策略。低级别的日志类数据一般采取单机离线冷备，重要数据则采用多副本热备，而影响公司命脉的核心数据通常采用 321 备份策略，即：

• 至少 3 个副本

• 2 个不同的存储介质

• 1 个 offsite

2012 年，美国计算机应急响应组（US-CERT）推荐 321 备份策略，里面特别提到了异地备份对于从自然灾害或者严重故障恢复的重要性。于同城多活、异地多活、冷热结合等备份策略，都是 321 规则的实现或者变体。但多活策略一方面大多是 onsite 的热备设计，另外一方面业界缺乏产品化的解决方案，微博部分核心业务实现了同城与异地多活，投入了巨大的人力与资源成本，所以在全站级别容灾时，微博选择了异地快速重建的方案。

由于微博的社交媒体属性等业务特点，其对于数据丢失带来的不可用的容忍度远低于一般公司。对于社交媒体属性非常强的公司来说，数天不可用，基本就等同关站。因此，对于微博而言，备份只是手段，快速恢复才是实际需求。我们需要在遭受极端情况下在线数据完全损毁时，1 个小时内在异地重新构建完整的微博服务，同时确保数据完整性。这在整个业界都是一个前所未有的巨大挑战。为此，微博构建了数据恢复中心，为全站数据提供数据备份与极速恢复服务。

截止到 2020 年 10 月，微博月活跃用户达 5.23 亿，每天产生的各类数据已达 PB 级，核类在线业务存量数据达到 100PB 级别。这些数据分散在微博的数百个独立的业务当中，为了满足不同用户的数据展示场景，这些数据会以各种形式存在，包括图片、视频、镜像文件、MySQL、Redis、原始的二进制文件等。

面对微博复杂的业务场景、超大规模的数据量，微博数据恢复中心需要同时权衡可用性、经济成本、安全性、效率。在整个设计过程中，所有的设计策略都围绕恢复时效性展开，把数据与恢复链路中涉及的所有环节都进行标准化与自动化。

按照 80/20 原则，数据的重要性是有差异的。如果不加区分的恢复 100PB 级别的数据，无论是从成本上还是效率上都是无法承受的。微博从垂直与水平两个方向对数据的优先级进行拆分：

• 垂直层面：按业务的重要程度划分核心与非核心。核心业务的确认相对复杂，通常需要公司层面的领导拍板，但核心业务变更的频率非常低。微博上千个对外提供的 API，核心 API 只有十几个。

• 水平层面：数据的访问是有时效性的，在微博场景下表现更加明显，7 天内的数据访问量超过 98%。部分超过 1 年的数据被访问的吞吐基本维持在个位数甚至是零，简单的使用吞吐量作为数据的访问热力值，通过热力值对数据进行二次分级。

通过垂直与水平数据分级之后，核心热门数据的数据规模下降两个数量级到 PB 级别，这使得整个数据在 1 小时内重建成为了可能。

有了数据分级标准后，需要按照分级标准找出备份哪些资源。数据是由服务生产的，所有的数据都会归约到一个特定的服务，因此数据的备份转化成了服务的备份，这样就可以通过追踪流量路径依赖的方式，发现流量路径中的服务节点，从而完成个服务网络拓朴图的构建。拓扑中服务依赖关系的一个核心准则是：核心业务不依赖非核心业务。避免核心业务拓扑扇出不可控，影响数据备份的范围与可用性。

微博服务的注册通过 weibo-mesh 启动完成后自动注册构建，形成服务依赖关系拓扑，开源或者第三方资源类的服务包括 MySQL、Redis 类的数据，微博通过 resource mesh agent 发现并自动注册到所属的服务池。

不同的数据类型，备份方式各有不同。包括流量最开始入口四七层的配置、RPC 服务需要备份的二进制版本（镜像 URL）和 MySQL、Redis 等业务数据。所有接入数据恢复中心的服务，都需要提供 snapshot+streaming 两个 API。Snapshot 用于生成数据的快照，streaming 提供自上一次快照以来产生的所有的 operation。服务提供 API 后，数据恢复中心就能自动备份数据，实现备份与业务的解耦合。目前数据恢复中心提供了常用数据类型的 snapshot 与 streaming 的 API，相关业务只要上线，即可纳入数据恢复中心进行备份。

数据备份两个最基本的要求是数据的一致性与数据完整性。单个文件的数据一致性通过数据摘要进行动态存储验证，使用纠错码有效处理 bit 反转静默存储错误。

对于数据的完整性，微博使用大块存储结合 Merkle Hash Tree 来解决。所有的数据文件，都拆分或者合并成 1GB 的一个数据块（1GB 大小的块是一个最佳实践值，过小网络传输效率低，过大单个块传输耗时长，不利于提升并发效率）。一个完整的数据备份元数据由<版本号，所属业务，数据类型，数据块列表>四元组构成，数据备份服务提供 API 可以进行全网备份或者指定业务与数据类型的备份。备份 API 与业务无关，与数据类型无关。

数据备份利用 snapshot 进行全量备份，使用 streaming 支持动态增量备份。我们采用了 watch 变化的机制，数据容量累计到一定程度或者超时则会把增量数据做一次 checkpoint。snapshot 通常是天级别，checkpoint 一般是小时级。

在微博使用的资源中，一类是类似 Redis，读写量非常高，增量数据产生的 operation streaming 量非常大，但这类资源的单实例容量一般控制在 10GB 级别，可以提升 snapshot 的频率，降低两个 checkpoint 之间的数据量以提升恢复效率。另一类是 MySQL，单实例容量非常大，通常在 TB 级别，写入量较低，可以降低 snapshot 的频率，提升 checkpoint 的频率，以在存储成本与数据恢复效率上达到平稳。

数据服务服务通过 checkpoint 机制，将数据备份转换成了数据块的存储与备份。

微博在数据备份上遵循了 321 策略，1）所有的数据备份都至少包含 2 个热备，2 个冷备；2）在线热备数据存储在 SSD 设备，冷备数据存储在独立的 OSS 集群；3）数据会在异地离线存储，通过专线进行数据同步与传输。

数据备份服务存储中心选择的是在云原生场景下应用广泛的对象存储 OSS。在逻辑上，恢复中心由管理端与存储端组成，且二者逻辑上是独立的。存储端支持多物理存储，具体来说，支持在物理上各个机房内的自己 OSS 存储集群，同时还支持接入云厂商的 OSS 服务；由管理端来统一调度。管理端本身亦支持异地多活。自建存储共 8 个集群，每个小集群 7 台存储主机，单机容量 20T，单集群容量 140T， 8 个集群 1120 TB。集群对外网络带宽为 100Gbps。自建存储集群示意图如下，能够支撑 PB 级别的数据备份与快速读取。

全站异地构建主要是应对极端灾难，所有站内（onsite）的数据几乎都处于不可用状态，所有的数据恢复与构建都围绕 1 小时展开。服务构建的每一个环节都需要进行自动化处理，整个重建过程包括以下几个部分：

• 第 1 分钟：实现系统自举

• 第 13 分钟：基础设施的部署与准备

• 第 53 分钟：服务启动与数据分发

• 第 58 分钟：服务自检、自动注册与负载均衡变更

• 第 60 分钟：完成流量迁移

通过部署在 offsite 的 event-listener 收到恢复事件后，首先开启备份数据自检流程。主要包括：

1. 加载对应版本的备份元数据。元数据包含备份的整体统计信息，包括服务的版本、数量、规格以及服务依赖，用于在服务恢复时构建拓朴信息及加速分发。

2. 恢复混合云平台服务 DCP。DCP 作为混合云的 IaaS 层，后续所有的物理机资源都通过 DCP 创建。为了减少 DCP 恢复时的依赖，提升 DCP 的恢复速度，DCP 部署涉及的所有的二进制包、存储等支持单机部署，所有实例都部署在一台高配机器（256C/2TB 内存）上，可以做到 1 分钟以内完成 DCP 的恢复。

DCP 启动后作为 IaaS 设备混合云提供平台，借助云厂商 5 分钟扩容 2000 台神龙裸金属的能力，相当于 8 万台 ECS 服务器。DCP 启动后，读取备份元数据中 IaaS 设备的规格、数量，快速扩容指定数量机器，并完成包括 Docker、kuberlet 等初始化（初始化过程需要花费 2min 左右时间）。

完整的服务启动与数据分发包括服务拓朴解析、服务镜像拉取与启动以及数据分发等几个阶段。

• 服务依赖树解析

offsite 解析模块开始解析灾备待恢复服务元数据，将服务依赖关系解析到服务依赖树。各个服务树全速并行恢复，服务与资源按照存储在拓朴图中的距离就近甚至同机部署，最大程度上提升带宽吞吐，在机器上挂载磁盘时每业务一块盘，提升整体磁盘顺序写入 IO 带宽。

• 服务恢复流程

微博构建了以 Kubernetes、Docker 为代表的容器调度混合云平台，为业务提供 serverless 服务。容器调度平台可以快速适配待恢复服务所需运行时环境。为了解决待恢复服务对 CPU、内存、磁盘、带宽等五花八门运行时环境的诉求，我们将其抽象提炼到规格，根据规格匹配锁定 IaaS 层节点设备，在锁定节点上拉取镜像，启动容器服务。

• 业务数据分发

在服务恢复过程中，当容器启动后，对于同一份数据需要分发多次的场景，例如服务的应用的可执行文件、镜像，使用 P2P 的分发方式，多点并行分发，大幅提高分发效率，同时降低存储 server 的负载。

所有纳入到 weibo-mesh 管理的服务及资源，都实现了标准的回调 API：服务注册、健康检查、预热以及启动心跳保持。服务在启动完成首先会健康检查，健康检查通过后调用预热接口，避免系统冷启动导致的大量超时；冷启动完成后，服务实例会自动注册到分布式配置中心（微博自建的服务：vintage），启动心跳汇报功能完成服务的注册。

四、七层的启动过程与普通的服务并无差异，以 nginx 为例：在 nginx 完成部署部署启动后，nginx-upsync-module 会自动从分配式配置中心 vintage 同步其相关的配置并进行动态 reload，完成 upstream 的同步更新与 backend 的注册。

数据恢复中心通过检查分配式配置中心 vintage 并与服务拓朴进行比对，所有服务启动完成后，则变更出口 DNS，以实现流量的迁移，完成最终的异地构建。

微博数据恢复中心涉及十余个独立系统的密切交互，包括 1）IaaS 层的基础设施管理 DCP，抹平了公有云、自建 IDC 等异构基础设施差异，向上提供 5 分钟 2000 台机器的闪电交付能力，后续基于神龙裸金属可以提供 5 分钟相当于 8 万台机器的交付能力；2）把所有的物理机资源看成一个超大的 CPU、内存与存储池，由 KRS（自研的基于 K8S 的容器编排调度系统）实现服务的全网调度，有效利用了超大规格机器（目前重点使用 256C/2TB 规格）百 Gb 级别的高带宽吞吐等能力，实现全网服务与数据的极速分发；3）把 Redis、MySQL、RPC、代码、二进制和四七层等所有都看成资源，提供 RaaS（Resource as a Service）的抽象，每一类资源实现标准的 backup、prestop、poststart、register 等接口，都能够自动接入数据恢复中心，做到整个过程零参与；4）微博的热点联动系统在系统完成冷启动后，自动依赖流量的变更，快速扩容，完成业务的重建过程。

整个异地重建项目过程中，每一个环节都可能会成为瓶颈，包括数据备份的可靠性、基础设施的自动化部署与快速构建、基于 P2P 的数据快速分发等等。本文限于篇幅未能充分展开描述，受限于成本，目前微博也未在全站维度进行 1:1 规模进行数据异地构建与恢复的验证，接下来一段时间，微博的基础设施建设会围绕此展开。