V2EX = way to explore

V2EX 是一个关于分享和探索的地方

已注册用户请登录

这是一个创建于 2322 天前的主题，其中的信息可能已经有所发展或是发生改变。

作者丨魏旸：腾讯高级工程师，具有 15 年运维经验的专家。负责 QQ 空间、微云、QQ 空间相册等的运维工作。

12 月 16 日，首期沙龙“海量运维实践大曝光”在腾讯大厦圆满举行。沙龙出品人腾讯运维技术总监、复旦大学客座讲师、DevOps 专家梁定安，讲师腾讯手机 QQ 运维负责人郭智文，腾讯高级工程师魏旸，腾讯 SNG 资深运维专家周小军出席沙龙，并带来精彩的技术分享。为了便于大家学习，特将本次沙龙讲师的演讲内容进行了整理。您也可以在腾讯织云公众号下载本次演讲 PPT。

背景

腾讯社交业务包括 QQ、QQ 空间、QQ 相册等核心业务。核心业务按深圳、天津和上海三地分布，各支撑华南、华中、华东、华北、西北、西南等大区的用户访问。

大家都知道核心业务多地部署物理容灾，名字服务、负载均衡等手段架构容灾。但是当机房、网络等大范围故障真正发生时，我们要怎么做才能保证业务持续可用？拿前一段时间腾讯深圳某个机房光纤被挖断的案例来讲，业务碰到的问题：

机房爆炸了，会影响多少用户？
是否需要调度？
怎么调度？
天津机房覆盖范围的用户调度到哪里？调多少？
怎么调度？

带着这些问题，我简单介绍一下空间 SET 化分布异地多活方案。

为什么要做 SET ？

提升质量，提升速度，提升效率，节约成本。

业务通过 SET 化部署在多个物理机房，当某个机房故障时，我们可以快速切换服务到其他机房，可以做到物理容灾。同时，多地部署也提供了用户就近接入的能力，提升用户体验。再者，业务关联的服务部署在同一个城市或者机房，能够极大减少业务之间的机房穿越带宽，降低成本。最后，SET 的复制结合织云的快速部署能力，我们能够快速复制并在不同地域部署多个业务 SET。

SET 的属性

简单来说，SET 是一个包含了多个标准化模块的集合，同时包含了更多的业务属性，比如业务形态，核心指标，柔性策略，地域，调度策略等等。

怎么分 SET ？

横向分布与条带化的思维  海量用户按不同比例被分流到不同的专区访问。比如用户接入维度，我们划分了 PC、移动端 SET，同时在移动端我们又可以细分为安卓和苹果用户。比如运营商，比如地域分布。每一个 SET 都需要有可度量的指标，空间业务主要根据 SET 内模块负载、可支撑的用户量、和实时交易量等维度来评估一个 SET。

SET 模型

在有了可度量的 SET 标准后，我们就可以基于自己的业务形态来创建 SET 模型了。以空间为例，用户登录进空间首先会看到自己发表的历史说说，相册，好友动态等等信息，我们把这一类的业务场景划分为读数据 SET。用户会在空间上发说说，上传照片或视频，我们把这一类的业务场景划分为写数据 SET。同时深圳的 PC 或者移动端用户更新了空间，数据需要同步到其他地域的后端存储上，空间有一套专用的同步中心架构来保证数据同步。

我们基于空间的业务场景制定的一个大致的模型就是这样：根据接入层区分用户，单点写，多点读，数据同步模块保证多点读的数据一致性。

命名规范：

初步模型制定好以后，我们需要针对不同的架构和业务场景来划分不同的 SET。比如空间首屏，主要由空间的信息中心模块来负责数据拉取展现，我们把信息中心相关联的业务模块都统一划分为 I 类 SET。再根据不同的

我们还根据不同数字代表不同的地域信息和 SET 顺序。

1 ）名称分为 2 段，用“_”分割；第 1 段固定为 SET，表示专区；

2 ）第二段分为 4 节，每节占一位，前 3 位与目前规则一致：

