站在风暴中心:如何给飞奔中的腾讯更换引擎

腾讯自研上云之路

明敏 鱼羊 发自 凹非寺

量子位 | 公众号 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年五一前后,在核心业务基本上云后,欢乐斗地主项目组把团建去处定在了江西武功山。

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

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

站在风暴中心:如何给飞奔中的腾讯更换引擎

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

— 完 —

版权所有,未经授权不得以任何形式转载及使用,违者必究。

相关阅读