Gmail的第一位产品经理Paul Buchheit说，最好的产品会让人一旦用上，就再无法想象没有它们的生活。这句话一直贯彻在全球接近20亿用户的Gmail身上，而如果在中国找一个样本，微信再恰当不过。

一个在中国生活却没有微信帐户的人现在已足够成为一个故事，但一个国民产品的煎熬也在于此。6月16日上午，微信支付短暂出现异常即上了热搜，在它身上发生的任何闪失都会引发一种集体性的不适。这种谨慎让微信无法成为一款在功能上嗅觉灵敏的产品。

但它仍然需要主动求变以跟上这个时代，只是对于微信的开发团队来说，这是一条试错空间极窄的路。人们无法回到没有微信的时候，而微信最好也不要提醒他们。

这样的事情在2013年发生过，上海某施工队的一敲让那时候“仅有”的3亿用户在接近5个小时里不能收发信息。这条底线在2020年的春节前夕又被拉紧过一次，如果2013年那次是被动的意外，两年前的试探则是不得不。

彼时的微信正在离开物理服务器，处于一切转向虚拟与云的中途。1月中旬的一场“春节保障”压力测试中，微信团队对虚拟服务器进行扩容后的攻击性测试，结果服务器在同时访问数量才到预计一半的时候就到了极限。那年的除夕夜是1月24日，这个问题如果在两个星期内解决，意味着新年钟声敲响之前，整个微信可能将会再一次大规模宕机。

暗涌最终没有浮出水面，现在提起那一天的微信，偶尔会有人记得那天是专属红包封面第一次上线，一切相安无事。

930变革后，开源协同和自研上云成为腾讯新的战略方向，也同样成为微信上云的契机。微信是腾讯最谨慎小心的业务，这从它在腾讯内部的上云顺序里就可以看出来——最后一个。微信在两年时间里完成了用虚拟机对物理机的替代，然后逐渐脱离原来内部自研的云平台系统，转向更具开源属性的K8S。对于已经降落为生活底色的微信来说，这是一场无法张扬的浩大变革。直到现在，微信基础架构上云的过程逐渐完成，一条复杂的道路才在身后显现出来。

物理机，Yard，和那个旧微信

事后看来，2013年这个年份，在微信身上隐隐划出一条界限。

这年的1月中旬，微信团队在微博上宣布了微信用户数终于突破3亿，这让它成为当时全球下载量和用户量最多的通信软件。这时候离微信首次上线的两周年时刻甚至还差着几天。不到两年的时间，附近的人和摇一摇两个功能带着移动互联网最初的燥热感觉给微信带来了最早一批用户，然后就是2012年朋友圈和视频聊天功能的出现。

2013年之前，除了那个对话框里的橙色信封，我们现在熟悉的那个微信已经基本成型。

一明一暗，腾讯搜搜在2013年被卖掉。这款2006年追随谷歌和百度而出的产品最终无疾而终，在七年后被打包注入搜狗。腾讯的搜索业务暂时停顿下来，其中的迷茫转而成为明星业务上更多的心血。主导腾讯搜搜整个架构建立，又把它做到卖掉了的工程师文杰，作为骨干力量同一年进入微信技术架构部。

微信力求简单与用完即走，而百亿级的消息日收发量，数万个的服务器数量，是贯彻这场繁荣背后的另一个故事。微信的服务器能力需要满足压力上限，而CPU的使用率并不总在高峰，晚上九点是消息收发最高涨的时间段，过了几个小时走到凌晨，CPU的使用率就剩下3%，极限落差有15倍。绝大多数服务器的运算能力都被浪费了。

第三个1亿用户，微信只用了不到四个月，一个近在眼前的爆发期已可以预见。微信内部一个新的资源分发逻辑呼之欲出，文杰和整个技术架构部将会主导这一场变革性的研发。2013年底，自研云平台系统Yard开始出现在内部讨论中。

Yard是四个英文单词的首字母缩写，分别是Yet，Another，Resource和Dispatcher ，合在一起即“仅仅是另一个资源分发系统”。或者称之为一套容器管理体系，Yard利用容器技术对微信服务器CPU做了精细化隔离后，可以实现在同一台服务器上分割部署多个功能模块。