3 ） SET 类型，简写为 A、D、B、I，分别代表接入、数据 SET、基础数据，信息中心等；

4 ）地域信息，分别有深圳，上海、西安等，用 0、1、2 分别按序增加，最多到 16 进制等

5 ） SET 数序号，从 1、2、3 开始，最多到 16 进制的 F ；

6 ）业务产品信息，即 Qzone 为各业务搭建的 SET，用一个字母代替，如 P、G、U 分别代表如 PENGYOU、3G、UGC 等

同步中心

同步中心是空间业务 SET 化能力的一个重要组件，业务数据的同步都依赖同步中心。简单介绍一下同步中心的架构：单写多度的业务讲数据接入同步中心后，同步中心通过多种技术手段保证数据同步到多地的读 SET。同步中心架构较复杂，这里主要介绍一下同步中心的有序转发：

许多业务对用户请求处理的先后顺序有很严格的要求，为了实现用户请求的有序转发，同步中心做了三个功能：

接入机转发请求到存储机使用有状态 l5，确保同一个号码的请求流水落到同一台机器上。
固定进程读取固定号段，平均分配每个进程处理的号段，并且确保同一个号码的请求由同一个进程处理。
使用半异步方式进行转发，批量读取流水，对不同号码的请求流水并发转发，对相同号码的流水进行串行转发。

空间实际的 SET 展示

SET 链路

SET 内部和不同 SET 的业务模块都是通过名字服务来相互访问的

用户层 GSLB->STGW=TGW+Nginx，Nginx 自动获取 vip

接入->逻辑：L5，vip->l5 名字服务。负载均衡的时候有过载保护

逻辑->存储：L5。Stgw 和 L5 都是腾讯自研的路由、名字服务组件。调度都是基于名字

服务来实施。L5 有 SET 化的标签，可以让 SET 的服务配置文件保持一致的情况下，服务只在 SET 内调度。可以极大提升 SET 的部署效率。

SET 容量管理：

指定好的 SET，需要通过压测来找出 SET 内业务模块资源的最优配比。我们会通过调度现网用户来对 SET 做压测，通过压测找出 SET 内某个模块的短板并及时调整资源配比。同时，随着 SET 内模块服务的升级，服务性能也在变化，我们会定期做调度演习来压测 SET 的完整链路，及时更新 SET 内模块的资源配比，可支撑用户数等 SET 核心指标。

SET 的部署和扩容

在制定好 SET 模型，明确了每个 SET 可以支撑多少用户量，对应的业务场景，包含了多少个模块，可以支撑多少用户后，就可以开始着手 SET 部署了。每个 SET 建立一个模板，录入 SET 内包含的模块，模块内服务、权限、文件等信息保持一致，不同 SET 的配置不同

SET 的复制根据 SET 模板快速部署。这些信息最后会同步到织云，由织云来快速部署服务。一个 SET 内几十个模块，几百台服务器可在 10 分钟内完成自动化部署上线。

SET 的监控

针对 SET 内不同的业务架构，业务形态，我们也开发了配套的监控工具。

SET 的调度

前面主要说了为什么要做 SET，怎么做，以及怎么维护和监控，回到深圳机房光纤被挖断的问题上来，我们是怎么做的？

每个 SET 都有可衡量的指标，模块设备的平均负载都在 40%左右。

如果网络故障影响到了用户接入 W01 SET，我们会调整 stgw 将用户转移到部署在另一个机房的 W02 SET。如果 W01 访问 I01 故障，我们可以把 W01 的访问切换到 W02。如果整个深圳机房都不可访问，我们则会把请求切换到上海、天津的 SET 中。

柔性策略：

重大活动期间，用户量可能会突增几倍甚至十几倍，靠堆设备不现实。我们针对这类场景制定了柔性策略，当 SET 容量达到一定的标准时，比如 CPU 负载达到 70%，我们就会开启业务的柔性策略，牺牲用户部分非核心功能体验来保证业务整体可持续可用。柔性策略有分级，SET 容量没达到一个标准就会自动启用不同的柔性策略。