本文来自微信团队工程师张文瑞的技术分享，由InfoQ编辑发布，下文有修订和改动。原文地址：infoq.cn/article/1-billion-bonus-from-the-clouds，感谢原作者的分享。
一、引言
与传统意义上的红包相比，手机端的红包似乎更符合现在年轻一代的习惯。这其中，以春节发红包最为流行。以微信为例，除夕全天微信用户红包总发送量可以达到百亿个，红包峰值收发量为比百万个/秒。
本文将由微信团队工程师张文瑞分享微信春节摇一摇红包技术背后的方方面面，希望能给同行们带来启发。
二、分享者
张文瑞：微信高级工程师，微信接入系统负责人。一直从事后台系统设计开发，早期涉足传统行业软件，后投身互联网。作为微信最早的后台开发之一，见证了微信从零开始到逐渐发展壮大的过程。
王鹏程：微信支付商户系统开发组组长，专家工程师。2008 年加入腾讯，6 年的电商经验，做过 c2c、b2b2c、b2c 及 erp，2 年第三方支付开发经验。
张文瑞还分享了微信其它方面的技术文章，您也可能感兴趣：
- 《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
- 《快速裂变：见证微信强大后台架构从0到1的演进历程（二）》
- 《社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等》
三、系列文章
❶ 系列文章目录：
- 《社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等》
- 《社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进》
- 《社交软件红包技术解密(三)：微信摇一摇红包雨背后的技术细节》（* 本文）
- 《社交软件红包技术解密(四)：微信红包系统是如何应对高并发的》
- 《社交软件红包技术解密(五)：微信红包系统是如何实现高可用性的》
- 《社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践》
- 《社交软件红包技术解密(七)：支付宝红包的海量高并发技术实践》
- 《社交软件红包技术解密(八)：全面解密微博红包技术方案》
- 《社交软件红包技术解密(九)：谈谈手Q春节红包的设计、容灾、运维、架构等》
- 《社交软件红包技术解密(十)：手Q客户端针对2020年春节红包的技术实践》
- 《社交软件红包技术解密(十一)：最全解密微信红包随机算法(含演示代码)》
- 《社交软件红包技术解密(十二)：解密抖音春节红包背后的技术设计与实践》
- 《社交软件红包技术解密(十三)：微信团队首次揭秘微信红包算法，为何你抢到的是0.01元》
❷ 其它相关文章：
- 《技术往事：“QQ群”和“微信红包”是怎么来的？》
- 《QQ 18年：解密8亿月活的QQ后台服务接口隔离技术》
- 《月活8.89亿的超级IM微信是如何进行Android端兼容测试的》
- 《开源libco库：单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]》
- 《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
- 《微信技术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》
- 《如何解读《微信技术总监谈架构：微信之道——大道至简》》
- 《微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]》
- 《微信异步化改造实践：8亿月活、单机千万连接背后的后台解决方案》
- 《微信朋友圈海量技术之道PPT [附件下载]》
- 《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》
- 《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
- 《快速裂变：见证微信强大后台架构从0到1的演进历程（二）》
- 《微信“红包照片”背后的技术难题》
- 《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
- 《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
四、摇一摇红包系统组成
红包系统由三部分组成：
- 1）信息流；
- 2）业务流；
- 3）资金流。
这三部分在组织架构上由不同的后台团队完成：
- 1）信息流——微信后台；
- 2）业务流——微信支付后台；
- 3）资金流——财付通后台。
在平时，红包系统主要处理个人会话中以消息形式发出的红包，其中：
- 1）信息流主要包括用户操作背后的请求通信和红包消息在不同用户和群中的流转；
- 2）业务流是用户请求引发的包红包、抢红包和拆红包等的业务逻辑；
- 3）资金流则是红包背后的资金转账和入账等流程。
微信红包系统在春节除夕活动时和平时的实现不大一样。在除夕活动时，除了个人红包外，红包系统还要处理由后台通过摇一摇集中下发的大量企业红包。这里边信息流的实现变化较大。
接下来简单介绍一下 2016 年除夕活动时的红包系统架构。
如上图所示，摇一摇红包系统架构包括三个方面：
- 1）资源预下载；
- 2）摇红包；
- 3）拆红包。
资源预下载：
在除夕，用户通过摇一摇参与活动，可以摇到红包或其他活动页，这些页面需要用到很多图片、视频或 H5 页面等资源。在活动期间，参与用户多，对资源的请求量很大，如果都通过实时在线访问，服务器的网络带宽会面临巨大压力，基本无法支撑；另外，资源的尺寸比较大，下载到手机需要较长时间，用户体验也会很差。因此，我们采用预先下载的方式，在活动开始前几天把资源推送给客户端，客户端在需要使用时直接从本地加载。
摇 / 拆红包：
除夕的摇一摇子系统是专门为活动定制的，按时间轴进行各项活动，这里边最重要、同时也是请求量最大的是摇红包。从需求上看，系统需要完成两件事：用户可以通过摇一摇抢到红包，红包金额可以入到用户的支付账户。在除夕，系统需要在很短时间内将几十亿个红包发放下去，对性能和可用性要求很高。考虑到涉及资金的业务逻辑比较复杂，还有很多数据库事务处理，耗时会比较长，于是我们将抢红包（信息流）和红包的账务逻辑（业务流和资金流）异步化。将前一部分处理流程尽可能设计得轻量，让用户可以很快抢到红包，然后再一步完成剩下的账务逻辑。
那么，抢红包阶段是怎样做到既轻量又可靠呢？
1）零 RPC 调用：
在微信后台系统中，一般情况下客户端发起的请求都是通过接入服务转发给具体的业务服务处理的，会产生 RPC 调用。但对于摇一摇请求，我们将摇一摇逻辑直接嵌入接入服务中，接入服务可以直接处理摇一摇请求，派发红包。
2）零数据库存储：
按一般的系统实现，用户看到的红包在系统中是数据库中的数据记录，抢红包就是找出可用的红包记录，将该记录标识为属于某个用户。在这种实现里，数据库是系统的瓶颈和主要成本开销。我们在这一过程完全不使用数据库，可以达到几个数量级的性能提升，同时可靠性有了更好的保障。
- 1）支付系统将所有需要下发的红包生成红包票据文件 ;
- 2）将红包票据文件拆分后放到每一个接入服务实例中；
- 3）接收到客户端发起摇一摇请求后，接入服务里的摇一摇逻辑拿出一个红包票据，在本地生成一个跟用户绑定的加密票据，下发给客户端；
- 4）客户端拿加密票据到后台拆红包，后台的红包简化服务通过本地计算即可验证红包，完成抢红包过程。
3）异步化：
用户抢到红包后不会同步进行后续的账务处理，请求会被放入红包异步队列，再通过异步队列转给微信支付后台，由微信支付后台完成后续业务逻辑。
五、大规模集群中保证数据一致性
事实上网络分裂很难从根本上避免，我们在设计系统时都是假设网络分裂一定会出现，基于此思考应该采用什么方案保障系统在网络分裂时能正常运作。
我们的方案是在每个数据中心都建设三个独立的数据园区，可以做到在任意一个数据园区出现网络分裂等故障，甚至彻底变成园区孤岛后，另外两个数据园区可以无损承接整个数据中心的请求。
三园区容灾的关键就是数据一致性：我们需要做到在分裂出去的那个数据园区的数据在其他园区有个强一致的副本，这样请求落到其他两个园区后，可以无损完成服务。
此外在故障园区恢复后，数据在所有园区还能自动保持相一致。
微信后台实现了基于 Quorum 算法，对数据有强一致性保证的存储系统——KvSvr（这一存储系统，详见：《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》、《快速裂变：见证微信强大后台架构从0到1的演进历程（二）》）。
此外还有可以提供三园区强一致保证的可靠异步队列，这次就应用在这个红包系统中。前边提到的部署在接入服务的红包文件实际上也是可以实现三园区容灾的，我们在每台接入服务部署的红包文件都会在其他数据园区有个备份。在某个数据园区故障时，我们可以在其他数据园区发放故障园区的红包。
通常活动红包总量非常大，活动形式也更丰富，我们会在以下方面做优化。
1）服务性能：
为提升各个服务模块的处理性能，我们通过压测和 Profiler 分析，发现了不少性能瓶颈点，做了大量优化。
2）业务支撑能力：
支持更加复杂的业务场景，并在客户端和服务器都加入了很多可以后期灵活调整的预埋能力，以更好地服务产品运营。
3）可用性：
不断提升系统可用性是我们一直努力的目标，以下 5 点很好地提高了系统的可用性。
[3.1] 系统容量评估与配额
对系统的容量需要有个准确的评估与验证，并结合业务设计合理的配额方案和降级方案，尽可能保障系统不会过载。例如，我们评估并验证完系统每秒最大拆红包量后，就可以在处理用户摇一摇请求时，限制系统每秒最大发放红包配额，这就间接保证了拆红包量不会超出处理能力。
[3.2] 过载保护
服务如果出现过载了，必须有能力自保，不被压垮，并且不扩散到系统其他的服务。我们在后台的服务框架层面具备通用的过载保护能力：服务如果处理不过来，就按请求的优先级尽快丢掉超出处理能力的请求，保证服务的有效输出；上游调用端在部分服务实例过载时，能自动做负载均衡调整，将请求调整到负载较低的服务实例中；上游调用端发现大部分服务实例都出现过载，也可以主动丢掉部分请求，减轻后端服务器的负担。
[3.3] 减少关键路径
减少核心用户体验所涉及的步骤和模块，集中力量保证关键路径的可用性，从而在整体上提高可用性。我们把活动红包的信息流和业务流进行异步化，就是基于这个考虑。跟用户核心体验相关的抢红包操作，在信息流中的接入服务、红包简化逻辑服务和红包异步队列（入队）这三个服务模块参与下即可完成。这三个服务模块是可以比较容易用较低成本就做到高可用的，可以较好地规避业务流和资金流中几十甚至上百个服务模块可能出现的风险。
[3.4] 监控指标
我们需要对系统的真实负载情况有准确及时的了解，就必须要有一套高效、可靠的监控系统，同时还要有一套有效的监控指标，监控指标不是越多越好，太多了反而会影响判断，必须要有能准确反映问题的几个核心指标。在我们系统里，这些核心指标一般在基础框架集成，根据经验来看，其中一个很有用的指标是服务的最终系统失败。
我们把服务的失败分为两类：逻辑失败和系统失败。系统失败一般是服务暂时不可用导致，是可通过重试来自动解决的，如果请求重试若干次仍然为系统失败，就产生最终系统失败。通过最终系统失败通常可以快速定位到异常的服务，及时进行处置。
[3.5] 人工介入
我们在红包系统内预置了很多配置开关，当自动运作的过载保护无法发挥预期作用时，可以通过人工介入，使用这些保底的手动开关迅速降低负载、恢复服务。
六、技术创新
实际上，类似的这种活动用到的技术都是现成的，并不复杂。但为什么大家会觉得很难实现呢？
主要是因为规模：用户和请求的并发规模越大，就越难在系统的成本和可用性上达到平衡，也就是说越难实现一个低运营成本、高服务可用性的系统。
在传统的应对这种有很大规模用户参与的活动的实现方案里，一般会采用在客户端过滤请求，以某种概率（基于时间或互动次数）发到服务器进行处理，这样服务器的压力可以大幅降低。
我们认为还可以做得更好，在这种活动的技术方案上可以有所突破——在保持低成本的前提下，全量处理用户的每次交互。这就大大降低了客户端的实现风险（因为客户端的更新和覆盖周期相对较长）。此外，服务器有了对用户交互有了全面的控制能力和灵活调整的能力。
这些能力对活动的运营是非常可贵的。可以让我们在活动过程中，各种复杂用户场景下，都能做到精细的调整，给了产品运营很大的灵活性，以保证活动效果和用户体验。看看下面两个例子。
我们可以精确控制和调整每次用户交互出现什么结果，曝光哪个赞助商；
活动过程中，有个很难预估的因素——参与人数。说不准参与的用户少了（或互动次数少了），导致红包很久都发不完？或者参与的用户多了（或互动次数多了），导致需要加快发放速度，更快速发完红包？
于是我们对这个技术方案做了全面的思考和设计，最终实现了现在这个系统，可以用很低的成本实现极高的性能和可用性，在除夕活动中得到了成功的应用。
七、服务降级方案
我们曾经对摇一摇 / 朋友圈红包照片在 2016.1.26 的预热活动和 2016.2.7 的正式活动都做了详细的复盘。包括活动过程中各项业务数据是否符合预期，各个模块的表现是否符合预期等，并分析各种不符合预期表现的成因和解决措施。
在红包系统的信息流、业务流和资金流都有很多保障用户核心体验的降级方案。举几个信息流的降级方案的例子。
a） 如果某一个数据园区出现网络分裂等故障，完全不可用了，部署在那里的红包怎么发下去？
红包文件虽然在园区间有冗余存储，但基于性能和可用性考虑，我们并不打算在各园区间维护相一致的红包发放记录，做到记录级的“断点续发”，而是将红包文件按时段进行切分，降级为只做文件级的“断点续发”。在某个园区不可用时，使用降级方案后，故障园区当前发放时段的红包文件不会接着发放，仅保证下一时段的红包能通过其他园区正常发出去。
b）活动过程中，如果用户的交互量超过服务的处理能力了怎么办？
正如前面所述，我们很难准确估计参与用户量及互动次数。就本次活动而言，在系统设计之初，我们评估有 2000 万次 / 秒的峰值请求，并在系统最终实现和部署时预留了一定的余量，提供了评估值 2.5 倍（也就是 5000 万次 / 秒峰值请求）的系统处理能力，除夕当晚服务器处理请求峰值达到 2500 万次 / 秒，服务实际负载低于 50%。但如果当时用户过多，互动过于火爆，到达后台的请求超过 5000 万次 / 秒，系统就会进入降级模式，客户端可以在服务器的控制下，减少请求，防止服务器过载。
c）红包发放速度过快，后端处理不过来怎么办？
正如前面所述，用户抢红包是在信息流完成的，完成后请求放到红包异步队列再转到业务流。如果领取红包请求量过大，队列会出现积压，红包的入账会出现延时，但不会导致用户请求失败。
类似的降级方案还有很多，每个环节都有若干个不同的降级方案，有些是针对业务专门设计的（如 a 和 b），还有些是使用基础组件 / 服务 / 方案本身就具备的降级能力（如 c）。这些方案都遵循着一个原则：降级时，尽可能保证用户的核心体验。
八、资金与红包准备的难点
除夕活动资金和红包准备的难点总体来说有以下 4 点。
1）红包的数量：
- a. 由于招商的不确定性，最终投入微信摇企业红包的资金不可准确预估；
- b. 不同的商户其对品牌的曝光量的需求不同，有的要求多曝光，有的要求多关注，红包金额或大或小，数量则或多或少；
- c. 从准备到除夕当天，期间各种变化，活动方案变数很多。
红包的数量可能从几亿到几百亿变化，资金与红包的准备需要能够满足需求的巨大变化。
2）资金的就位:
- a. 企业各行各业，营销经费的审批流程不尽相同，资金最终支付到位时间前后差异很大，甚至有些在除夕前一周才会最终敲定支付到账；
- b. 某些企业可能在最后阶段停止合作；
- c. 某些企业可能在最后阶段调整资金的使用方式。
以上情况会导致资金的到位时间不完全可控，本着尽可能多的资金能够投入到活动中的原则，希望可以尽可能压缩活动的准备时间，让更多的资金能够上车。
3）资金预算的配置方案（资金剧本）：
- a. 按设想的活动方案，红包会分为三大类：图片红包、视频红包、品牌 logo 红包。活动方案较去年又有新的变化，特别是 logo 红包的认知度和接受度不确定，logo 红包过度会否导致未领完而浪费资金，不容易确定 logo 红包的资金占比；
- b. 除夕当天的活动剧本可能会反复调整优化，红包时段的划分可能修改，不同时段的资金投放量可能变化。
大笔资金、大量的红包、复杂的活动方案、善变的商户要求，都可能反复调整，如果面对百亿量级的红包配置调整时，技术上如何实现缩短准备时间，支持方便的变化。
4）资金的安全：
- a. 如何防止红包的金额被篡改；
- b. 如何防止未被领取的红包被入账给用户；
- c. 如何防止红包金额重复入账给用户；
- d. 如何防止机器被攻破产生了不存在的红包；
- e. 如何防止红包被不同用户重复领取；
- f. 如何在确保资金安全的情况下尽可能保证用户的到账体验（最好是实时或准实时到账）。
技术上必须做万无一失的准备，确保资金足够安全，活动顺利完成。
九、微信摇企业红包全过程
如果在除夕当天摇的过程中按前边提到的超级复杂的配置方案即时生成随机红包，这显然是风险齐高逻辑奇复杂的。对待只许成功不许失败的项目，主流程必须极简高效，所以这里全部的资金和红包数量都需要按方案规则提前切分和准备好。
将预生成好的红包数据（预红包数据）进行准确的部署，摇红包的资金和红包准备的整体流程方案有两个选择。
方案一：预红包数据提供部署给微信的接入机和写入红包 DB，摇红包过程由红包接入机控制红包的发放，拆红包时修改红包 DB 中的红包数据；
方案二：预红包数据只提供部署给微信接入机，摇红包过程由红包接入机控制红包的发放，拆红包直接 Insert 到红包 DB。
第二个方案减少一次 DB 操作，如果是百亿量级的红包数据，可以极大减少数据导入、对账等活动准备时间，特别是方案需要变更时。
十、充足准备
10.1对资金预算和资金剧本进行合理的建模
首先，面对如此大量的资金和复杂的资金剧本，如何准确高效地管理和控制逻辑呢？要杜绝傻大黑粗，我们需要一个优雅的解决方案——建模。
对资金预算和资金剧本进行合理的建模，让模型涵盖、掌管、控制一切——让工具基于模型进行自动化的处理和校验。
这里需要做的就是：
- 1）落地该模型的设计，让一切围着模型转；
- 2）按规定的格式文件导入预算和配置，并进行数据和逻辑合理性校验；
- 3）一切利用工具进行处理，资金的支付、退款、红包的随机生成和多商户随机打散、预红包文件分割、预红包数据的校验，减少人为过程导致的潜在失误；
- 4）优化红包随机算法和文件处理方法，将红包随机分割和多商户随机打散算法的 n^2 时间复杂度优化 n，压测 30 亿红包的生成时间为 2~3 小时，极大缩减准备时间，增加方案调整的回旋时间，可以让更多的资金上车。
其次，前边提到方案有如此多的变数、调整、变更，如何支持？还是回归模型，建模时就要考虑支持同样的预算多套资金配置方案。
同样的资金预算，同时或依次生成多套预红包数据文件，提前做多手准备，方便方案变更。
再次，如此大量的资金就意味着如此大量的诱惑，会不会出问题呢？
- 1）方案预红包数据未提前落地 DB，导致拆红包时缺少一次红包数据有效性的检验；
- 2）预红包数据存放在微信接入机上，存在被攻陷获取或篡改的可能；
- 3）红包数据在传输的过程中存在系统异常或恶意攻击，导致数据错误特别是金额错误的可能；
- 4）系统内部可能存在恶意人员直接调用拆红包的接口写入不存在的红包。
墨菲定律要求我们必须重视以上安全隐患，解决方案就是加密——对预红包数据进行加密，加密库和解密库独立维护保证密钥不被泄露，通过工具生成预红包数据时用密钥进行加密，预红包数据在部署存储和传输的过程中保持加密状态，仅在拆红包的逻辑中编译二进制紧密库进行解密。
同时，鸡蛋也不能放在一个篮子里，为了控制密钥泄露导致的影响，确保资金风险可控，整个预生成的红包数据可能分别使用了几百到几千个密钥进行加密，一个密钥加密的红包资金量在 20~30 万。解密库还需要能设置密钥 ID 的白名单和黑名单，确保未被使用的密钥不能被利用，确认泄露的密钥可以进行拦截。
10.1极限压缩
如果是百亿个红包，那么产生预红包数据文件的大小不经过压缩是非常恐怖的，传输部署几百 GB 或几 TB 的数据是很艰苦的，一旦发生调整变更会变得非常艰难，所以需要对数据进行极限的压缩。
数据进行极限的压缩的实施内容：
- 1）对于支付单号、商户号、红包账户等信息，由工具导成配置文件，配置到拆红包逻辑中，加密的红包数据中仅用一个批次 ID 表达；
- 2）拆分红包 ID，部分分段同样转为 ID，解密库解密后利用配置进行还原；
- 3）加密部分（Ticket）：红包 ID、金额、批次 ID、密钥 ID，压缩到 16 字节；
- 4）单条红包记录二进制表达，压缩到 26 字节。
10.2对账
上面所有都做到就安全了么？真的就有人写了一个不存在红包进来会怎样？是否还有其他未考虑到的潜在风险？所以我们需要一个兜底——对账，把一切都要对清楚才放心。
对账后再入账的时效在 30~60 分钟，会造成不好的用户体验。为了提升用户体验，将大额的预红包数据（占比 10% 左右）导入 KV（高速缓存），拆红包时进行即时校验，即时进行转账入账，未命中 KV 的红包则等待对账后异步完成入账。
主要要点有：
- 1）资金配置与资金预算要总分对账；
- 2）红包数据文件与资金剧本进行总分对账；
- 3）红包数据进行全局去重验证；
- 4）红包数据进行解密验证和金额验证；
- 5）如果密钥泄露红包金额等被篡改，兜底要进行红包 DB 中已拆红包数据与预红包数据的对账后，才能实际进行转账入账。
十一、本文小结
未来我们可能还继续会有类似的活动，虽然我们已经有了一个经过实践的可复用的技术方案，接下来我们希望能够继续优化，并实现一些可复用的模块和服务，可以快速应用到下一次活动或者其他业务场景中。例如，我们在当初的 2015 年春节首次完成除夕活动后，就把其中的资源预下载系统进行了完善和通用化，随后应用在多个业务场景和后来的 2016 年除夕活动中。未来可以有更多类似的系统和服务可以被复用和通用化。（本文已同步发布于：http://www.52im.net/thread-2533-1-1.html）
附录1：有关微信、QQ的文章汇总
[1] QQ、微信团队原创技术文章：
《微信朋友圈千亿访问量背后的技术挑战和实践总结》
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)》
《微信团队分享：微信移动端的全文检索多音字问题解决方案》
《腾讯技术分享：Android版手机QQ的缓存监控与优化实践》
《微信团队分享：iOS版微信的高性能通用key-value组件技术实践》
《微信团队分享：iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的？》
《腾讯技术分享：Android手Q的线程死锁监控系统技术实践》
《微信团队原创分享：iOS版微信的内存监控系统技术实践》
《让互联网更快：新一代QUIC协议在腾讯的技术实践分享》
《iOS后台唤醒实战：微信收款到账语音提醒技术总结》
《腾讯技术分享：社交网络图片的带宽压缩技术演进之路》
《微信团队分享：视频图像的超分辨率技术原理和应用场景》
《微信团队分享：微信每日亿次实时音视频聊天背后的技术解密》
《QQ音乐团队分享：Android中的图片压缩技术详解（上篇）》
《QQ音乐团队分享：Android中的图片压缩技术详解（下篇）》
《腾讯团队分享：手机QQ中的人脸识别酷炫动画效果实现详解》
《腾讯团队分享 ：一次手Q聊天界面中图片显示bug的追踪过程分享》
《微信团队分享：微信Android版小视频编码填过的那些坑》
《微信手机端的本地数据全文检索优化之路》
《企业微信客户端中组织架构数据的同步更新方案优化实战》
《微信团队披露：微信界面卡死超级bug“15。。。。”的来龙去脉》
《QQ 18年：解密8亿月活的QQ后台服务接口隔离技术》
《月活8.89亿的超级IM微信是如何进行Android端兼容测试的》
《以手机QQ为例探讨移动端IM中的“轻应用”》
《一篇文章get微信开源移动端数据库组件WCDB的一切！》
《微信客户端团队负责人技术访谈：如何着手客户端性能监控和优化》
《微信后台基于时间序的海量数据冷热分级架构设计实践》
《微信团队原创分享：Android版微信的臃肿之困与模块化实践之路》
《微信后台团队：微信后台异步消息队列的优化升级实践分享》
《微信团队原创分享：微信客户端SQLite数据库损坏修复实践》
《腾讯原创分享(一)：如何大幅提升移动网络下手机QQ的图片传输速度和成功率》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（下篇）》
《腾讯原创分享(三)：如何大幅压缩移动网络下APP的流量消耗（上篇）》
《微信Mars：微信内部正在使用的网络层封装库，即将开源》
《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
《开源libco库：单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]》
《微信团队原创分享：Android版微信从300KB到30MB的技术演进》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《微信技术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]》
《微信异步化改造实践：8亿月活、单机千万连接背后的后台解决方案》
《微信朋友圈海量技术之道PPT [附件下载]》
《微信对网络影响的技术试验及分析（论文全文）》
《一份微信后台技术架构的总结性笔记》
《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《快速裂变：见证微信强大后台架构从0到1的演进历程（二）》
《微信团队原创分享：Android内存泄漏监控和优化技巧总结》
《全面总结iOS版微信升级iOS9遇到的各种“坑”》
《微信团队原创资源混淆工具：让你的APK立减1M》
《微信团队原创Android资源混淆工具：AndResGuard [有源码]》
《Android版微信安装包“减肥”实战记录》
《iOS版微信安装包“减肥”实战记录》
《移动端IM实践：iOS版微信界面卡顿监测方案》
《微信“红包照片”背后的技术难题》
《移动端IM实践：iOS版微信小视频功能技术方案实录》
《移动端IM实践：Android版微信如何大幅提升交互性能（一）》
《移动端IM实践：Android版微信如何大幅提升交互性能（二）》
《移动端IM实践：实现Android版微信的智能心跳机制》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《移动端IM实践：iOS版微信的多设备字体适配方案探讨》
《信鸽团队原创：一起走过 iOS10 上消息推送(APNS)的坑》
《腾讯信鸽技术分享：百亿级实时消息推送的实战经验》
《IPv6技术详解：基本概念、应用现状、技术实践（上篇）》
《IPv6技术详解：基本概念、应用现状、技术实践（下篇）》
《腾讯TEG团队原创：基于MySQL的分布式数据库TDSQL十年锻造经验分享》
《微信多媒体团队访谈：音视频开发的学习、微信的音视频技术和挑战等》
《了解iOS消息推送一文就够：史上最全iOS Push技术详解》
《腾讯技术分享：微信小程序音视频技术背后的故事》
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《微信多媒体团队梁俊斌访谈：聊一聊我所了解的音视频技术》
《腾讯音视频实验室：使用AI黑科技实现超低码率的高清实时视频聊天》
《腾讯技术分享：微信小程序音视频与WebRTC互通的技术思路和实践》
《手把手教你读取Android版微信和手Q的聊天记录(仅作技术研究学习)》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
《腾讯技术分享：GIF动图技术详解及手机QQ动态表情压缩技术实践》
《微信团队分享：Kotlin渐被认可，Android版微信的技术尝鲜之旅》
《社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等》
《社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进》
《社交软件红包技术解密(三)：微信摇一摇红包雨背后的技术细节》
>>更多同类文章 ……
[2] 有关QQ、微信的技术故事：
《技术往事：微信估值已超5千亿，雷军曾有机会收编张小龙及其Foxmail》
《QQ和微信凶猛成长的背后：腾讯网络基础架构的这些年》
《闲话即时通讯：腾讯的成长史本质就是一部QQ成长史》
《2017微信数据报告：日活跃用户达9亿、日发消息380亿条》
《腾讯开发微信花了多少钱？技术难度真这么大？难在哪？》
《技术往事：创业初期的腾讯——16年前的冬天，谁动了马化腾的代码》
《技术往事：史上最全QQ图标变迁过程，追寻IM巨人的演进历史》
《技术往事：“QQ群”和“微信红包”是怎么来的？》
《开发往事：深度讲述2010到2015，微信一路风雨的背后》
《开发往事：微信千年不变的那张闪屏图片的由来》
《开发往事：记录微信3.0版背后的故事（距微信1.0发布9个月时）》
《一个微信实习生自述：我眼中的微信开发团队》
《首次揭秘：QQ实时视频聊天背后的神秘组织》
《为什么说即时通讯社交APP创业就是一个坑？》
《微信七年回顾：历经多少质疑和差评，才配拥有今天的强大》
《前创始团队成员分享：盘点微信的前世今生——微信成功的必然和偶然》
《即时通讯创业必读：解密微信的产品定位、创新思维、设计法则等》
《QQ的成功，远没有你想象的那么顺利和轻松》
《QQ现状深度剖析：你还认为QQ已经被微信打败了吗？》
《[技术脑洞] 如果把14亿中国人拉到一个微信群里技术上能实现吗？》
《QQ和微信止步不前，意味着即时通讯社交应用创业的第2春已来？》
《那些年微信开发过的鸡肋功能，及其带给我们的思考》
《读懂微信：从1.0到7.0版本，一个主流IM社交工具的进化史》
《同为IM社交产品中的王者，QQ与微信到底有什么区别》
《还原真实的腾讯：从最不被看好，到即时通讯巨头的草根创业史》
>>更多同类文章 ……
附录2：更多架构方面的文章汇总
[1] 有关IM架构设计的文章：
《浅谈IM系统的架构设计》
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》
《一套原创分布式即时通讯(IM)系统理论架构方案》
《从零到卓越：京东客服即时通讯系统的技术架构演进历程》
《蘑菇街即时通讯/IM服务器开发之架构选择》
《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》
《微信后台基于时间序的海量数据冷热分级架构设计实践》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《17年的实践：腾讯海量产品的技术方法论》
《移动端IM中大规模群消息的推送如何保证效率、实时性？》
《现代IM系统中聊天消息的同步和存储方案探讨》
《IM开发基础知识补课(二)：如何设计大量图片文件的服务端存储架构？》
《IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议》
《IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token》
《WhatsApp技术实践分享：32人工程团队创造的技术神话》
《微信朋友圈千亿访问量背后的技术挑战和实践总结》
《王者荣耀2亿用户量的背后：产品定位、技术架构、网络方案等》
《IM系统的MQ消息中间件选型：Kafka还是RabbitMQ？》
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《以微博类应用场景为例，总结海量社交系统的架构设计步骤》
《快速理解高性能HTTP服务端的负载均衡技术原理》
《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实践之路》
《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
《新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》
《一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践》
《阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史》
《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路》
>>更多同类文章 ……
[2] 更多其它架构设计相关文章：
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《快速理解高性能HTTP服务端的负载均衡技术原理》
《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实践之路》
《新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》
《阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史》
《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路》
《达达O2O后台架构演进实践：从0到4000高并发请求背后的努力》
《优秀后端架构师必会知识：史上最全MySQL大表优化方案总结》
《小米技术分享：解密小米抢购系统千万高并发架构的演进和实践》
《一篇读懂分布式架构下的负载均衡技术：分类、原理、算法、常见方案等》
《通俗易懂：如何设计能支撑百万并发的数据库架构？》
>>更多同类文章 ……
热门跟贴