0 到 1：微信后台系统的演进之路

0 到 1：微信后台系统的演进之路

从无到有

2011.1.21 微信正式发布。这一天距离微信项目上线日期大约还有 2 个月。这 2 个月，微信从无到有成长，你可能会好奇这段时间微信后台最重要的事情是什么？我认为应该是以下三件事：

1. 确定微信的消息模型

微信最初被定位为一种通讯工具，通讯工具的核心功能是发送和接收消息。微信团队起源于广汇团队，消息模型也和邮箱的邮件模型有很强的关系，两者都是存储和转发的。

图 1 说明了这种消息模型，其中消息在后台临时发送和存储。为了让接收者更快地收到消息，消息通知会推送给接收者;最后，客户端主动从服务器接收消息。

2. 制定数据同步协议

由于用户的帐户、联系人和消息都存储在服务器上，因此如何将数据同步到客户端成为一个关键问题。为了简化协议，我们决定使用统一的数据同步协议来同步用户的所有基础数据。

初始方案是客户端记录本地数据的快照（），当数据需要同步时，会带到服务器，服务器会计算与服务器数据的差值，将差值数据发送给客户端，客户端会保存差值数据以完成同步。但是，这种方案存在两个问题：一是会随着客户端数据量的增加而越来越大，同步时流量开销会很大;其次，每次同步都需要计算 ，这将带来额外的性能开销和实现复杂性。

经过几次讨论，方案改为由服务计算，客户端同步数据时，数据随数据一起交付给客户端，客户端不需要理解，只需存储起来，下次同步数据时带上就行了。同时，它被设计得非常精简，它是几个 key-value 的组合，key 代表数据类型，value 代表提供给客户端的数据的最新版本号。有三个键，分别代表：帐户数据、联系人和消息。这种同步协议的另一个好处是，在客户端同步了数据之后，不需要额外的 ACK 协议来确认数据接收成功，还可以保证数据不会丢失：只要客户端将最新的数据带到服务器进行数据同步， 服务器可以确认最后的数据已经同步成功，并可以进行后续操作，例如清除临时存储在服务中的消息等。

此后，简化方案、减少流量开销、尝试由服务器完成更复杂的业务逻辑、降低客户端实现的复杂度一直是重要的指导原则，不断影响着微信后续的设计开发。记得一个经典案例：我们在微信 1.2 版本中实现了群聊功能，但是为了保证客户端新旧版本之间的群聊体验，我们采用了服务器适配，允许 1.0 版本客户端参与群聊。

3. 后端架构已经敲定

微信后端采用三层架构：接入层、逻辑层、存储层。

1. 接入层提供接入服务，包括长连接服务和短连接服务。长连接服务支持客户端发起请求和服务器发起推送。如果连接到服务的短连接，则只有客户端可以发起请求。

2. 逻辑层包括业务逻辑服务和基础逻辑服务。业务逻辑服务封装了业务逻辑，是后台提供给微信客户端的 API。基本逻辑服务抽象化了较低级别和通用的业务逻辑，并提供对业务逻辑服务的访问。

3. 存储层包括数据访问服务和数据存储服务。数据存储服务通过 MySQL 和 SDB（广研早期后端广泛使用的 Key-Table 数据存储系统）等底层存储系统持久化用户数据。数据访问服务将数据访问请求适配并路由到不同的底层数据存储服务，为逻辑层提供结构化数据服务。特别之处在于，微信后台中每种不同类型的数据都使用单独的数据访问服务和数据存储服务，例如帐户、消息、联系人等。

微信后端主要使用 C++。后台服务是使用框架构建的，服务通过同步 RPC 相互通信。

它是广言后端已经存在的另一个高性能 RPC 框架，当时并没有被广泛使用，但在微信后端大放异彩。作为 后端基础设施中最重要的部分，它多年来一直在发展。我们构建了数千个服务模块，提供了数万个服务接口，每天进行数十万亿次 RPC 调用。

这三件事都产生了深远的影响，即使在 5 年后的今天，我们仍然继续使用原来的架构和协议，甚至支持原来的 1.0 版微信客户端。

