给飞奔中的腾讯更换引擎 媒体揭秘腾讯上云背后故事
明敏 鱼羊 发自 凹非寺
量子位 | 公众号 QbitAI原标题《站在风暴中心：如何给飞奔中的腾讯更换引擎》
2016年的一次改变，转动了科技大厂向前奔驰的方向盘。
其时，一种兴起于谷歌、名为“Kubernetes”的集群管理技术开始在全球范围内“野蛮生长”——
这种被简称为K8S的技术，此后几乎被外界视作云原生技术的代名词。
身处国内的技术弄潮儿们，自然也嗅到了这股技术热浪的气息。一个新的容器项目就此在腾讯云内部悄然启动。
只是，打从事情一开始，争执和分歧其实已经在技术团队内部爆发……
项目主力于广游，便身处风暴眼中。
作为国内最早接触到K8S的一批人，于广游和他的同事们很快敏锐地察觉到：这种新的云计算调度系统，一定是个“大事情”，代表着未来技术发展的方向。
但就是这么个“大事情”，摊子刚刚铺开，“往何处去”就成了大问题。
底层复杂的技术应该被包装成一个简化的服务，把K8S几十个复杂的API都“藏”起来，做成一个只暴露一个接口的、封装好的“黑盒子”，还是有别的选择，成为团队技术人员的争议点。
出于对K8S更深入的理解，于广游这样的“技术原教旨派”认为，“K8S不应该是一种面向终端用户的产品啊。这个产品的更多是企业平台用户。与其把精力花在对K8S概念的包装上，还不如做好开放、完整的K8S生态。”
尽管这样的观点在今天看来具有前瞻性，但在当时，要打破多年以来团队已然验证过的成熟“经验”，去走一条看上去更复杂的路线，多少让人感觉有些风险不可控。
怎么办？
现在看来有些幸运的是，尽管团队中有不少更为资深的技术人员，但在K8S这股刚吹入国内的新风面前，大家都算是从零开始，对新观点的接受度也更高。
在于广游等人的坚持和反复游说之下，越来越多人意识到，面对K8S这样火花越燃越旺的技术，做正确的事或许比稳妥更重要。
这个新容器项目的发展思路，也逐渐明确下来：
一个完全开放原生K8S API的腾讯云“引擎”。
而这，后来也成为了更大规模技术变革的契机。
路线最终按照于广游的设想推进，但正确与否，在当时恐怕并没有人能100%确定。甚至连验证本身进行得都没有那么顺利。
转机在2018年出现。
2018年9月30日，腾讯进行成立后第三次重大组织架构调整。也就是在这次内部变革之中，“自研上云”成为了腾讯技术发展的一大方向。
所谓自研上云，就是把腾讯内部各自跑在不同数据中心的业务全部搬到腾讯云上。
包括于广游团队所提供的腾讯版K8S在内，腾讯云打造一系列云上开发环境和功能组件，开始成为所有腾讯工程师能够共同使用的“武器”。
对于开发者们而言，这也就意味着，无需再重复造轮子，开发流程也从手工时代进入到自动化时代：不需要自己去部署物理机、虚拟机，扩缩容也不需要再折腾机器的事，全部变成面向API的自动化工作。
对于腾讯云团队而言，这样的变化用一个词来形容，就是“很爽”。
但上云这件事，触动的显然不仅仅只有腾讯云。
具体业务开发者，事情或许就没有那么“爽”了。
光子欢乐游戏工作室技术总监马同星的团队，就在上云之初倍感压力。
彼时，欢乐游戏工作室内部打算对原有架构进行重构，以实现服务的弹性化和可拓展。
恰逢服务网格istio 1.1版本发布，两套技术方案就这样摆到了这个团队面前：
其一，是在原有架构的基础之上去增加功能，来实现自动化的流量治理和服务发现。
其二，就是完全切换到云原生方案上，对原有架构进行云原生改造。
一开始，对于彻底重构团队里不少同学忧心忡忡。原因很简单，对于开发人员来说，项目运营多年，原有的架构是经过检验成熟稳定的，开发者对其掌握的程度也比较高。
而云原生，并不是简简单单把旧的本地部署迁移到云端即可，相反，这个方案意味着一切都要遵循云上的技术标准从头来过。
其中的业务风险，不言自明。
这样的技术疑虑，也非止一例。
同样的情况，也令腾讯课堂研发中心负责人王昂和他的同事们心头一紧。
王昂的团队脱胎于QQ，而QQ本身上线十多年、月活超过8亿，早已具备成熟稳定的技术架构。
因此在2019年，面对腾讯课堂新的业务需求时，是否自研上云就成为了技术团队需要艰难抉择的问题。
从实用主义的角度来说，QQ那套老的技术栈依然能用，而且足够稳定，能保证新业务顺利推进。
相反，走自研上云的路线，不仅意味着开发人员需要学习新的技术栈、初期工作量大大提升，各种云上组件也尚未经过充分的验证，很有可能给业务质量带来未知的影响。
只是在这样的“不爽”之中，这些团队最终仍然选择了攀登那条看上去更为艰难的路线。
原因也非常相似：
诚然，在高速狂奔的腾讯内部，去做更换技术引擎这样的事，组织上必然要承担风险和挑战。但是长远而言，无论是对技术人员个人的发展，还是对于团队业务的突破，都有非常大的价值。
王昂坦言：
“作为开发者，如果只把眼光聚焦在内部自研的组件上，不仅有重复造轮子的问题，而且会越来越跟行业领先技术拉开差距。上云与否，短期来看或许没有区别，但长期则会带来研发效率的巨大差距。”
不过，与小说里那些英雄主义的桥段不同，克服抵触的心境下定决心，还只是翻过了困境的序章。
上云的过程，正如开发人员们起初所预料的那般，远不能一帆风顺……
如果说最初决定上云，是基于对行业技术趋势的洞察。
那么，在经历过种种困境后仍不放弃，则因为是上云带来的切实好处，已经开始在日常运营中显现。
欢乐游戏虽从2019年开始云原生重构和平滑迁移，到2020年底仍有不少老旧模块跑在云下。2021年春节前夕，欢乐游戏工作室与手机QQ联动做了一个活动，在春节零点时刻向用户推送游戏的tips。
随着大量用户瞬间涌入游戏，让活动团队始料不及的事情发生了——
用户排队。
出现这样的故障，运营、非研发团队的同事其实很不理解。
“不是说系统能支持100、200万人数在线吗？怎么涌入50万就不行了？”
马同星用一个直白的例子作了解释。
比如腾讯的办公楼能够支持5000人办公，但是每天早晨电梯口还是会排很长的队。为什么会这样呢？
因为5000人指的是容量，但电梯能运载多少人上楼指的是登入并发负载。
容量很大，并不能代表短时间内处理能力可以很强。
回到业务本身来看。
假设某个业务每秒的部署能力是处理5万请求，结果1秒钟涌来了50001个用户。
这意味着，1秒之后还有一个请求没处理，可是到了下一秒又来了50001个用户……以此类推，用户的请求就会积累。
这种积累可能会导致有几十万用户在排队，最终结果就是大量用户的请求都会超时或者被系统丢弃。
因为等排到他的时候可能已经过去了5秒、10秒，这在专业上被称为过载。
而出现这一问题更加深层的原因，是当时还有部分业务没有上云，没有动态弹性计算的能力。
要知道，用户从登录到进入游戏这个流程，只要有一个卡点不能动态伸缩，就会导致排队。
怎么解决这一问题？
云原生重构，是马同星向运营团队给出的答案。
“我和运营的小伙伴说，我们现在正在做一个大的技术重构。”
“它的核心能力之一就是，如果一条路上只有1个人走，它能够让路变得很窄、节省资源；如果突然来了5万人，它又可以把路变得很宽，让这些人快速通过。”
在浅显通俗的解释下，运营团队也很快理解了马同星他们在做的事情，并切实感受到了云原生能为实际业务带来哪些好处。
这个过程中，内部团队之间的信任也悄然建立。
后续，当版本中有部分业务需要技术团队来做重构时，运营团队能够给予更多的理解，同时也很开心业务能够上云。
而这样的故事还只是上云过程中的一隅。
透过它也显示出了上云时面临的许多棘手问题。
比如涉及到的业务往往是大体量、高营收的，无法不管业务死活去“一刀切”做迁移。
再比如需要运营、策划团队也要懂研发团队在做什么事，建立团队之间的技术信任。
简而言之，无论是马同星还是王昂团队的经历，都说明了同一件事：上云不是一蹴而就。
回顾腾讯上云几年来的经历，大致可以归结出3方面经验。
第一、研发团队通过试点项目做技术验证，建立团队信心；
第二、将不同业务逐步迁移上云，云上云下两步走，保证在出现故障时能够回滚；
第三、腾讯云团队与业务团队之间耐心磨合。
首先来看技术团队如何建立信心。
比如马同星所在的欢乐游戏团队。
在最初决定迁移上云时，他们就开始自己去搭设服务网格做技术验证，成功之后再把技术慢慢铺开。
为此，马同星团队用一个用户体量较小的业务作为“试验田”。
验证期间，技术团队一边趟平了大大小小的坑，另一方面还加深了对云原生的认识和掌控，最初对上云的恐惧和顾虑也随之消散不少。
其次，如何平滑上云是重中之重。
马同星表示，我们期望的上云并不只是把业务直接搬到自研云里，而是从架构层面的改变。
他们采用的迁移策略是先从相对不重要的服务入手，等出现的故障逐渐减少时，再迁移核心服务。
同时，为了保证“用户无感知”，在新业务上云后，相应的云下环境不会立刻裁撤，流量保留了自动切回的能力，由此平稳度过了波动期。
最后，团队之间磨合也十分重要。
除了如上欢乐游戏研发团队和运营团队之间信任建立的故事。
在腾讯课堂这边，王昂也提到上云过程中一直和容器化、运维等团队在密切沟通。
这主要是因为云技术方案更为领先，技术栈还没有十分稳定，所以不可避免需要更为耐心的磨合。
“基本上云的组件，我们提了三四百个issue和反馈。”
这样大量的反馈沟通，是王昂此前从未经历过的。
在投入大量人力、物力上云的另一面，成果也已开始显现。
截至目前，QQ产品、腾讯课堂已经实现100%迁移上云。
今年，他们计划将其余老业务也全部重构上云，存量业务进行迁移。
今年，是“腾讯跑在腾讯云上”的第4个年头。
业务发展愈加成熟，亲历上云的工程师、开发者们心态上也发生了不少变化。
比如于广游，在亲眼见证自己团队的产品成为腾讯重大技术变革的基底之后，开心的同时，也慢慢“从技术原教旨主义者变成了一个更加务实的人”。
在自研上云前期，他对遇到的一些需求非常不能理解。比如要求自研上云需要原地重启、需要指定POD去更新、需要做固定IP。
作为国内最早一批接触K8S的人，于广游觉得这些要求都很“不云原生”。
毕竟K8S的理念是让部署容器化的应用简单、高效，结果腾讯自研上云却提出了一堆“乱七八糟”的需求。
但随着自研上云的脚步往前迈进1-2年后，于广游慢慢发现在接触外部客户时，他们也在提类似的需求。
由此他开始意识到，一些兼容特性的出现是有必要的。在此，他用VPC举了个例子。
“比如VPC，它其实是为了让云模拟IDC的网络环境，是为了兼容企业上云之前传统的网络管理模式，所以VPC的出现本身就是为了降低企业迁移成本。”
而这正是云产品更为核心的演进方向。
在直接使用价值之上，进一步去降低企业迁移成本，才会吸引更多企业来上云。把云原生从一个小众的前沿领域，逐渐变成一个覆盖大众需求的领域。
基于这样的思考，于广游表示自己之后看待技术问题开始从更加宏观的角度出发，并在自研上云中发现有更多创新可做。
马同星团队有位专业能力强悍的资深工程师，甚至是因为自研上云这件事，才选择继续留在腾讯。
在负责工作室上云的开发和架构设计之前，他一度觉得工作少了很多新鲜感。
但云原生架构这一技术，重新吸引了他的目光。
因为这将会改变腾讯原本的开发模式，各个团队不再自己重复“造轮子”，这个开发后台也会更加开放。
全新的技术架构，打破了团队同学们的职业发展瓶颈。
而透过自研上云这件事，更让大家感受到开源社区的意义所在。
现在，他希望随着云原生的大潮，他和团队能够对技术不断迭代，为开源社区做出更多贡献。
腾讯课堂研发中心的负责人王昂，则表示在上云过程中，“团队的技术焦虑得以缓解”。
作为从QQ团队一路走来的开发人员，他此前深刻意识到，腾讯内部老技术栈稳定、成熟的另一面，往往是与外界技术潮流的脱节。
这套技术栈会不会过时？研发人员仅在成熟技术上添砖加瓦，个人能力会不会掉队？
这些问题在过去一段时间里，令王昂感到十分焦虑。
直到自研上云的变革到来，各个业务部门原本各自封闭的的“烟囱模式”被打破，他和团队成员才纷纷感到技术视野大大拓宽，在面对外部挑战之时，也更具技术自信。
尽管在自研上云最初，王昂对是否使用新技术栈，仍抱有过犹疑。但从结果来看，这一决定是正确的。
现在，王昂和同事们还有了新的“兴趣爱好”：在腾讯内网连载上云的技术经验。据说追更的人还不少。
2021年五一前后，在核心业务基本上云后，欢乐斗地主项目组把团建去处定在了江西武功山。
当所有人徒步爬到山顶后，大家发现云是真的在脚下的。
后台同学们纷纷激动地发朋友圈：我们这才是真·上云的团队！
而这种情绪的自然流露，或许正是团队自身对于自研上云这件事，最发自内心的认同。
— 完 —
本文来自微信公众号 “量子位”（ID：QbitAI），36氪经授权发布。
