全面上云为什么这么难——腾讯「世纪工程」的反向解耦-技术圈

云的能力和规模关系密切，大江大海里才能见出真章。

”

作者 | 胡喆

编辑 | 胡喆

现实中的锚是用来固定船的，是为了让船不至于飘走。

腾讯技术体系，也要一个强大的锚，这个锚可以理解为腾讯技术体系的内在价值究竟绑定在什么底座上，进而解释这一体系发展的参照基准，甚至对外展示其未来价值和如何满足产业预期。

腾讯技术体系早期的锚，是锚定于某个超级产品上，就像早期的贝壳、金、银等货币，它们有内在价值，自身就是锚。

这就好比以往，外界要评估腾讯的技术水平，往往就会去看微信的产品做到怎么样，我们就会听到很多观点，比如，从微信的某某功能来看，腾讯的技术发展如何如何。

目前，腾讯的技术价值在一定程度上仍是锚定超级产品的，但从腾讯未来的产业地位和技术发展需要来说，这绝非长久之计，因为产品是有兴衰周期的，但技术却可以越做越强，越积越厚。

换言之，腾讯技术体系的锚，应该锚定于自己最前沿技术的含金量和流通率这两个指标上，而纵观整个腾讯的发展，没有任何一个技术底座比云计算更适合担当这个“锚定物”。

而要加强这种锚定联系，如果腾讯自身的自研业务都不能充分上云的话，在逻辑上显然是不能自洽的，所以，我们看到了从9.30以来的这次“超级工程”。

回落到现实层面，互联网野蛮增长的时代早已过去，精益增长成为新的标准，降本增效要在每个局部较优中求得全局最优的解，也需要完成一次集体向云的迁移，这是腾讯前所未有的一次战略级的技术穿透对齐，是腾讯内部技术体系打通奇经八脉、拥抱开源协同文化的大动作，是世界范围内也很难找到的超级工程、世纪工程，甚至可以上升到中国数字产业的竞争力的观察窗层面。

腾讯“换锚”

将近四年前的秋天，腾讯完成了自成立以来的第三次重大组织架构调整，史称“930变革”。

早在2017年年底，腾讯核心管理团队便着手调研，试图“诊断”自身，并且意图进行腾讯公司史上的第三次组织架构变革。2018年9月30日，一封落款为“Pony（马化腾）、Martin（刘炽平）和总办全体”的邮件被发送到全体腾讯员工的邮箱中。

在这封宣布变革的邮件中提到：将原来七大事业群调整为六大，新成立云与智慧产业事业群（CSIG）、平台与内容事业群（PCG）的同时，腾讯还成立技术委员会，打造具有腾讯特色的技术中台。这也成为腾讯公司史上第三次架构调整。

当时，媒体的更多关注点在于事业群层面的调整，对于技术委员会的成立，关注、解读相对较少。

在雷峰网多年对头部企业的采访中，“技术委员会”作为一个组织设置，绝大多数情况下都扮演着相当“虚”的角色，跟掌握着公司技术路线话语权的CTO不同，“技术委员会”大多是给即将荣退、或暂时无处安放的技术大牛的一个荣誉存在。

但是，这一次和历史有所不同，930后的技术委员会有两个相当实在的任务。

那就是启动“开源协同”和“自研上云”的两大战略方向。

开源协同比较好理解，此前，和所有“研发跟着业务走”的互联网企业一样，腾讯围绕不同的业务形成了无数个典型的“烟囱式”业务架构，研发人员只为“自己这个烟囱”服务。

这就导致，很多部门的代码不开放，或者开发者缺乏写文档的动力，因为没人看。但事实上，作为一个优秀的组件，文档、支持、社区都是非常重要的，没有这些支持的话，很难把一个组件做到最优。但是，在腾讯内部无数次的重复造轮子的工作后，很多组件缺少文档，研发力量支持力度不足，甚至出现了很多无人维护的“孤儿组件”。

