微信上云，一切不动声色
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年之后。届时的微信将真正把整个身体搬上云端。
一切都在不动声色中，微信成了新的微信。
页:
[1]