这里有一个教训 – 运营支持系统真的很重要。第一版微信后台匆忙完成，当时只完成了基本的业务功能，没有配套的业务数据统计等等。我们开放注册后，一时间没有业务监控页面和数据曲线可看，从数据库中临时统计注册用户数，从日志中提取在线用户数，通过每小时运行一次的脚本统计数据（这个脚本也是当天临时添加的）， ，然后自动向邮件列表发送电子邮件。还有各种其他通过邮件发布的商业数据，可以说是微信早期最重要的数据门户。

1月

2011 年 21 日，最高并发在线连接数为 491 个，而今天这个数字是 4 亿个。

小步慢跑

在微信发布后的 4 个多月里，我们经历了发布后热注册的惊喜，也经历了此后一直不温不火的困惑。

在此期间，微信做了很多旨在增加好友数量并允许用户聊天的功能。打开腾讯微博私信、群聊、工作邮件、QQ/邮件好友推荐等。后端最重要的变化是这些功能产生了对异步队列的需求。例如，微博私信需要对接外部部门，不同系统之间的处理时间和速度不同，因此可以通过队列进行缓冲。群聊是一个耗时的操作，消息发送到群后，可以通过异步队列异步完成消息的传播和写入。

图 4 显示了异步队列在群聊中的应用。微信的群聊是 and ，这意味着发送到群的消息将为群中的每个人保存一个副本（消息索引）。为什么不阅读 呢？这有两个原因：

1. 群里的人不多，群里的人数上限是 10 人（后来逐渐增加到 20、40、100，现在是 500），扩散的成本不会太大，不像微博，粉丝上千。

2. 消息传播写入大家的消息存储（消息收件箱）后，接收者在后台同步数据时，只需要查看自己的收件箱，同步逻辑与单条聊天消息一致，这样数据同步过程就可以统一，实现会非常轻量级。

异步队列作为后端数据交互的重要模式，已经成为对同步 RPC 服务调用的有力补充，在微信后台得到广泛应用。

快速增长

微信的快速发展始于 2.0 版本，该版本发布了语音聊天功能。此后，微信用户数量快速增长，2011 年 5 月用户数量超过 100 万，2011 年 7 月超过 1000 万，2012 年 3 月注册用户超过 1 亿。伴随着令人满意的结果，也带来了一堆快乐的烦恼：

快速业务迭代的压力

微信发布的时候，功能非常简单，主要功能就是发送消息。不过，在语音之后的少数几个版本中，手机通讯录、离线留言、查看附近人、摇一摇、漂瓶和朋友圈等功能很快就被引入。

关于 的开发，有一个广为流传的传说 - 花了 4 个月的时间和 30 多次迭代才最终成型。其实还有一个鲜为人知的故事——当时，由于人员紧张，朋友圈的后台很长一段时间里只有 1 个开发者。

对后台稳定性的要求：用户越多，功能越多，后台模块的数量和机器的数量不断翻倍，随之而来的是各种故障。

什么

帮助我们度过这个阶段的是：

1. 极简设计

虽然满足了需求，但我们的每一个实施都一丝不苟。实现需求的最大困难不是设计一个解决方案并实施它，而是在几种可能的解决方案中选择最简单、最实用的一种。这往往需要经过几轮思考、讨论、推翻的迭代过程，规划后行动有很多好处，一方面可以避免浮华的过度设计，提高效率;另一方面，经过详尽的讨论，仔细关注细节，看似简单的解决方案往往是最可靠的解决方案。

2. 大系统小工作

起初，逻辑层的业务逻辑服务只有一个服务模块（我们称之为 mmweb），它包括了所有提供给客户端访问的 API，甚至还有一个完整的微信官网。该模块的架构类似，由一个 CGI 容器 （） 和几个 CGI （每个 CGI 都是一个 API）组成，只是每个 CGI 都是一个动态库，因此它是动态加载的。

当 mmweb 上的 CGI 数量比较少时，这个模块的架构是完全足够的，但是当功能迭代加速，CGI 数量增加时，问题开始出现