而开源协同则是希望实现，至少在腾讯内部，所有的开发团队代码都是开放的。这从理论上使得团队与团队协作更好，随时可以去创建新分支，或者提交更丰富的特性功能，形成公司内的开源代码文化，创建更好的工程师氛围。

但是，如果大家研发所使用的工具、体系、目标、性质都截然不同，代码公开和开源协同的意义就变得有限，因为你即使看到了优秀的源代码，也无法借鉴、移植，应用到自己的业务场景中去。

而要把这一切都统一协调起来，就必须让开源和协同基于同一个底层架构之上，而历史的巧合点就是，有且只有把腾讯的技术底座以公有云的模式进行了一次前所未有的“大一统”，才能让开源协同的价值最大化。

这就是腾讯技术体系大演进和腾讯云业务成长的风雨际会与历史巧妙的暗合。

当然，自研业务上云，并不仅仅是为了更有效的开源协同。

在宏观与微观之间，腾讯全体系的“自研业务上云”，目的是基于公有云的研发模式，使用云上丰富的组件和服务，实现技术层面的降本增效；同时把内部自研业务的优秀工具和组件上云，对外开放，在云上做服务。最终，使得腾讯云业务可以在内外部客户的双重驱动下，不断迭代成为行业内的领先水平。

但是，从最大的宏观层面，自研上云的核心，是重新锚定腾讯技术体系的价值。

长期以来，腾讯“产品强”的口碑都是众所周知的，但那是toC互联网时代的美誉。在产业互联网时代，腾讯急需在技术价值层面，为自己的业务能力找到一个“锚定物”。

我们知道，现实中的锚是用来固定船的，是为了让船不至于飘走。

腾讯技术体系并非没有锚，但早期的锚，是锚定于某个超级产品上，就像早期的贝壳、金、银等货币，它们有内在价值，自身就是锚。

而且，这个“锚”是一体两用的。

对内，为所有的业务发展找到根本遵循；对外，展示腾讯技术体系的能力尺度。

还是拿货币来做比喻——在国际贸易中，想用来交换或者各国之间贸易，必须让对方明确，你的货币，能够买到什么，能买多少，它的价值如何衡量，这个衡量基础的“物”，就可以称之为货币的锚定物。

而在未来，外界评估腾讯云的价值如何、功能如何、对业务发展的价值如何，都可以参看自研业务上云后的整体水平和运转情况。

简单说，腾讯要以自研上云的成果，为腾讯产业互联网的技术输出作出信用背书。

更为重要的是，自研上云还有组织能力升级的附加值。

腾讯这样发展20多年的企业，内部业务在一定程度上也形成了“部门墙”效应。应该说，腾讯做了不少穿透部门墙的努力，但并不是每次都取得比较好的结果，这里面的原因是极其复杂的，很难用单一的归因来解释。

但至少有一点是，原本分散的技术架构，使得部门墙的现象在技术层面也初见端倪，而自研业务上云，既有高层的压力与安抚，也有执行层的协作与博弈，但这些都客观为腾讯迎来更开放的技术氛围提供了条件。

而最后不得不提及的是，自研业务上云，腾讯已经不是第一家了。为了迎接产业互联网时代更激烈的竞争，使得腾讯在未来更残酷的竞争到来前的档口上，更换更强大的引擎，恐怕除了自研上云这样的超级工程，也再也没有更合适的业务实践机会了。

这是一场只能赢，不能输的长期战、整体战。

自研上云的“三个关口”

自研上云，就是把所有腾讯自研的业务的运行都放到云上去，你可以理解为一次“搬家”。

但这次“搬家”并不是一次简单的物理平移，也不是把家里的物品原封不动的从A处挪到B处。

如果要找一个合适的比喻，它更像在太空中组建“天宫实验室”，它既要把最核心的能力完好无损的进行一次漫长的迁移，同时又要使其在一个全新的环境中继续安然运行，难度可谓前所未有的高。

