腾讯提供引擎支持怎么关闭（如何给飞奔中的腾讯更换引擎）

明敏 鱼羊 发自 凹非寺

量子位 | 公众号 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团队一路走来的开发人员，他此前深刻意识到，腾讯内部老技术栈稳定、成熟的另一面，往往是与外界技术潮流的脱节。

这套技术栈会不会过时？研发人员仅在成熟技术上添砖加瓦，个人能力会不会掉队？

这些问题在过去一段时间里，令王昂感到十分焦虑。

直到自研上云的变革到来，各个业务部门原本各自封闭的的“烟囱模式”被打破，他和团队成员才纷纷感到技术视野大大拓宽，在面对外部挑战之时，也更具技术自信。

尽管在自研上云最初，王昂对是否使用新技术栈，仍抱有过犹疑。但从结果来看，这一决定是正确的。

现在，王昂和同事们还有了新的“兴趣爱好”：在腾讯内网连载上云的技术经验。据说追更的人还不少。

One More Thing

2021年五一前后，在核心业务基本上云后，欢乐斗地主项目组把团建去处定在了江西武功山。

当所有人徒步爬到山顶后，大家发现云是真的在脚下的。

后台同学们纷纷激动地发朋友圈：我们这才是真·上云的团队！

而这种情绪的自然流露，或许正是团队自身对于自研上云这件事，最发自内心的认同。

— 完 —

量子位 QbitAI · 头条号签约

关注我们，第一时间获知前沿科技动态

,