每个 CGI 都是一个动态库，当一些 CGI 的公共逻辑的接口定义发生变化时，在不同时间更新和启动的 CGI 可能会使用不同版本的逻辑接口定义，这会导致运行时出现奇怪的结果或进程崩溃，并且很难定位;

所有的 CGI 都放在一起，每次发布和推出一个大版本，从测试到灰度再到全面部署都是一个非常漫长的过程，几乎所有的后端开发者都会同时卡在这个环节，这极大地影响了效率;

新的不太重要的 CGI 有时不稳定，一些异常的分支会崩溃，导致进程无法使用，向这些重要的 CGI 发送消息会受到影响，无法运行。

因此，我们开始尝试一种新的 CGI 架构——。

基于框架。框架和 CGI 逻辑经过静态编译，以生成可以使用 HTTP 直接访问的 URL。我们将 mmweb 模块拆分为 8 个不同的服务模块。拆分的原理是实现不同业务功能的 CGI 被拆分成不同的功能，相同的功能但重要程度不同的也被拆分。例如，作为核心功能的消息发送和接收逻辑，拆分为三个服务模块：消息同步、文本和语音消息、图片和视频消息。

每个 都是独立的二进制文件，可以单独部署和独立启动。如今，有数十个微信后端，提供数百种 CGI 服务，部署在数千台服务器上，每天有数千亿次客户访问。

除了 API 服务，其他后端服务模块也遵循“大系统做小事”的实践原则，微信后端服务模块的数量从微信发布时的 10 个左右迅速增加到数百个模块。

3. 业务监控

在此期间，有很多后端故障。比故障更麻烦的是，因为缺乏监控，我们往往无法在第一时间发现一些故障，导致故障的影响被放大。一

方面，缺乏监控是由于在快速迭代过程中，强调了功能开发的重要性，而低估了业务监控的重要性。另一方面，基础设施对业务逻辑监控的支持较弱。该基础设施提供对机器资源的监控和对服务运行状态的监控。这是每台机器和服务的标准配置，不需要额外的开发，但是业务逻辑的监控要麻烦得多。当时，业务逻辑监控是通过业务逻辑统计功能完成的，需要 4 个步骤才能实现一次监控

申请日志报告资源;

在业务逻辑中增加日志上报点，日志将由每台机器上的 Agent 收集并上传到统计中心。

统计代码的开发;

实现统计信息监控页面。

可以想象，这种耗时费力的模式反过来会降低开发者加入业务监控的积极性。于是有一天，我们去了公司里面的标杆，也就是通过后台（Back ）来学习经验，发现解决方案出奇的简单和强大：

1） 故障报告

在之前的每次失败之后，QA 都会带头生成一份失败报告，该报告的重点是评估失败的影响和对失败进行评级。新的方法是，每次故障不分大小，开发人员需要彻底审查故障流程，然后商定解决方案，并辅以详细的技术报告。本报告重点介绍如何避免同类型故障的再次发生，提高主动发现故障的能力，缩短故障响应和处理流程。

2） 基于 ID 值的业务无关监控和警报系统

这

监控系统的实现思路非常简单，它提供了两个 API，允许业务代码为共享内存中的监控 ID 设置或累积值。每台机器上的 Agent 会定期将所有 ID- 上报给监控中心，监控中心在汇总存储数据后，可以通过统一的监控页面输出监控曲线，并通过预先配置的监控规则产生告警。

对于业务代码，您只需在需要监控的业务流程中调用监控 API，并配置告警条件即可。这大大降低了开发监控告警的成本，并且我们完成了各种监控项目，以便能够及时主动发现问题。新开发的功能也会预先加入相关的监控项，这样在少量的灰色阶段，就可以通过监控曲线直接了解业务是否达到预期。

4、KVSvr

微信后台中的每个存储服务都有自己独立的存储模块，该模块彼此独立。每个存储服务由一个服务访问模块和一个底层存储模块组成。业务访问层将业务逻辑层和底层存储隔离，并提供基于 RPC 的数据访问接口。底层存储有两种类型：SDB 和 MySQL。