先抛一个结论，腾讯云副总裁徐勇州告诉雷峰网：“自研上云之前，腾讯云整体的业务负载，也就是原来三年前大概是在30%的水平，但是今天，基于云原生带来的调度以及迁移的能力，集群负载提升到45%，在离线业务混部集群的负载更是到了65%这样一个相对比较高的水准。考虑到有一些冗余要求，业界做得好的、也就是美国的科技巨头，在负载上大约是做到50%左右。

所以可以得出结论，无论是从量的角度，还是质的角度，腾讯自研业务在云端整体的资源负载率有了一个大幅提升，这对于企业来讲是一个巨大的降本增效，是在运营效率上得到一个更极致的提升的过程。”

然而，这样一个过程却是经过了千辛万苦。

首先，自研上云，这里的云指的是公有云，因为公有云才是云计算行业发展的主流，而此前腾讯业务已经有很多的自发上云，有的是基于公有云，有的是基于私有云或者混合云。

这比在一张白纸上画画更难。

其次，腾讯的很多业务不仅成熟，而且对稳定性要求极高，比如微信业务，轻微的抖动都可能影响数亿人的使用。

雷峰网在长期采访企业数字化转型的过程中，对成熟业务模块迁移难度的印象是极为深刻的，这并不能简单的用“部门墙”或“怕麻烦”来解释，而是一种真实的焦虑，这其实成为很多数字化程度已经很高的企业上云中最大的阻碍，那就是害怕迁移带来的风险，和对已有系统的信靠。

最后，腾讯并不是一个非常军事化氛围的公司，虽然“自研上云”是公司层面的正式决策，而且有“技术委员会”作为组织保证，但在实际工作中，腾讯云的员工并不能仅仅依赖这些公司决策来推动工作，他们需要换位思考、需要在这个过程中动用更多“情商”，去琢磨上云业务单元的种种痛点、顾虑，然后再找出对方能接受的办法。这是一个水滴石穿的过程，也是一次最好的如前述“打通技术体系的奇经八脉”的过程。

所以，这三个难关，其实也是腾讯云自我突破的三个阶梯。

在大江大海里

那么多的困难、那么多的挑战，腾讯仍要坚持自研上云，实在是因为价值太大了。

用“大江大海”来形容这次上云的规模，也毫不夸张。

用腾讯云CTO王慧星的一句话说就是——在大江大海里调度资源，难度虽高，但腾挪的空间反而更大了。

这个腾挪的空间，有两层意思：一个是底层自研技术发挥作用的空间更大了，能倒推团队去研发更先进的底层技术；另一个是资源利用率提升了，降本增效的成果显著。

首先是底层的自研技术。

可以说，全球的云计算都是在当时的算力基础设施上做起来的，包括当时的CPU、服务器、操作系统等。但当云计算的规模发展到一定阶段，就产生了定制化软硬件的需求，而且定制的越早，就越为后面的自主可控和资源利用率提升留出空间。因为自研的一定是高度符合实际需求的，而外购的再好、再定制化，也要受制于人。

因此，包括腾讯这样的大体量公司最终也都会走到定义硬件或者自研硬件的路子上去。

王慧星提到，2014年前后，腾讯自己的工程师就提出来要自研服务器、智能网卡，彼时距离图灵奖得主提出“计算架构在未来迎来黄金10年”这个著名观点还有三年。而腾讯去推动云平台的软硬结合、研发云原生硬件也可以追溯到这个时候。一方面腾讯云在自研硬件上布局够早，另一方面自研上云带来的巨大业务体量，也反推了星星海服务器、智能网卡芯片、视频编解码芯片、AI推理芯片的诞生和应用。到自研上云后期，性价比极高的星星海服务器在云上的规模化应用也成为了内部业务上云的重要推动力。

其次，是资源腾挪带来的利用率提升。