这意味着在线与离线有了更有效率的混布方式，在线上了突发流量需求时，离线任务可以迅速腾出服务器资源，Yard下微信集群CPU资源的使用率达到了40%以上。

这种办法奏效了，Yard托住了微信的下一个爆发期。2016年年底，微信和WeChat合并月活跃用户数达到8.89亿，那一年我国网民规模达只有7.31亿。

但当微信走完了用户增长的最重要一程，开始把更多注意力放在业务宽度上时，Yard的劣势也开始出现。

2014年初的微信离第一个小程序的上线还有三年，甚至还没有微信支付。那扇接纳天下宾客的平台之门还未打开，Yard在研发时也并未过多考虑与外部技术工具的兼容性。事实上，Yard出生所被赋予的目标非常具体，针对服务器的CPU和存储做虚拟化的灵活调度以降本增效，换句话说，Yard是为了解决一个指向性非常明确，与微信原有基础架构强关联的需求而诞生的。

但随着更多业务的涌入，不开源的Yard像一个非标品，

微信的业务在几年内迅速拉开宽度，业务涉及的领域变多，每个团队所依赖的技术工具各有偏好，定制化的要求带来很多不必要的工作量。大数据相关的业务主流上更偏向Hadoop或者Spark技术；做AI训练的团队则倾向于Tensorflow或者Pytorch，但这些框架在第一次接入Yard时都要人工重新进行适配，甚至在每一次框架升级后，同样的事情又要再做一遍。越多新的技术工具引入，Yard在开放性上的局限就越暴露出来。

930变革后，剥离物理机成为上云的开始，但这只是第一步。基础架构整体搬上云端，微信这次势必要走到一个开源的环境里，Kubernetes系统看起来是最合适的路。

风向

Yard真正开始在微信内部落地是2013、2014年前后，这也是微信上云的开始。这一年全球的开源潮流也终于开始向暖。

彼时北半球的另一只企鹅Linux风头正劲，2014年当选微软新任CEO的纳德拉在上位后随即高举“微软爱Linux”；同一年，上线满六年已托管了超过1000万个存储库的GitHub逐渐成为微软、谷歌等硅谷巨头科技公司的码农客厅。

一切早有迹象，2013年中旬白宫的一份“公开数据政策”（Open Data Policy）草案被发布在GitHub上。在此之前，将一份政府政策文件托管在在一家私人公司的服务器上从未有过。虽然这份文档并不能被二次操作或者衍生出任何代码项目，但它仍然具有极重要的象征意义。GitHub以及背后的开源思想，随着克里斯·万斯克拉斯而登堂入室。

此前微软或者说整个科技主流声音直站在开源的反面，正如Windows与Linux长时间在安全性上的对峙立场一样。但技术的迷人处也在这里，开源的优越性在这个一切场景都趋向于虚拟化的时代显露无疑，一旦达成了共识，转变在一瞬间。

从巨头到独立开发者们，开源的思想显然热起来了。让代码协作起来，甚至让写代码这件事本身社区化，正在成为信息世界新的项目管理方式。

同样在2013年， Docker项目的第一个版本被上传到了GitHub，以Apache 2.0授权协议开源并在GitHub进行维护。Docker拉开了容器作为一种虚拟化技术的历史，在此之前，随着硬件性能的发展，硬件性能过剩成为一种愈发显眼的问题，而硬件虚拟化成为最先出来的解决方法。传统虚拟机技术是虚拟出一套硬件后，在其上运行一个完整操作系统（Guest OS），在该系统上再运行所需应用进程。但Guest OS本身就是一个非常占内存且需要在所有虚拟机上重复安装的系统，这种方式显得很重。相比之下，打包进容器内的应用进程可以直接在宿主内核中运行，而容器内没有自己的内核，也不必要进行硬件虚拟，这种封装隔离的逻辑显得更轻，也有更好的扩容弹性。

由于容器的出现，使得硬件虚拟化，也就是虚拟机与大内存的Guest OS，不再是实现资源有效配置的必要条件。但容器更偏向一种技术方法，这种技术最终要解决应用程序端的问题，因此在庞大的容器基础架构集群之上，需要一种更高维度的调度工具。