SDB 对于以用户的 UIN 作为键的数据存储非常有用，例如消息索引和联系人。优点是性能高，在可靠性方面，它提供了基于异步流水线同步的 -slave 模式，并且在发生故障时，slave 可以提供读取数据服务，无法写入新的数据。

由于微信账号是字母 + 数字的组合，不能直接作为 SDB 的密钥，因此微信账号数据并不存储在 SDB 中，而是存储在 MySQL 中。MySQL 还使用基于异步流复制的 -slave 模式。

的版本 1 每个使用 1 个 -Slave。提供了读写功能，Slave 不提供服务，仅用于备份。当出现故障时，手动读服务切换到 slave，无法提供写服务。为了提高访问效率，我们还在业务访问模块中增加了缓存服务，以减少对底层存储的访问。

服务与版本 2 中的 -slave 的区别在于，slave 可以提供读服务，但有可能读取脏数据，因此一致性要求较高的业务逻辑，比如 、login logic，只允许访问。当出现故障时，它只能提供读服务，不能提供写服务。

的版本 3 使用一个或多个从属节点来解决读取服务的水平可扩展性问题。

底层存储版本 4 使用多个 -slave 组，每个组由一个或多个 slave 组成，解决了写服务容量不足时的横向扩展问题。

最后，还有一个未解决的问题：-slave 组的单点故障不能提供单点故障，这意味着单点故障无法消除。此外，-slave 的同步延迟对读服务影响很大，流中较大的延迟会导致服务失败。KVSvr 正在寻找一种底层存储解决方案，该解决方案可以提供高性能、水平读/写扩展、无单点故障、读/写灾难恢复和强大的一致性保证。

KVSvr 基于分布式数据使用强一致性算法，为 Key-Value/Key-Table 模型提供存储服务。传统算法的性能并不高，KVSvr 创造性地将数据的版本与数据本身区分开来，将算法应用于数据版本的协商，然后通过基于流水线同步的异步数据复制，提供强大的数据一致性保证和极高的数据写入性能。

KVSvr 解决了我们当时迫切需要的灾难恢复功能。除了 版本 5 之外，所有 SDB 底层机箱和大多数 MySQL 底层机箱很快都切换到了 KVSvr。随着业务的增长，KVSvr 不断发展并演变成各种定制版本，以满足业务需求。今天，KVSvr 作为核心存储仍然发挥着关键作用。

平台化

2011.8 世界大运会在深圳举行。微信上线了“深圳大运志愿者服务中心”服务账号，微信用户可以搜索“szdy”将此服务账号添加为好友，获取会议相关信息。当时后台对“szdy”做了特殊处理，当用户搜索时，会随机返回 10 个微信账号中的 1 个“”，“...，”“”，并且每个微信账号背后都有一个志愿者来服务。2011.9 “微成都”落户微信平台，微信用户可以搜索“”添加好友，成都市民也可以在“附近的人”中看到这个号码，我们在后台为这个账号做了一些特殊的逻辑，可以支持后台自动回复用户发送的消息。

随着需求越来越大，我们开始做一个媒体平台，后来从微信后台分离出来，演变成微信公众平台，独立发展，开始了微信的平台化。除了微信公众平台，微信后台的外围也出现了微信支付平台、硬件平台等一系列平台。

出国

微信走出国门的尝试始于 3.0 版本。从这个版本开始，微信逐渐支持繁体中文、英文等多种语言。不过，真正具有标志性的事情是第一个海外数据中心的投入使用。

1. 海外数据中心

海外数据中心的定位是一个自治系统，即功能齐全，可以独立运行，不依赖国内数据中心。

1） 多数据中心架构

无状态接入层和逻辑层的系统自治很简单，所有业务模块都可以部署在海外数据中心。

但是存储层遇到了大麻烦——我们需要保证国内数据中心和海外数据中心能够独立运行，但不能保证两个孤立的系统单独部署，各自发挥作用，而是一组业务功能可以完全互通的系统。所以我们的任务是保证两个数据中心之间的数据一致性，而且架构是必须的，即两个数据中心都需要是可写的。