要在大江大海里把资源盘活，怎么调度就很重要。这里面也有不少故事。调度要看两个层面，一个是基于什么调度，一个是用什么调度。

从技术上来说，全球的云计算已经进入云原生阶段，其中的一个关键技术就是容器。在2019年初，腾讯就定下了最终所有业务都得完成容器化改造，打造云原生的基础设施。而彼时大家争论的点是：用什么调度，即这个容器的编排调度体系，到底是开放给各个BG各自去做调度？还是整个公司用一整套的调度平台和服务？

从行业里看，最流行的容器编排调度技术是K8S。虽然它是谷歌提出来的，但是它今天是社区上面一个非常优秀的开源服务，腾讯云的团队在这里面也做了非常多的工作，形成了成熟的产品叫TKE。但腾讯的各个BG其实很早就做了很多容器化的实践。虽然不是基于K8S的，但在海量业务的打磨下，也早就自成体系，扛住了不少考验。

“当时，我们在这个事情上大家的讨论还是挺多的。其实这个背后的核心还是局部最优和整体最优。使用TKE作为统一的调度引擎，是能实现整体最优的。我们也是靠这样的数据分析说服了总办，也非常感谢卢山（腾讯公司高级执行副总裁、技术工程事业群总裁）在这个地方大力的牵头推动”，王慧星回忆说。

为什么统一调度能实现整体最优？其实原理说起来也很简单：

每个BG自己做调度，就相当于自建一个小池塘，按照安全运营的基本逻辑，这个池塘最少也要有20%的一个空余空间必须保留着。

但是，因为腾讯的BG非常的多，如果搞20个小池塘，那每一个小池塘都得留着20%，最后留出来的空间那就是20乘以20%，这就是非常大的浪费。

在一个小池塘，跟在一个大江大海里去做资源的搬迁和调度，肯定是大江大海的腾挪空间更大，因为更大了，所以反而更省了。

在大江大海里腾挪资源，底层推动技术创新，往上提升资源利用率。这就是自研上云给腾讯带来的一个很显性价值。据腾讯披露，自研上云三年省了30亿元。

内外统一视角之下的自研上云

让雷峰网感触颇深的，是腾讯云的自研上云伊始，就提出来一个要求——服务于内外部客户，要用统一标准来规范服务。

这个“内外部客户统一性”，值得说说。

有人或许认为，服务于内部客户或许沟通难度低一点。但在腾讯云的实践中，这是不能区分的，或者，有时候内部客户反而“更刁钻”。

例如在支持全民K歌的海外版业务上云的过程中，使用了一段时间以后，全民K歌的技术人员直接扔给腾讯云TRTC(腾讯云实时音视频业务)一份文档，另附一行字：“你们自己看看数据比得过竞品吗？“

这是真实的故事，当时全民K歌海外版（WeSing）上云后使用量一直不涨，腾讯云的员工去沟通，对方就直接丢过来一个很大的文档，上面就是和竞品的各种质量对比。

结论是——进房耗时没有人家好、清晰度没有人家高、秒开率也没有人家高。

TRTC就要分析，除了进房耗时这个指标，外部竞品有误导之嫌以外，秒开率、清晰度确实不如竞品。

某种程度上，云服务出海的技术复杂度高于本土，但技术先进性未必高于本土。

在国内，运营商的基建水平很高，例如各个运营商都有很多的大buffer路由器，这些路由器上都有缓冲，当带宽不够的时候会增加延时抗拒丢包，但是，海外很多落后的国家或者偏远地区用的设备还是上世纪90年代的设备，这些设备没有缓存，遇到带宽不够的时候上来就丢包，没有增加延时。所以当时把国内的经验搬到海外给客户用的时候就水土不服。

腾讯云意识到这个问题后，针对海外网络进行了非常多的细致优化，再进行大的架构升级改造，最终实现TRTC在各方面指标全面做到业界领先。这些经验不仅为更广泛领域的出海所用，也反哺了国内的技术演进。