2017年10月的欧洲DockerCon大会上，Docker公司CTO Solomon Hykes宣布下一个版本的Docker除了支持自有的调度引擎Swarm外，将会首次支持一个外部的调度平台——谷歌的Kubernetes。

Kubernetes也被叫做K8S（由于一共8个字母），是一个针对容器应用，进行自动部署，弹性伸缩，和管理的开源系统。主要功能是生产环境的容器编排。2014年6月谷歌云计算专家埃里克·布鲁尔（Eric Brewer）在旧金山的发布会为这款新的开源工具揭牌，2015年7月22日迭代到 v 1.0后，k8s正式对外公布。

率先提出容器概念的Docker在三年后主动靠近K8S，这一举动给业界带来的震荡不亚于那句“微软爱Linux”。这意味着在容器调度工具的市场中，K8S在与Swarm和Mesos的争锋中胜出，成为行业标准。

某种程度上，微信Yard与Windows有些相似处，两者都曾是技术至上但完全向内的闭源作品。当时不同往日，在微信长成一个平台，连接起的业务越发复杂后，一场改闭源为开源的革新已经不可避免。巧合的是，微软在2018年以75亿美元的价格收购了Github，微信在这一年决定开始从Yard开始转向K8S。

这个过程并非一蹴而就，向K8S迁移需要硬件环境的必要支持，腾讯负责云环境搭建的团队从2018年开始着手建立。与此同时，以930变革为界，腾讯内部开始改变服务器的提供模式，从原来提供物理机，改为提供CVM虚拟机。

前面已经提到，虚拟机在性能上对比物理机并没有优势，摆脱物理机的价值在于降低成本。没有折旧，不需要购买实体服务器或者特别布置机房，这将节省出一笔上亿的开支。这个步骤在2020年走完。也是从那时候开始，一个完全运行在云端的Yard，开始向K8S迁移。

转向K8S

2014年Yard开始成型的时候K8S还没有出现，当时设计的时候微信内部对于yard的定位就是只满足自己的需求，没有做更通用化、或者进一步云化的需求。从两个看上去有些脱节的系统中带着一大堆复杂的功能做转换，兼容性就成了这个迁移过程中最重要的问题。

一个最典型的冲突是，以K8S的架构在一台服务器上部署两个功能模块，这两个功能模块是要完全隔离的，这是K8S或者当下云平台从安全性角度形成的一个基本假设。但是在早期Yard的设计里并没有特别强调这一点，Yard的分核部署逻辑完全服务于微信，一台机器中的两个功能模块是可以通过共享内存等一些方式互相通信的。

2020年中，微信内部在一个内部效能工具的迁移过程中，曾经整个平台大范围宕机过一次。

“当时上面跑了二三十个服务，一下子所有的服务都异常了，我的电话和企业微信全部被打爆了，都在找我”，微信给微信支付业务一整年的宕机故障预算只有几分钟，对于微信支付平台架构中心的工程师lucienduan来说，这次提前在内部试出来的雷是经历中少有的“乌云压顶”时刻。

这个事故最终追溯到一个书写不规范的任务，一行不起眼的错误代码导致网关负载过高，直接把网关跑挂了。 

在刚转入K8S的初期，这个迁移过程并不成熟，整个架构团队都要时常在这种巨大的潜在风险下工作。

所幸的是，这次操作失误只是仅有的几次事故之一，也并没有影响到外界的微信用户，这也是微信给这次上云过程划的底线。对于正在使用微信的10亿用户来说，他们完全不需要知道手中这个绿色的对话框背后在发生什么变化，但用K8S替换掉自研的Yard，这件事又不得不与微信日常的正常运行同时发生。

因此在迁移过程的初期，微信团队预先做了冒烟测试，所有原来基于Yard形成的微信功能，都需要预先放到K8S上跑一圈，筛出一些明显的问题。

确定兼容性是Yard向K8S迁移的第一步，之后就是在两套系统中进行所有功能的对齐，包括对于三园区容灾的支撑能力，这个在微信整个产品历史中都十分显眼的教训。

