你可能不知道，微信的服务器今天才彻底搬到云上( 三 ) 作者｜油醋邮箱

文章图片
图源：TheNewStack某种程度上，微信Yard与Windows有些相似处，两者都曾是技术至上但完全向内的闭源作品。当时不同往日，在微信长成一个平台，连接起的业务越发复杂后，一场改闭源为开源的革新已经不可避免。巧合的是，微软在2018年以75亿美元的价格收购了Github ，微信在这一年决定开始从Yard开始转向K8S 。这个过程并非一蹴而就，向K8S迁移需要硬件环境的必要支持，腾讯负责云环境搭建的团队从2018年开始着手建立。与此同时，以930变革为界，腾讯内部开始改变服务器的提供模式，从原来提供物理机，改为提供CVM虚拟机。前面已经提到，虚拟机在性能上对比物理机并没有优势，摆脱物理机的价值在于降低成本。没有折旧，不需要购买实体服务器或者特别布置机房，这将节省出一笔上亿的开支。这个步骤在2020年走完。也是从那时候开始，一个完全运行在云端的Yard ，开始向K8S迁移。转向K8S2014年Yard开始成型的时候K8S还没有出现，当时设计的时候微信内部对于yard的定位就是只满足自己的需求，没有做更通用化、或者进一步云化的需求。从两个看上去有些脱节的系统中带着一大堆复杂的功能做转换，兼容性就成了这个迁移过程中最重要的问题。一个最典型的冲突是，以K8S的架构在一台服务器上部署两个功能模块，这两个功能模块是要完全隔离的，这是K8S或者当下云平台从安全性角度形成的一个基本假设。但是在早期Yard的设计里并没有特别强调这一点， Yard的分核部署逻辑完全服务于微信，一台机器中的两个功能模块是可以通过共享内存等一些方式互相通信的。 2020年中，微信内部在一个内部效能工具的迁移过程中，曾经整个平台大范围宕机过一次。 “当时上面跑了二三十个服务，一下子所有的服务都异常了，我的电话和企业微信全部被打爆了，都在找我” ，微信给微信支付业务一整年的宕机故障预算只有几分钟，对于微信支付平台架构中心的工程师lucienduan来说，这次提前在内部试出来的雷是经历中少有的“乌云压顶”时刻。这个事故最终追溯到一个书写不规范的任务，一行不起眼的错误代码导致网关负载过高，直接把网关跑挂了。在刚转入K8S的初期，这个迁移过程并不成熟，整个架构团队都要时常在这种巨大的潜在风险下工作。所幸的是，这次操作失误只是仅有的几次事故之一，也并没有影响到外界的微信用户，这也是微信给这次上云过程划的底线。对于正在使用微信的10亿用户来说，他们完全不需要知道手中这个绿色的对话框背后在发生什么变化，但用K8S替换掉自研的Yard ，这件事又不得不与微信日常的正常运行同时发生。因此在迁移过程的初期，微信团队预先做了冒烟测试，所有原来基于Yard形成的微信功能，都需要预先放到K8S上跑一圈，筛出一些明显的问题。确定兼容性是Yard向K8S迁移的第一步，之后就是在两套系统中进行所有功能的对齐，包括对于三园区容灾的支撑能力，这个在微信整个产品历史中都十分显眼的教训。 2013年7月22日，微信上海数据中心的主光纤被意外挖断，这导致了一场两千台服务器的集体瘫痪。微信此前一直将单一消息系统里核心模块的三个互备的服务实例部署在同一机房，这个冗余的设计在微信迅速成长的初期并不显眼，但那一次事故却足足造成了消息收发和朋友圈服务近5个小时的中断。