微信背后不为人知的一场巨变：他们如何「把年夜 象搬进冰箱」？
2020 年 1 月中，距离春节不到 1 周的时间，微信技术架构负责人 Stephen Liu 异常 焦虑，即将到来的年夜 年节 夜是一年傍边 微信业务最为忙碌 的时刻，好几亿的用户会在这个时刻发送新年祝福以及微信红包，微信办事 器也经受着一年比一年更年夜 的冲击。为了保障所有人都能如期收到新年祝福，抢到微信红包，微信技术团队在每年年底进入「春节保障」模式，进行办事 器压力测试，确保微信不失落 链子。
最症结 的时刻，很棘手的问题
然则 在这一个春节的测试阶段，却出了问题。
出生 于 2014 年的微信红包，在昔时 春节期间就经历过不年夜 不小的宕机，部分用户在部分时间领不了红包，也看不了红包金额。次年，微信拿下了春晚的告白 互动权。那一年年夜 年节 当日中国微信红包收发总量达 10.1 亿次，春晚微信摇一摇总量达 110 亿次，这一年微信准备充分，年夜 体上还算平稳，偶有小范围 宕机。
因此，还没到春节就涌现 测试问题，不是个好现象。
Stephen Liu 说：
我们其时 想压测的（目标）值年夜 概是每分钟下发的消息数有几十亿条，然则 我们压测到的水平只有目标的一半，其时 离春节只有两个星期了。
所谓压测，就是对微信线上的办事 器做扩容。扩容完之后，然后进行进击 性模拟，模拟在年夜 年节 零点那一刻的峰值数据，看看今年有可能比去年增加若干 ，然后把那个量完全模拟出来，压到系统上面去。
简单理解，就是类似于网站对自己进行 DDoS 进击 ，测试网站能经历若干 人同时拜访 而不宕机。更通俗的理解是餐厅接客，淡季一家餐厅的座位和厨师只能同时接待 100 位客人，然则 旺季的时候，可能同时有 300 位客人需要就餐，这个时候就需要提前扩建餐厅招聘厨师了，也就类似于「扩容」，或者实在不可 就让客人在外面排队等位。
但微信收发消息是不克不及 采取 排队等位方法 的。
微信技术团队和 Stephen Liu 这次遇到的问题就似乎 明明扩建了餐厅多招了厨师，然则 同时能接待的客人只有 150 位，没有达到 300 名的目标，并且这个时候厨师都还挺闲，座位也很空，外面还有人排队。
微信技术团队在此之前已经核查了年夜 概一两周时间，终于定位到问题：网卡性能涌现 了问题。再打个比方说，就是像是餐厅门口的接待员偷懒，没把客人往屋里带，导致餐厅里面坐不满，外面客人排长队。
问题背后，是一场微信不为人知的巨变
之所以往年压测没问题，这一年压测有问题，涉及到微信背后的一场巨变：自研上云。
这场巨变从 2018 年腾讯的 930 变革开始，2018 年 9 月 30 日，腾讯再次对公司架构进行年夜 调剂 ，原有七年夜 事业群重组整合，新成立云与智慧家当 事业群（CSIG）、平台与内容事业群（PCG）。其中 CSIG 承担着腾讯 ToB 的宏伟愿景，而微信事业群（WXG）则是连接了最广年夜 的 C 端用户。
云，对于腾讯来说已经是战略支点业务，从此时开始，自有业务自研上云成为业务调剂 的重要事项，而微信业务自研上云则是重中之重。
在腾讯 930 变革之前，腾讯并未给内部自研业务提供统一的云基础设施，而是采取 物理机办事 器的模式。宏不雅 上讲，考虑到微信巨年夜 的用户量和业务量，自研上云能够带来巨年夜 的成本和效率优势，对微信和腾讯云两个业务都有利益 。
但微不雅 上讲，一个涉及到 10 多亿用户的业务要做如此巨变，并且要让用户无感，就似乎 需要给高速行驶的汽车换轮子，车不克不及 停，甚至都不克不及 波动 ，同时轮子也要换。
前面压测涌现 问题，就涌现 在换轮子的进程 中。
实际上，轮子也确实到了该换的时候了，Stephen Liu 说：
2014 年微信只是一个部分 。其时 公司提了这么一个成本优化的想法的时候，我们自己还挺紧张的，因为其时 部分 的人不是很多，其时 只是一个部分 ，那个时候也就三四百号人。在 2014 年之前，微信所有的人力都扑在做功能迭代，赓续 打磨新的功能，所以对于后台的办事 器用得怎么样，包含 架构做得怎么样，对这些存眷 得比较少。
那公司又有这个要求，后来公司就支配 了人对每个业务部分 去看做得怎么样，最后选派了异常 有经验的人。像其时 带队的也是公司的 VP，横竖 我异常 有印象，因为我被他批了很多次。就说微信这边的成本异常 高，你们办事 器用得欠好 。
▲ 微信曾经的申报PPT
这次降本增效的要求促使了微信团队第一次进行办事 器架构的优化，其时 采取 了名为 YARD 的系统架构。
然则 这次自研上云则需要和腾讯公司坚持 一致，采取 开源的 K8S 系统架构，相比于 YARD，K8S 架构更为开放，在适配人工智能和年夜 数据框架等等方面有先天优势。而现在微信的诸多功能都与人工智能和年夜 数据有关，比如语音转文字，还有文字翻译功能。
或者说， 2014 年微信采取YARD 架构目的很简单，就是赞助 灵活调剂 办事 器资源，节省成本，并未考虑更庞杂 更久远 ，而其时K8S 也没有开源。
随着业务成长 时间前行，K8S 架构的优势逐渐盖过架构迁移的阵痛，又恰逢腾讯业务变革，这场转变 势在必行。
微信基础架构工程师 Edsel Wang 告诉爱范儿微信自研上云的宏不雅 步调 ：
对于微信团队来说，上云可以分成狭义和广义两个层面。狭义的上云就是 2018 年 930 变革，公司 930 变革之后公司推动了自研上云这件事情，然后微信开始使用公司提供的统一的云基础设施。广义上上云，就是微信把整个研发模式逐渐云原生化，这里就不纯真 包含 把一些后台的办事 从原来的物理机搬到云上，当然这里还包含 整个研发进程 会跟云做一个结合。
针对 2018 年 930 变革之后，公司推动自研上云这件事情到目前为止也是经历了两个阶段。第一个阶段是 2018 年到 2020 年这个时间点，公司主要转变 了提供办事 器的方法 ，就是从原来提供物理机改为 CVM（Cloud Virtual Machine，云虚拟机）。第二个阶段的时间点是从 2020 年开始，公司进一步要求各个业务部分 把内部的一些调剂 系统统一改为 K8S，这个对我们来说，就是从 YARD 迁移到 K8S 上。 在第一个阶段，从原来的物理机改为使用 CVM 这一块，由于我们设计了 YARD 作为它的调剂 层，所以我们的主要工作是让 YARD 适配云，因为 YARD 原来是支持物理机的，现在就是 YARD 支持 CVM 虚拟机，而业务层是不需要做很多转变 的。
在第二个阶段，对于微信团队来说，就是要用 K8S，就是用腾讯云提供的 K8S 集群的调剂 能力替代失落 自研的 YARD 平台。为了使这个迁移加倍 顺滑，我们在用 K8S 替代 YARD 进程 中计划 了三步走。 第一步，首先要解决微信能不克不及 上 K8S 跑的问题，那个法度模范 能不克不及 上去跑的问题。第二步是要把 YARD 原来积累的一些经验移植到 K8S，让 K8S 跟 YARD 原来的能力对齐，可以接着使用原来 YARD 提供的所有能力。第三步，我们要充分施展K8S 的能力，因为前两步 YARD 提供的我们都提供了，第三步我们就要更充分地使用 K8S 的能力，这块主要体现在成本、效率上。
2020 年之前我们就完成了前两步，从 2020 年的下半年我们开始年夜 范围 使用 K8S，2021 年开始进入到了第三步。从目前看，我们的成本和研效都有了进一步的提升，相对于原来 YARD。 还有从广义上云的角度来说，之前推动上 CVM 虚拟机这一块，微信团队还有一个标记 性的事件，就是存储团队也在上云这一块有了一个突破，因为微信一直用的是自研的存储系统，在曩昔 十年我们经历了很多不合的 DB（Data Base，数据库）还有 KV（Key-Value，一种数据库系统），最终在 infinityKV 的版本实现了存储上云的能力。在 2020 年下半年，infinityKV 开始上线，微信后台年夜 概有 80% 的数据存储在现在的 infinityKV 这个新系统里面的。
这是我提到的微信上云（进程 ），就是把年夜 象搬进冰箱有几步（的进程 ）。
Edsel Wang 进一步介绍了 YARD 逐渐显现的局限性，在 2014 年的时候整个行业对于云平台的界说 都不是很清晰，另外一方面，腾讯的硬件环境跟现在的云硬件的环境有比较年夜 的区别。YARD 是在其时 那一种硬件环境下研发和设计的，导致它在一些核心能力上比如磁盘和网卡的虚拟化，是有所欠缺的。
开头微信在自研上云进程 中涌现 的压测问题，就定位在了网卡这里，原因是腾讯云其时 使用了一个新的机型，CVM 操作系统和硬件的适配还不敷 好。
最后，微信技术架构团队通过曲线救国的办法 ，短暂地解决了 CPU 负载小，然则 网卡性能涌现 瓶颈的问题。简单讲，就是如果原来办事 器整机 CPU 有 180 个核心，切片之后 90 个核心配 1 个网卡，结果网卡负载满了，CPU 负载只有 20% 左右。微信技术架构团队重新对 CPU 核心进行切分，改成 48 个 CPU 核心对应 1 个网卡，让 CPU 负载过半，充分利用性能的同时，网卡负载也不到瓶颈。
这是治标的办法，这是治标的办法，治本的办法就是 CVM 优化网卡调剂 法度模范 。CVM 网卡调剂 法度模范 优化加上迁移到 K8S，让微信后台能够更有效地控制网络流量，进一步提升了微信后台安排 的灵活性和稳定性。
变更 弗成 怕，可怕的是不变更
2013 年的时候，微信涌现 了时长最久的宕机。因为有挖掘机挖断了通信光缆，导致华东数据处理中心的业务请求纷纷转向华南和华北，进而导致长达 5 个多小时的微信办事 瘫痪。
自此，在次年安排YARD 架构的时候，微信做了一个重要功能：三园区支持。就是在每个城市建造三个机房（园区），机房的网络和电力自力 ，哪怕其中一个被挖断光纤，还有另外 2 个作为支持。
这就是 现在办事 器安排 中常见的「冗余」概念。
现在自研上云之后，不但 是办事 器资源虚拟化了，新的 K8S 架构能够更进一步，办事 器资源属于腾讯整个公司，这个资源量级就年夜 多了，「冗余」也更多了。这就像贷款一样，之前微信是从市级支行贷款，现在则是从省总行贷款。
在微信迄今 11 年的历史中，微信的界说 也是在赓续 变更 的。朋友圈，微信红包，小法度模范 ，视频号等等节点性的功能一次次让微信的界说 拓展，它是社交网络，是支付对象 ，也是内容平台。
微信背后的办事 器支撑，也正是面对的这样一个赓续 变更 的进程 。
早些时候，北京的一场初雪导致本地 用户拼命发朋友圈也会导致办事 器需求瞬时加年夜 ，这种时候就需要响应很快的扩容。
但某地的天气变更 和用户行为是难以预期的，春节和年夜 年节 夜零点集体发红包是一种必定 ，类似的必定 还有很多，比如周杰伦的演唱会视频号直播，数千万的不雅 看是对微信办事 器的巨年夜 考验，但这是可以进行压力测试，提前安排 的。
回忆起去年 9 月的一场直播，视频号后台开发工程师 Bok Zhou 依旧觉得惊险。
他介绍说，得益于上云之后的优势，遇到这种预期外的流量剧增，微信团队也可以更快地上线更多办事 器资源，避免部分用户看不了直播。
自研上云也是个历久 且赓续 变更 的进程 ，优势也会慢慢挖掘出来，现在也不是这个进程 的终点，但有些优势和愿景已经可以预料。
微信技术架构负责人 Stephen Liu 说：
在一年多以前我跟团队有分享过一个不雅 点，我就拿自动驾驶 5 个 Level 来类比。Level 0 是人工驾驶，完全没有自动化。Level 1 是有一些驾驶帮助 ，Level 2 是更强的驾驶帮助 ，Level 3 已经具备一定的自动驾驶能力了，然后还有 Level 4 和 Level5。
我的一个希望，就是将来能够杀青 像自动驾驶一样，将来春节保障的时候能够完全由机器来自动驾驶。我们几年前可能在 Level 0。后来有了 YARD 之后，是 Level 1。经过 2021 年整个去挖掘 K8S 的各类 能力之后，我觉得我们现在应该处在 Level 2 状态。我希望接下来能够到 Level 3，有比较完善的自动化驾驶功能。
页:
[1]