另外，随着全民K歌推出“合唱“功能，原有的延时300毫秒的标准，就不够用了。因为，原来都是你唱一段我唱一段，所以延时300毫秒是没有问题的。但实时合唱就是两个人在一起同时唱一首歌，大家的声音一定不能一前一后，要到80毫秒以内，人耳才感觉不出来。

这对技术挑战很大，TRTC的延时，是一个系统性问题，是从采集、编码、传输再到播放渲染这一系列过程中产生了300毫秒的延迟。那么，要优化就要从全链路上优化，从每一个环节上找原因。甚至要精细到针对手机的不同操作系统版本，通过调用不同的API的方式，尽量降低延时。

所以，TRTC的一个业务负责人很有感触地说：“内部客户的业务指标检测做得足够好，因此提要求就有理有据，这就带给我们很大的压力，为了‘生存’、为了应对自研业务的挑战，在这种极度打压测试中，慢慢地产品就越做越好了”。

分头突破集中成长

从全民K歌这个案例里，我们能看出来，自研上云的第二重价值，是很好地打磨了腾讯云的产品。

腾讯业务线众多，每个业务场景不同、痛点不同，所以一通跑下来，整个腾讯云都在提升。

比如，如果粗略的划分一下，自研上云的过程，可以分为从本地服务器迁移到云服务器，和业务的云原生化改造两个阶段，每个阶段都充满了挑战。

第一阶段的绝对主角是CVM（云服务器），它是最核心、最基础的云计算产品之一，也是腾讯自研业务上云的基础大底座。

简单而言，CVM要支持大量原本本地化部署的业务完成主机上云，也就是从物理服务器到云服务器。

而更进一步来说，CVM也是很多业务实现云原生上云的底层支持，例如我们后面会讨论到的TKE和EKS等云原生容器服务，本质上也是基于CVM构建。

作为自研业务上云最早的支撑产品，也是自研业务上云中规模最大的产品，CVM承担着建立自研业务团队对云本身的信任的责任。

但这个过程开局就不顺利，2019年2月，首个自研上云可用区交付的时候，定的交付时间，是一个周五。但是CVM团队一直搞到周五晚上一点钟、两点钟还是没有交付，等到搞完了，业务下班了，只能延期到下周一。

首次交付就delay，此次事件被称为“CVM团队在支撑自研上云业务时的当头一棒”，后来团队比较高规格地复盘此次问题，引发了很大的震动。

必须说，腾讯有超级产品和超级场景，这对云业务的成长有很大的好处，但也带来了空前的挑战。

例如，本地部署的物理服务器，虽然远没有云来的灵活，但不存在虚拟化带来单机性能损耗。

因此性能上，腾讯自研业务特别是一些超级业务，对CVM有着极高的要求，比如微信、QQ等业务要求云服务器单机性能要相对物理服务器在8%以内。

而事实是，在2019年时，CVM仅仅能在不同场景下做到虚拟化开销在15%左右，虽然已经是当时的业界最佳水平，但与自研业务预期之间还有较大差距。

在清晰的目标和强大的倒逼压力下，CVM产品团队在三个月时间内，结合业务性能测试结果，启动云服务器性能优化专项，重构网络虚拟化、存储虚拟化软件，大幅优化KVM性能。

最后，他们做到了，虚拟机相比物理机性能损耗控制甚至在5%以内，并实现虚拟化性能损耗降低50%的技术突破。到现在，腾讯云的虚拟机相对于物理服务器的损耗已经到0。

而这个过程，就包含我们前述的，很早就通过自研软硬件一体化来为系统架构突破提供腾挪空间，事实上，这次CVM的成功达阵，不是单纯靠软件优化得到了，反而恰好是首创性的使用了硬件芯片加速，才实现网络性能提700%，延时降低60%；存储性能突破，IO性能提升300%，有效支撑了自研业务平滑上云。

