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，有比较完善的自动化驾驶功能。
加载中,请稍侯......