2） - 存储架构

- 下的数据一致性是一个大问题。两个数据中心之间的网络延迟很高，这意味着看似一劳永逸的解决方案（例如直接在数据中心之间使用 Paxos 算法，或直接部署基于 KVSvr 的解决方案）并不适用。

最后，我们选择了类似于 Yahoo！的 PNUTS 系统的方案，需要对用户集合进行拆分，所有数据写入操作都必须完成回国内数据中心供国内用户使用。海外用户只能在海外数据中心写入。从整体存储来看，这是一种 - 架构，但具体到用户的数据上，就是 -slave 模式，每条数据都只能在用户所属的数据中心写入，然后异步复制到其他数据中心。

3） 数据中心之间的数据一致性

此体系结构可实现不同数据中心之间的最终数据一致性。如何保证在这种数据弱一致性保障下，业务逻辑没有问题呢？

这个问题可以分为 2 个子问题：

用户访问自己的数据：

用户可以在世界各地运行，因此是否允许用户访问最近的数据中心对业务处理过程有很大影响。如果允许就近访问，同时保证数据一致性，不影响业务，这意味着要么可以动态改变用户数据的需求;要么需要仔细梳理所有业务逻辑，严格区分数据中心内和跨数据中心的用户请求，并将请求路由到正确的数据中心进行处理。

考虑到与这些问题相关的实施和维护的高度复杂性，我们将每个用户限制在其家庭数据中心进行操作。如果用户漫游，他们漫游到的数据中心会自动将用户引导回主数据中心。

这样，用户访问自己数据的一致性问题就很容易解决了，因为所有操作都仅限于家庭数据中心，保证了他们的数据强一致性。此外，还有一个额外的好处：用户自己的数据（例如消息和联系人）不需要在数据中心之间同步，这大大降低了数据同步的带宽要求。

用户对其他用户数据的访问：

由于不同数据中心之间需要业务通信，用户将使用其他数据中心用户创建的数据。例如，您可以参与其他数据中心用户创建的群聊，查看其他数据中心用户的朋友圈。

仔细分析可以发现，大多数场景对数据一致性的要求并不高。如果您稍后看到自己被添加到其他数据中心用户或朋友创建的群组中，看到朋友的 更新，这并不重要。在这些场景中，业务逻辑直接访问数据中心中的数据。

当然，仍然有一些场景需要高数据一致性。例如，如果您为自己设置了一个 账号，则该 账号在整个 账号系统中需要是唯一的。我们提供全球唯一的微信账号申请服务来解决这个问题，所有数据中心都通过此服务申请微信账号。这种情况需要特殊处理，很少是问题或太大的问题。

4） 可靠的数据同步

数据中心之间存在大量的数据同步，数据是否能够最终一致取决于数据同步是否可靠。为了保证数据同步的可靠性，提高同步的可用性，我们开发了基于算法的排队组件，每个组件由 3 个存储服务组成。与一般队列不同，该组件大大简化了队列写入操作，三机存储服务之间不需要相互通信，每台机器上的数据是按顺序写入的，执行写入操作时，3 函数写入 2 份副本成功;如果失败，请在另一个组中重试。因此，此队列可以实现极高的可用性和写入性能。每个数据中心将需要同步的数据写入到该数据中心的同步队列后，另一个数据中心的数据回放服务将数据拉取并重放，以达到数据同步的目的。

2. 网络加速

海外数据中心建设周期长，投资大，微信只有香港和加拿大两个海外数据中心。但世界如此之大，即使是这两个数据中心，也依然无法辐射到全世界，让各个角落的用户都能享受到流畅的服务体验。

通过海外的实际对比测试发现，微信客户端在消息等一些主要使用场景下，与主要竞品存在较大差距。为此，我们与公司的架构平台部、网络平台部、国际业务部合作，围绕海外数据中心（包括信令加速点和图像 CDN 网络）精心挑选和构建了全球数十个 POP 点。此外，通过对移动网络的深入分析和研究，我们还大大优化了微信的通信协议。微信最终在比较测试中赶上并超越了其主要竞争对手。