有时候，不得不叹服，体量大、痛点多，固然是腾讯云的磨难，但的确也是云计算行业的福气。

王慧星就讲过一个案例，他说，一般的服务器存储出现问题，换块硬盘就好了，最多不过换一台物理机。但是由于腾讯云的业务密度非常大，所以一个存储机柜可能有几个P的存储空间，一旦发生问题，T级的数据备份和P级的数据备份，完全不是一个数量级上的问题。

但腾讯云的业务密度就是催生了这种怪兽级的P级存储柜，而为了解决这些不可预知的硬件故障问题，倒逼腾讯云打造出了业界领先热迁移热升级技术，使得热迁移成功率由70%提升到了98%，已经接近极限。

此外，为了优化磁盘IO慢导致停机时间变长的问题，腾讯云在业界首创了停机阶段内存和磁盘单独控制的思路，这已经是系统架构底层的突破了，而这种突破使得停机时间从秒级减少到50ms，而这种“单独控制”结合前面所说的热迁移技术，使得MCA Recovery技术大规模落地，把服务器内存故障率下降了50%，服务器可用性达到业界领先水平。

说到这里，不得不提及的还有一个验收环节。

腾讯，或者说绝大多数有超级产品的企业，都有一个特性，那就是规模越大，对可控性要求越高。

比如，波音747的安全性理论上就是会比波音737更高。

在推动自研上云的过程中，腾讯云计算产品策划经理刘洁欣就感到，业务体量越大的自研上云的业务，不管是对设备的性能监控，还是日常使用的流程管理，都比其它体量相对没那么大的业务更加严谨，准确的说，是要严谨很多。

这体现在，腾讯云在给一些比较大的业务做交付时，即使是内部，也会有非常详细的验收场景和流程。比如QQ里面也细分了非常多不同的场景，其中，春晚保障红包的团队的验收标准，跟QQ提供基础能力的团队的验收指标，又是不一样的；而到了QQ群的场景，它又是以另一个标准来衡量，又换了一套更贴合于他们业务自身所定义的标准。

这带来的一个极大的好处就是，腾讯云每攻克一个大的业务“山头”，就会沉淀出一整套针对更多的细分场景和性能场景不同的验收要求，而这些也会沉淀下来，补充到腾讯云的交付体系中，久而久之，这个体系就天然十分严密。

更多时候，腾讯云还需要拥抱前沿技术，才能满足那些复杂和严密的要求。

比如，腾讯云是国内是首先采用KVM虚拟化技术的，一开始布局虚拟化平台的时候，就选择了Linux+KVM的技术方案。这在当时是激进的，也是有争议的，毕竟当时业界主流的虚拟化技术是Xen。

选择KVM一方面是KVM在技术架构上有着更好的前景，能够兼容主干Linux，另外一方面KVM社区很高的活跃度，正好也符合腾讯拥抱开源的技术思路。

即便腾讯云在KVM上保持着行业领先性，但每个BG需要的交付和支撑都是不同的，要让腾讯云一开始拿出的交付就满足所有性能要求，基本不可能。因为开发者是无法通过穷举用户的使用行为来设计功能的，只能说沿用过去定义的几个业界比较规范的指标去开发大略的功能，然后在业务交付中不断完善，每次交付要处理的这些纯“细节”问题都不会少于上百个，而这也能逐渐加强最终产品形态的完善。

而在这个过程中，其实也充满了博弈。

联合调优、协同打造，固然是常见；但腾讯云也有一个堪称难能的优点——那就是它们不会因为对方是客户，就放弃质疑对方的权利。而这才是一种对技术负责的态度，也是非常有价值的。

“被上云”的团队，有自己的已有资源和经得起考验的技术，所以他们能直接说“你搞不定我就不用”。而腾讯云作为服务方，也会去质疑和挑战某些标准设置的是否合理，是否是最优路线。正是在两方都在求真、求极致，才能共同把事情做好，甚至打磨出新的产品复用到公有云。

