腾讯全面上云背后：程序员的技术焦虑和技术理想

2018 年，腾讯正式启动“自研业务上云”战略，微信、QQ、腾讯游戏等海量业务开始了浩浩荡荡的搬家之旅。

将本地部署的程序直接转移到云上，并不能完全享受到云计算的优势，唯有依托云技术栈重新部署、部分重构甚至全部重写，才能由水土不服的“外来者”，成为土生土长的云上“原住民”。

在这个过程中，腾讯的开发者们发挥了极其重要的作用，他们围绕着云原生进行自我技术迭代，通力合作，搭建了一条通往云端的技术“天路”。

2022 年 6 月 16 日，腾讯正式宣布，内部海量自研业务已实现全面上云。

短短一句话的背后，是国内最大的云原生实践。据统计，腾讯的自研业务上云规模已经突破 5000 万核，累计节省成本超过 30 亿。

腾讯自研业务上云的四年，也是腾讯开发者成长和蜕变的四年。

上云，让技术水平脱胎换骨

上云带来的弹性伸缩能力，可以大幅提升资源利用率，降低财务成本，这足以成为大部分业务向云上搬迁的理由，但对游戏团队来说，因为要持续进行高强度的内容研发，重构的成本和风险不容忽视。

“坦白讲，我们做上云这件事，初期的主要目标不是为了节约计算成本。游戏是比较复杂的业务场景，与在原有架构下持续迭代相比，彻底做一次云原生重构需要投入不小的额外技术成本，是不是划算的呢？”这是腾讯 IEG 欢乐工作室技术总监马同星团队，在云原生重构启动前最大的纠结。

“思来想去，云原生重构是对流量的动态治理和调度能力的系统提升，提升容灾和容错能力，进而提升业务的可靠性。”马同星说。

“通过重构上云，我们把服务的动态伸缩变成了常态化、每时每刻都能进行的动作，这也就意味着任何节点或网络故障的时候，都能自动完成故障转移。没有这个能力，我们就得半夜从床上爬起来手动切换——这是完全不同的技术水平。”

类似情况还体现在故障管理上。传统客户端发生故障时，因为后端发生了一系列复杂调用，需要分析日志才能找到问题源头。但在云原生架构下，调用链路清清楚楚，问题节点一目了然。

“这些治理能力下沉到基础设施层面，前期业务架构重构的成本和挑战虽大，但研发运营效率、质量的提升却是长期受益的。”马同星这样劝说自己的团队，“而且这是行业趋势，是机会，虽然现在不做也可以运营得很好，那三年后呢？可能我们距离行业一流的团队经差很远了。”

就这样，团队达成了共识，投入到云原生的实践中。他们进行了大量研究与分享，甚至专门翻译了一本 K8s 的书籍。经过几年的云原生重构实践，团队的专业能力显著提升，多位同事也自然而然地获得了专业晋升。

如果当初团队没有坚持走云原生的技术路线，现在会怎么样？马同星想象不出来，但他知道，有新技术出现，就一定会有革命，如果没法保证自己不被别人革命，那不如主动投身到技术革命中。

投身云原生实践，打破技术焦虑

参与自研上云项目前，哪怕是服务 QQ 这样的明星业务，王昂依然有挥之不去的技术焦虑。同样的焦虑感像低气压，笼罩在团队每个人头上。

2013 年，王昂毕业后进入腾讯，参与 QQ 后台系统的开发。当时，QQ 作为一款上线十多年、月活超过 8 亿的明星产品，拥有成熟稳定的自研架构。在外人眼里，这绝对是一份让人艳羡的工作。

但最初的兴奋感过去之后，王昂却陷入了自我怀疑：“如果只是基于 QQ 的自研技术栈修修补补、闭门造车，长期下来，自己的技术会不会和行业脱节，甚至落后？”

怀着难以排解的焦虑，王昂终于在几年后等来了转机。2018 年 930 变革后，CSIG 成立，他所在的团队被整个划入其中，开始做名为“腾讯课堂”的新产品。此时，一个需要抉择的问题摆在团队面前：是沿用 QQ 成熟稳定的老技术栈，还是使用腾讯云持续完善中的新技术栈？

这是一个很难衡量的问题。从实用主义的角度来看，QQ 的技术栈服务过海量用户，堪称千锤百炼。如果向新技术栈靠拢，上云初期会大幅增加工作量和学习成本，甚至可能因为组件不够成熟而影响业务质量。

对新技术的渴望压倒了顾虑，技术焦虑成为让天平倾斜的最后一个筹码：对业务而言，上云与否短期来看或许没有区别，长期则会带来研效的巨大差距；对开发者个人来说，公有云的技术栈是先进的，更是与外界接轨的，他们早就不甘心只当个修补匠，谁又愿意让这个机会溜走呢？

“以前我没得选，现在想试试新技术。”