2013年7月22日，微信上海数据中心的主光纤被意外挖断，这导致了一场两千台服务器的集体瘫痪。微信此前一直将单一消息系统里核心模块的三个互备的服务实例部署在同一机房，这个冗余的设计在微信迅速成长的初期并不显眼，但那一次事故却足足造成了消息收发和朋友圈服务近5个小时的中断。

那次事故之后，微信开始将服务器分散布置，在三栋不同建筑物中分别放置机房的容灾模式由此出现。这也是K8S对齐Yard的一个重点。

“K8S对三园区的支持能不能做好，这是当时首先考虑的事。”谨慎起见，微信团队内部对这次迁移过一个明确的要求，每一步迁移操作都要能够回退Yard。“YARD平台的容量要随时能承受K8S平台回退带来的流量，确保业务无损”，微信团队表示。

剩下的就是K8S代替了Yard后，能给微信带来什么了。

Coder到Owner

DevOps时代的软件开发部署，频率迫切到每周甚至每天，但开发和运维环节的割裂，逐渐成为微信内部一个明显的效率问题。虽然Dev与Ops写在一起，实际操作起来却由两个团队完成。开发团队完成代码的编写打包后交给运维团队去部署核上线，结果是运维人员不熟悉代码逻辑，开发人员不懂上线。这样的问题频繁在微信内部发生，遇到紧急问题往往需要拉很多人员共同处理。

“ 这样的事拉低了整个团队的研发效率，”微信业务团队中很多人同时提到了这一点。

迁移到K8S后对于微信开发者来说最明显的改变就在这里，全栈化的部署使得运维的角色很大程度上与开发者合并到了一起。微信的开发团队除了要写代码，也可以同时完成扩容、上线以及模块部署，这条从开发到上线的链路被极大缩短，以微信基础架构工程师edselwang的话来说，“业务代码编写人员从纯粹的Coder变成了一个业务模块的Owner”。

并且由于K8S具备更全面的虚拟化支持，在整个研发体系完成上云之后，节点部署与虚拟机脱离，开发过程中CI/CD（持续集成/持续部署）流程作为流水线般的自动交付过程可以更完整的实现，这可以被理解成一种“自愈”能力。

edselwang举了一个例子，如果部署在虚拟机上的节点坏了，因为虚拟机不具备节点直接迁移的属性，所以需要运维人员人工给节点在两台虚拟机之间做转移。但如果节点是部署在K8S的平台上，系统可以代替人工来给节点做自动调度。

曾经年三十晚上抢红包的高峰期，微信整个运维团队加班守在服务器前的排班，在整体上云后也会轻松下来。

更大的一个层面上，微信在腾讯内部并不是最早上K8S的，一手扶植起QQ的汤道生在930变革之后进入新组的CSIG事业部，QQ随后成为腾讯首个全面上云的内部业务，众多明星游戏工作室所在的IEG事业部也在几年前开始将架构摆到云上。

腾讯整体的K8S环境搭建在微信迁移之前，这意味着后者从Yard跳脱出来后，将在基础架构研发上进一步更融入进腾讯云原生的设施体系，无论从资源调度还是系统工具的适配性上来看，新业务的决策成本都变得更低了。

这样复杂的基础架构，最终指向一种释放人的价值的，更先进的生产力工具。

微信技术架构负责人Stephen Liu对于一个完全云原生的微信的期待是，它最终能成为一种资源调度意义上的“自动驾驶”。

“如果在2014之前的微信是 Level 0 的话，有了Yard之后现在是 Level 1 ，经过2021年整个去挖掘K8S的各种能力之后，我觉得我们现在应该处在 Level 2 的状态。”Stephen Liu设想中未来的微信春节保供调度将完全由系统调度主导，而这一定基于一个完全云原生的微信。

2019年是微信最后一次申请物理服务器，按通常四到五年的折旧时间来算，不出意外的话，这最后一批物理服务器将会在2023年底左右过保，那恰好是Yard开始搭建的10年之后。届时的微信将真正把整个身体搬上云端。

一切都在不动声色中，微信成了新的微信。