微信背后不为人知的一场巨变：他们如何「把大象搬进冰箱」？( 三 ) 2020年1月中

2020年之前我们就完成了前两步，从2020年的下半年我们开始大规模使用K8S ， 2021年开始进入到了第三步。从目前看，我们的成本和研效都有了进一步的提升，相对于原来YARD 。还有从广义上云的角度来说，之前推动上CVM虚拟机这一块，微信团队还有一个标志性的事件，就是存储团队也在上云这一块有了一个突破，因为微信一直用的是自研的存储系统，在过去十年我们经历了很多不同的DB（DataBase ，数据库）还有KV（Key-Value ，一种数据库系统），最终在infinityKV的版本实现了存储上云的能力。在2020年下半年， infinityKV开始上线，微信后台大概有80%的数据存储在现在的infinityKV这个新系统里面的。
这是我提到的微信上云（过程），就是把大象搬进冰箱有几步（的过程）。
EdselWang进一步介绍了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年的历史中，微信的定义也是在不断变化的。朋友圈，微信红包，小程序，视频号等等节点性的功能一次次让微信的定义拓展，它是社交网络，是支付工具，也是内容平台。
微信背后的服务器支撑，也正是面对的这样一个不断变化的过程。
早些时候，北京的一场初雪导致当地用户拼命发朋友圈也会导致服务器需求瞬时加大，这种时候就需要响应很快的扩容。
但某地的天气变化和用户行为是难以预期的，春节和除夕夜零点集体发红包是一种必然，类似的必然还有很多，比如周杰伦的演唱会视频号直播，数千万的观看是对微信服务器的巨大考验，但这是可以进行压力测试，提前部署的。