云上生长

前面我们已经提到了，腾讯的上云不是简单的将业务从物理机搬到云上虚拟机，尽管这个过程是自研上云的第一大阶段。

但这个阶段的目的，恰好是为了帮助自研上云完成第二步的目标，即借助云原生，尤其是容器、微服务、DevOps的能力，构建面向未来的技术架构，打破部门墙和重复造轮子现象，通过内部开源协同，加强基础研发，促成更多协作与创新，提高腾讯的技术资源利用效率。

腾讯各大事业群（BG）在没有上云之前，大多都有一套自己的容器平台，有的基于自研技术，有的基于开源的K8S，但是大家的方向是一致的，就是看到云原生是未来的大势所趋。

因此，在上云的过程中，面临的问题就是怎么上云，是直接上虚拟机，还是云原生，如果使用云原生的话，究竟要用哪个BG的技术，这里内部展开了激烈的PK，当时也调研了很多的云原生技术，最终确定了以开源协同的方式，构建基于K8S的底层能力，在此之上，使用腾讯云TKE来构建每个BG自身的容器平台。

反过来先看一个结果——自研上云从2018年的930到现在已经过了三年多时间，腾讯云自研业务整个规模已经超过5000万核心。

更重要的是，腾讯实现了自研业务百分之百在云上生长，这是一个面向宏阔未来的最佳开局。

前述中，我们讲过Wesing这样的业务的上云过程，但事实上，后期很多的业务使用，是直接在云上使用云的能力构建自己的服务，最典型的，就是腾讯会议。

腾讯体系内，除了QQ和微信之外，谁是用最短时间达到亿级用户的，你的脑中可能浮现出无数产品，但你大概率想不到是这一款——腾讯会议。

2020年1月23日，武汉宣布封城，全国在短短数日内切入抗疫模式，仅仅在6天之后，腾讯会议的后台资源已经告急。

毕竟，这是一个最初只为5万DAU设计的、带有一定试验性质的视频会议产品，哪知道在几天之内，就要承担一个14亿人的国度骤然增长的线上会议需求。

这是一次前所未有的、集中的跨时空沟通需求对线上资源的“挤兑”——扛过挤兑的，自此会提升一个甚至几个数量级，抗不过挤兑的，自然会在极化的竞争中被淘汰。

如果是在传统的IOE时代，这种几何级数的增长是平台级服务商最难抵御的，因为传统系统的设计有一定的上限和下限的阈值限定，如果遇到需求突然放大，就必须扩容机房、添置服务器、增加带宽，进行大量的线下作业，而这其中消耗的时间可能短则几日、多则一两周。

好就好在，腾讯会议基于云原生模式生于云，长于云的，于是，从当年的1月29日开始到2月6日，腾讯会议每天都在进行资源扩容，日均扩容云主机接近1.5万台，8天总共扩容超过10万台云主机，共涉及超百万核的计算资源投入，这种无缝也无感的资源投入，只有云计算才可能做到。

更重要的是，资源扩容还好说，架构的扩容才是最具有技术难度的。在传统的数字化体系内，软件的架构从万级到亿级，是需要经过若干次彻底重写的，而腾讯会议在短短两个月时间内快速扩容、调整架构，从一个支撑5万日活的体系，变成一个能快速支撑超过千万日活的体系，在产品孵化期只投了1.5个后台开发，花了两个月时间就完成了整个腾讯会议的后台体系搭建，这在过去也是不可想象的。

而这一切的背后，核心技术可以用一个词来概括，那就是“云原生“。在整体架构上，腾讯会议采用了容器化的云原生方案，真正做到弹性伸缩、自动扩容、异地容灾备份、服务化治理。

更重要的是，为了进一步降低云原生的应用难度，从前端的角度讲，云原生一直在低代码/零代码化，以及不断累计优秀的组件和模块，使得开发者不用太多的考虑基础设施层的东西，比如存储层、逻辑层、接入层等。