集约农业

1. 三个园区的灾难恢复

2013.7.22 微信发生了有史以来最大的中断，消息和朋友圈等服务中断长达 5 小时，期间消息量下降了一半。故障的原因是上海其中一个数据中心园区的主光纤被切断，近 2000 台服务器不可用，导致整个上海数据中心（当时是国内唯一的数据中心）的服务瘫痪。

如果发生故障，我们曾尝试切断有权访问故障校园的用户，但收效甚微。尽管数百个在线模块专为灾难恢复和冗余而设计，但单个服务模块似乎没有单点故障。但整体来看，无数的服务实例分散在数据中心内各个数据中心的 8000 多台服务器中，每个服务的 RPC 调用复杂且呈网状状，再加上缺乏系统级规划和容灾验证，最终导致故障被主动恢复。以前，我们知道单个服务故障不会影响系统，但没有人知道当 2000 台服务器同时不可用时，整个系统会发生什么。

事实上，在这次失败的 3 个月前，我们已经在努力解决这个问题。当时，上海数据中心的内网切换异常，导致微信意外故障，13 分钟的时间里，微信消息几乎完全无法使用。在分析故障时，我们发现消息系统中一个核心模块的三个服务实例部署在同一个数据中心。数据中心的交换机故障导致服务整体不可用，消息降至零。这个服务模块是最早的核心模块（当时微信的后端很小，大部分后端服务都部署在一个数据园区），而且服务基于 3 机冗余设计，年复一年地可靠运行，以至于大家完全忽略了这个问题。

为了解决类似的问题，三校区容灾应运而生，目标是将上海数据中心的服务均匀部署到三个物理隔离的数据园区，这样微信在任何一个校区整体发生故障的情况下，仍然可以提供无损服务。

1） 同步服务

传统的数据中心级容灾方案是“两城三中心”，即同一个城市有两个数据中心，同一个地方建另一个容灾中心，三个数据中心中只有一个有可能提供在线服务，然后在发生故障时将业务流量切换到其他数据中心。这里的主要问题是，灾备数据中心没有实际的业务流量，当主数据中心发生故障时，可能无法正常切换到灾备中心，而且平时没有提供大量的备份资源，也会造成大量的资源浪费。

三个校区的容灾核心是三个数据校区同时提供服务，所以即使一个校区出现故障，另外两个校区的服务流量也只会各增加 50%。另一方面，每个园区只需要保留 2/3 的服务器资源最大容量，并且可以预留 1/3 的容量以提供无损容灾能力，而传统的“两城三中心”则有更多的服务器资源闲置。此外，在正常情况下，三个园区同时提供外部服务，所以当我们失败时，我们需要解决的问题是“如何切断业务流量到其他数据园区”，而不是“我们能不能把业务流量削减到其他数据园区”，前者显然是一个更容易解决的问题。

2） 数据高度一致

这

三个校区容灾的关键是存储模块需要将数据均匀分布在三个数据园区之间，并且不同园区必须有两个以上相同数据的一致副本，以保证任何一个园区在灾难发生后都能提供不间断、无损的服务。由于后台的大部分存储模块都使用 KVSvr，因此该解决方案也相对简单高效——每 1 组 KVSvr 机器均匀分布在 3 个园区。

3） 发生故障时自动切换

三个校区的容灾难点是故障业务的自动屏蔽和切换。即业务逻辑服务模块可以准确识别出一些下游服务实例不再可访问，然后快速自动切换到其他服务实例，避免被拖死。我们希望每个业务逻辑服务都能做出自己的决策，在没有外部辅助信息帮助的情况下（比如搭建中心节点，通过中心节点下发每个业务逻辑服务的健康状态），自动将业务流量分发给其他服务实例。此外，我们还构建了一套人工操作的全局屏蔽系统，当大型网络出现故障时，可以人工干预屏蔽一个园区的所有机器，并迅速将业务流量分散到另外两个数据园区。