王昂举了个例子：“如果沿用 QQ 的技术栈，要实现业务逻辑必须吭哧吭哧写上一堆代码，但业务上云后，Redis 能直接解决很多复杂的数据结构问题，几行代码就能实现相同效果。公有云上有大量优秀组件，对研效有脱胎换骨的提升。”

和预期一样，更换技术栈并非一帆风顺。有一天，部分用户数据突然成了乱码，研发团队就原因定位了很久，发现是因为本地数据库有一些特殊编码，没有和云数据库的组件对齐，这才导致问题出现。

踩过这次坑，王昂意识到，上云流程一定要足够扎实，包括初期的工具准备、迁移过程的监测、迁移完成后的数据对账，都需要把细节抠得很细，才能保障业务的成功率。

为此，王昂和团队就上云组件的细节，与腾讯云的产品部门进行了大量磨合，一年下来反馈了近 400 个问题，双方就容器、运维、音视频等组件进行了持续交流，既完善了腾讯云的技术栈，也保障了腾讯课堂的上云过程。

2020 年初，新冠疫情爆发，腾讯课堂的流量也随着疫情反复大幅度波动，高峰期访问量可以达到平时的 100 倍。

如果沿用 QQ 的自研技术架构，需要提前几天申请服务器资源，然后手动扩容。腾讯课堂上云后，在容器化部署与弹性扩缩容的支撑下，腾讯课堂实现了自动流畅扩容，既大幅缓解了运维压力，稳定流畅的表现也得到了业务部门的认可。

这一刻，王昂觉得笼罩在团队头上的技术焦虑终于散去了。

如今，王昂已经是腾讯课堂的技术负责人。工作 9 年后晋升到这个位置，速度算得上很快，他认为这与参与自研上云颇有关系。除了对晋升的帮助，他更感谢自研上云让他接触了大量优秀的开源组件，技术视野变得更加开阔，并且能够将前沿技术应用在业务当中，这极大缓解了他的技术焦虑。

“如果感到焦虑一定要行动起来，去做难而正确的事情，行动是缓解焦虑的最好办法。”

追求技术理想，也要理解现实需求

技术极客于广游是国内最早投身K8s社区的先锋之一，对容器有着深厚的理解和认知。他和容器团队一同打造了国内最早的基于 K8s 容器化产品的平台——腾讯云容器服务（Tencent Kubernetes Engine，TKE）。

第一次听到公司要自研上云时，于广游的第一反应是“很爽”，“腾讯要跑在腾讯云上了”。

但现实并没有想象那么爽。

于广游曾自认为是个技术原教旨主义者，对技术路线有严格的坚持，但在自研上云的过程中，业务提出了一系列和云原生背道而驰的需求，这一度让他非常抓狂。

差异源于历史，譬如微信原有的架构运行在物理机上，部分系统例如访问控制，需要把 IP 写死。十多年过去，微信支撑了十多亿用户的可靠与稳定使用，尽管架构不断迭代，这个特性却融入到整个系统，牵一发而动全身。

围绕技术进行大量讨论后，为了不损害微信的原有设计架构，从而降低迁移成本，容器团队最终开发了支持固定 IP 的特性。

开发出这个堪称“行业独家”的能力后，于广游一度为技术不够纯粹而郁闷，但他很快发现，对固定 IP 的支持其实是个普遍需求，CSIG 和 IEG 的很多存量业务在迁到容器上时都需要固定 IP，这个功能甚至成为了吸引外部客户的利器。

类似情况发生了不止一次，有业务团队希望能指定TKE集群的接口参数，也有业务团队希望 TKE 能实现 Pod 原地变更，这些都和于广游理解的云原生存在差异，然而就结果来看，业务团队提出的需求，往往也是行业共性的需求。

“云原生技术不只要支持新业务上云，存量业务也有需求，但纯粹的云原生技术并不能完全支持。”为了支持大量存量业务上云，TKE 开发出了很多不那么“原教旨”的能力，但实实在在降低了业务的上云成本。

经过技术理想与现实需求的磨合，于广游抛下了对原教旨云原生的矜持，变得更加灵活务实。他和团队开发的容器技术除了支持微服务，也开始支持数据库、大数据等有状态服务……如今，他已经不把这些视为定制化服务，而是基于云原生内核的创新，不仅能帮助业务降低迁移成本，更能让云原生从专用场景向泛用场景拓展

“定制和创新的区别是什么呢？云原生的内核是声明式的 API，是不可变基础设施，只要定制化的需求不影响本质，它依然是云原生，甚至会成为创新的契机，进一步丰富 TKE 能力。”

“原本我认为技术应该义无反顾地向前瞻的方向迈进，但后来发现，任何一项技术演进，首先要在最适合的场景落地，随后进行技术强化和普适化，也就是能够兼容旧架构去持续演进。”

“不仅要追求局部最优，也要追求全局最优”，于广游说，“谁能想到原先虐我的那些东西，如今都变成了 TKE 在技术上领先的点。”