简言之，云原生的应用，甚至使得开发人员并不用担心后台的资源问题，而是完全聚焦于业务本身，之于如何用云，由于可以大量快速的使用基于云的基础设施和组件，极大的降低了后端的开销和开发。

腾讯云原生的案例，雷峰网已经收集过很多，但最经典的还是这个——腾讯会议能撑过亿级需求，可以说是腾讯云在2017年加速发展后，一系列基础研发和基础建设的一次总验收。

这次总验收，也让腾讯内部经过海量业务打磨的云产品、云技术和云服务开放给产业，推动产业的数字化升级，助力实体经济全面发展。

结语走向未来

在深度了解腾讯自研上云的三年多历程后，雷峰网的感受是，自研上云，并不是简单让业务把云用起来。

有三点让人感触良多：

第一，是腾讯少见的用一个点调动了全局。

本质上来说，自研上云这个过程，其实是集整个腾讯自研业务的全部技术能力，参与、帮助腾讯云的能力建设和打造，是一个少见的能够通过一个技术底座，调动全公司之力参与的超级工程。

比如K8S的技术，在内部叫TKE，它不是腾讯云的一个部门自己去研发，然后给腾讯所有的业务去使用，而是由全腾讯所有的K8S的团队，通过开源协同的方式共建。一方面，业务自己用云的水平得以提升，另一方面，通过开源协同的方式建设这个能力。这个能力的增强和成本的下降，最终也会让行业使用腾讯云的客户得到这样经过反复打压测试后提升的更成熟的云产品。

第二，是全公司的技术团队得到了一次很好的穿透对齐。

穿透对齐是企业文化里常见的一个表述，但是，通常情况下的传统对齐比较形式主义，往往是企业的创始人发一封全员信，或者全体员工被号召去读一本书，都叫穿透对齐。

像腾讯这样体量的公司，穿透的难度是很大的。从这个角度上，CSIG和自研上云部门建立的协同机制，以及在这个机制下协同、对抗、相互质疑的过程，会让原本散作满天星的腾讯技术人，能够建立一种深厚的战友情谊，同时也对云的应用有了更强的精神共识。

而按照美国科学哲学家托马斯·塞缪尔· 库恩的名著《科学革命的结构》所阐述的那样，一个主流范式（云原生）的应用，除了技术上的交叉叠加外，最重要看在什么程度上被承认为共识，而共识的渗透率决定了这个技术范式的影响力。

毫无疑问，自研上云后的腾讯的整个技术文化，将产生巨大的变化，而其中之一是更深的共识。

第三，当这种共创作为一种机制保留下来后，腾讯的组织结构也会发生微妙的变化，比如上云后组织架构和职能的变化，包括运维职责的变化；研发、测试和生产环境如何在混合云中共存；资源预核算的变化；故障处理流程的变化等，整个技术体系的组织都要准备跟着公有云转变。

组织架构的变化也会带动三重价值。

第一是业务价值，业务的研发效率会更高，从0到1开发一个新产品的时间大大缩短；研发团队不需要从0开始开发各种组件和工具，可以更专注业务研发。

第二是工程师价值，工程师可以使用到整个业界最标准化的服务，基于公有云的研发模式，能够离开封闭的开发环境和组件，让自己对外、甚至对整个世界输出，这无疑给了工程师更多的获得感。

第三是客户价值，可以给行业输出非常多的公有云的经验，让客户用到更好的云，推动整个国内数字化水平的提升。

2017年3月，计算机架构领域两位巨星级人物David Patterson与John Hennessy在斯坦福大学发表演时预言——计算机体系结构将迎来一个新的黄金时代！

因此，超级场景产生超级云——腾讯自研上云的核心价值是让腾讯庞大的业务场景变成驱动腾讯云技术进化的新动能，最后产生世界级的云创新，建立属于自己的计算科学体系架构。

这一天，在走向未来中渐渐到来。

END