你觉得微信是如何走出来的？( 四 ) Gmail的第一位产品经理PaulBuch

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（持续集成/持续部署）流程作为流水线般的自动交付过程可以更完整的实现，这可以被理解成一种“自愈”能力。