4） 灾难恢复效果测试

在完成上海数据中心和海外香港数据中心三个园区的建设后，我们进行了多次实战演练，将数千个业务屏蔽在一个园区，以测试灾难恢复效果是否达到预期。特别地，为了防止某个核心业务模块因为一段时间内的更新而不再支持三个校区的容灾，我们还构建了容灾拨测系统，每天对所有服务模块主动屏蔽某个校区的服务，并自动检查整体服务故障量是否有变化， 从而持续测试三个校区的容灾效果。

2. 性能优化

过去，当我们的业务快速发展时，我们优先支持业务功能的快速迭代，没有时间考虑性能问题。2014 年，公司开始大幅降低运营成本，性能优化被提上日程。我们基本上已经重新设计和实现了大部分的服务模块，并进行了有针对性的优化，这仍然可以节省大量的机器资源。但更有效的优化措施是基础设施的优化，特别是框架的优化。框架几乎广泛应用在所有的服务模块中，如果框架层面能够充分利用机器资源，肯定会事半功倍。

重点是可以在不破坏原始业务逻辑代码结构的情况下使用这个协程组件，使得我们原始代码中使用同步 RPC 调用的代码可以通过协程直接异步化，无需任何修改。框架直接集成了这个协程组件，然后一件美好的事情发生了，原来在单个实例中最多提供数百个并发请求处理能力的服务，在启动重编程后，眨眼间就能提供数千个并发请求处理能力。框架的底层实现在这段时间也是全新的，服务的处理能力大大提升。

3. 防雪崩

我们并没有太担心一个 实例的失败，导致实例完全无法提供服务，这在后台服务的灾备系统中是可以处理得很好的。最大的恐惧是雪崩：由于某种原因导致服务过载，导致请求处理时间显著增加。导致服务的吞吐量降低，大量请求在服务的请求队列中积压时间过长，导致上游服务访问服务超时。更遗憾的是，上游服务经常重试，然后重载服务的一点处理能力就没用了（也就是处理完后返回结果的时候，调用者超时后已经放弃了），最后重载的服务彻底雪崩了。最坏的情况是，上游服务的每个请求都耗时过长，以至于雪崩会沿着 RPC 调用链向上传播，最终单个服务模块的过载会导致大量服务模块的雪崩。

在我们勒紧裤腰带以节省机器资源并淘汰低负载机器后，所有机器的负载都出现了，服务过载变得频繁发生。解决这个问题的一个有力的解决方案是框架中的 QoS 保证机制，它可以快速拒绝超过服务自身处理能力的请求，即使在过载时也能提供稳定有效的输出。

4. 安全加固

近年来，互联网安全事件时有发生，各种拖车层出不穷。为了保护用户的隐私数据，我们构建了一套数据保护系统——全流程工单系统。核心方案是用户登录后，后台会给客户端下发一张 ，每次客户端请求时，客户端都会带来 ，并且在后台服务的整个处理链中，所有对核心数据服务的访问都会验证该 是否合法， 非法请求将被拒绝，从而保证用户的隐私数据只能由用户通过自己客户端发起的操作来访问。

新的挑战

1. 资源调度系统

微信后台有数千个服务模块，部署在全球数万台服务器上，一直依赖人工管理。此外，微信后台主要提供实时在线服务，业务高峰和低谷之间每天的服务器资源占用差异很大，计算资源浪费在业务的低谷中。另一方面，许多离线大数据计算受到计算资源不足的制约，难以高效完成。我们正在试验和部署的资源调度系统（Yard）可以自动化机器资源的分配和服务的部署，以及离线任务的调度，从而实现资源的优化分配，并在业务对服务资源的需求发生变化时，自动实现服务的重新配置和部署，更加及时、灵活。

2. 高可用性存储

基于该算法，KVSvr 实现了强一致性、高可用性和高性能的 Key-Value/Key-Table 存储。近日，微信后台诞生了另一个基于 Paxos 算法的存储系统，第一个是 SQL 存储，它支持全 MySQL 功能，具有强一致性、高可用性、高性能等特点。