从腾讯学，腾讯技术的上云之路
共 5179字，需浏览 11分钟
· 2022-07-25
2018年，潘乱写了一篇文章《腾讯没有梦想》，让行业重新审视这个中国互联网巨头，后来在知乎上，腾讯技术员工发起了一个帖子：腾讯也没有技术。
腾讯技术员工开始在内网反映：
”一开始觉得，我们自研的组件能做到海量高并发，觉得非常牛。但看到业界其他开源的组件后，慢慢觉得，别人比我们牛。如果我们一直在使用腾讯内部的技术组件，慢慢会跟行业技术脱轨，并会越来越落后。“
”行业基本上已经开始容器弹性扩缩容了，自动伸缩完全自动化。但QQ还是要申请服务器，再去扩容，从业务上来讲，业务无感。但从技术上讲，研发效率和基础技术还是落后。“
”kv存储的value只有字符串一种类型，所以要写很多业务逻辑代码，把一堆代码序列化，再塞到kv中。但如果使用redis，完全可以很少的代码，做相同的需求。“
”如果还是按照腾讯内部自研轮子工作，就算掌握了那些组件又怎样？出去之后个人不会找到特别好的工作。“
”一个封闭的循环，不与外部接轨的情况下，技术演进的唯一动力就是业务需求，最终业务发展到瓶颈之后，技术发展也会陷入停滞，就会形成一个自研-优化-推翻的循环了。“
最开始，技术委员会会在内网帖子下面盯着，并对具体问题进行认领。后来帖子多了，认领不过来，只能在帖子下面回复”收到“。最后帖子后面追加了大量吐槽，完全负能量走势了。
2018年9月30日，腾讯进行了一次大的组织架构调整，称为930变革。
这次变革主要解决腾讯老员工反映普遍的几个问题：
对于汇报、PPT、评奖和分享的重视，超越了工作本身；
微信群越拉越多，群里真正解决问题的人反而越来越少；
专家越来越多，高质量的创新反而越来越少，沦为了养老院；
战略上缺少大将，中高层权利板结；
规则屡屡突破，价值观摇摆，公司早期优秀文化被稀释；
腾讯管理层意识到，过去以产品为导向的割裂的技术栈，不仅产生了大量的浪费，也无法有效支撑新时期的业务创新。另一方面云计算不断发展，腾讯很多业务和工程师无法去拥抱云原生技术，上云已是大势所趋。
腾讯高层推动了组织调整，将原来的7大事业部调整为6大，新成立了云与智慧产业事业群（CSIG）、平台与内容事业群（PCG）。同时还成立了技术委员会，目标是打造腾讯特色的技术中台。
而今天，我们的目光，聚焦于腾讯的技术中台上云之路。
930变革3个月之后，腾讯宣布了两个技术战略：开源协同和自研上云。
开源协同的目的是推倒公司内部的技术烟筒，让封闭在烟筒内的技术人员可以建立连接，互相看得见，实现一个中台梦。
自研上云的目的是对公司技术价值观和研发文化的全面审视。
整个战略推动是自上而下的，不同于以往自下而上的赛马文化。
930变革之前，腾讯ToB业务负责人汤道生曾经向马化腾和刘炽平提了一个技术变革的条件：公司要全力支持CSIG推进腾讯内部自研上云的技术战略。
因为集团已经明确了，以CSIG牵头去做腾讯的ToB业务，但CSIG却回答不了一个用户问题，就是：腾讯自己的业务上云了吗，你们自己有没有用腾讯云？
这是个灵魂拷问，如果连微信、QQ都不用腾讯云，你怎么去说服客户去用腾讯云。
那么腾讯云是整个腾讯的云还是仅仅是客户的腾讯云。
反过来说，微信、QQ非常稳定，如果微信、QQ也在用腾讯云，客户将非常直观的感受到腾讯云的价值。
客户将非常有意愿，让自己业务上用上已经被微信和QQ充分证明过的技术积累和技术优势。
但，在930之前，这个答案是否定的。
以QQ发展为例，早年QQ不盈利但用户量很大，那个年代还是一个服务器比人贵得多的年代。为了应对网络不稳定和租不起服务器的困扰，腾讯在即时通讯实现时，采用的是UDP协议，而没有选择TCP协议。TCP协议虽然传输稳定，但需要一直维持连接，费服务器。UDP虽然会丢消息，但传输快，省钱。
后期，随着QQ用户的不断增多，技术团队围绕于服务端做了大量的优化，包括算法、降低CPU消耗，底层能力放到数据库等工作。
最终实现了腾讯系产品，如QQ、微信的”海量之道“的雏形，在PC时代迁移到移动互联网时代，依然可以支持海量并发，稳定也是当年微信迅速超越米聊的原因之一。
技术人员深扎业务，帮助业务快速发展，茂密生长，这是好处。但问题是，技术专用、人员专用，一个业务的技术积累很难复用到其他业务上。
如何让腾讯海量之道复用到腾讯其他业务上，进而以云的形式提供给客户，这个是云与智慧产业事业群CEO汤道生需要考虑的第一个问题。
云计算发展到今天，各家云厂商的基础服务能力过于同质化，毛利率低，竞争激烈，厂商很痛苦。
云计算被定义为水电煤，非常重要，但并不稀缺，对于客户来说，不同云厂商只是采购方式的不同。同时，资源型公有云业务，很难做出高利润。而且，当前云厂商的目标用户不应该是互联网企业，更应该是传统行业用户，而他们对于云的需求，不仅仅是资源。这一切都决定了腾讯云的定位，不能向资源型云服务商发展。
而腾讯的海量之道，正是腾讯云可以赋能于传统行业用户的主要价值。
于是，汤道生决定：自研业务、自研产品的转型，是基于云的架构来设计，是时候了。
腾讯自研业务上云，要做的第一件事就是以什么样的方式上云。到底是虚拟机，还是K8S这层。
虚拟机和容器是完全两种不同的上云技术。
虚拟机是通过物理机加一层应用，把一台物理机虚拟切割成多个云服务器，然后实现底层资源的灵活调度，是最基础的云计算技术。
容器则是在物理机操作系统层面，把应用和依赖环境集成打包，在迁移过程中，不需要依赖操作系统，比虚拟机更轻量，对各种部署环境也更适应，是一种更灵活的调度技术。
业务方决定，必须通过容器上云，根本性建立起面向未来的底层技术架构。
过去，每个业务为了应对自己业务可能面对的流量高峰，每个团队都冗余一部分资源池做空闲资源，相当于每个业务都有自己的buffer，一个业务一个，6个业务就有6个buffer，浪费资源。
而自研上云之后，各个BG的资源汇总到一个池子里面，可以只留一到两个buffer。共用一个池子之后，可以错峰利用，算力节省。
总之，上云之后的第一个收益是成本的优化。
但成本这件事，在不同BG情况则有所不同。有的BG的产品非常赚钱，成本在这里面是非常小的一头，对成本没那么敏感。
而且，BG负责自己的资源池子，更可控，好调度，好管理。
而且以前的技术设施已经和物理机有了很好的绑定，如果底层切换到容器云上，短时间内并不比管理物理机更省事，还得在技术上折腾，存在不稳定的因素。
比如腾讯云有自己的容器调度平台TKE，但各个业务BG也有自己基于K8S实现的容器弹性调度平台，且和业务结合紧密。这种情况怎么办？
每个BG在底层容器云调度上的投入人员，少则几十个，多个上百个，这么大的团队做了很多年。现在让统一迁走，统一替换掉，势必遇到很大的阻力。
但在汤道生看来，只有让业务长在云上，完成云原生的改造，才能让腾讯2w多技术员工随时看到外面的世界，才能保持腾讯技术上的先进性，底层容器的统一，是云原生改造的第一步。再难也要走。
云原生已经成为了技术的共识，于是大家同意，内部自研业务必须上到腾讯云的TKE上，并得到了所有事业部BG老板的同意。
汤道生负责的CSIG，主要是面对ToB业务，而其背后提供弹药支持的是TEG。TEG，定位是做基础设施，比如数据中心、服务器、安全、存储、计费等。
TEG团队的明星产品是存储，存储团队技术的积累来源于当年QQ空间产品的需求，而汤道生当年正是负责QQ空间业务，于是CSIG和TEG之间有着浓厚的”战友情“。
而这次推动开源协同与自研上云两大技术战略，正是由TEG和CSIG共同承担。
在推动自研业务上云路上另一个绊脚石是”魔改“。
比如推动推动业务迁移到容器云平台时，发现各个BG是在CSIG做得TKE基础之上包装了外壳，在外壳之上做管理工具、调度，于是集团内部各个BG出现了各种XXTKE的产品。
每个BG魔改，都有自己的理由。
比如游戏业务，不同游戏有着不同的架构，做云原生改造有巨大的工作量。而且，游戏业务属于内容型服务，过去的精力在于内容打造上，架构的技术投入本来就少，想要里面搞定云原生这件事不现实。
另一个原因是，腾讯云早期的容器化产品并不稳定，经常出现成功率低或pod之间通信不稳定情况。这些情况会导致业务上的抖动，各个BG的研发团队既要面对云原生、容器统一的压力，也要面对各个事业部老板的业务稳定性压力，难以抉择，不得不魔改，造轮子。
”之前的调度系统可能不够自动化，但稳定可控。切到云原生后，即不可控，也不稳定，在重视用户体验的业务上，往往被一票否则“。
同时，腾讯内部鼓励自下而上的创新，也容忍失败，很少有自上而下的铁血下达。很多团队自研的技术组件确实解决了自己的业务问题，有的还做得很成熟。研发团队和自己的产品建立了很深的情感，说推倒就推倒，感情上很难接受。
”我凭本事打下的江山，凭什么要让出去？“，很多技术团队的同学如是说。
对于这种情况，汤道生说：”我没有杀手锏，没办法强迫业务团队的技术决策，只能从提供价值的角度去做“。
腾讯内部，自下而上的行动会很迅速，自上而下的时候，往往先把道理讲通。
腾讯云副总裁高向冉，最开始推动自研上云时比较随意，”大家来上云吧“。
一说上云，很多业务都来了，自己主动申请。
但到了云平台官网一看，没有符合自己需求的云产品，一下就炸锅了。
有人到内网吐槽：”自研上云，就是自己研究怎么上云“。
跌跌撞撞，2019年2月，终于有了首个自研业务上云的产品。但可惜的是，比原计划delay了3天。
delay的原因不是卡在技术上，而是卡在了流程上。
原定周五交付，但因为账号、计费等流程细节没有梳理好，腾讯云搞到了凌晨2点，后面又是周六日，最后延期了3天。
这是一个缩影，反映了腾讯经历了十几年技术封闭之后，在不同技术壁垒下尝试必然面对的问题：尴尬、琐碎、曲折、痛苦。
第一个自研上云之后，压测发现，云平台的性能比物理机性能差了15%，最初的目标是相差8%，这一下就差了一倍多。
腾讯有着大量面向用户端的体验型产品，如果性能差了这么多，用户体验必然受到影响。
整个2019年，CSIG团队参加自研业务上云的周会，都会碰到相似的提问”这个问题如果你们解决不了，我们就不用了“。
2020年初，腾讯自研业务上云，轮到了微信团队。
微信架构团队抛出的第一个问题是：”云原生改造后所有架构都要做到多地三园区容灾，容器团队最好可以出一个报告，看看到底哪些模块可以做好，哪些做不好“。
多地三园区容灾的意思是，要在不同的地方搭建完全相同的系统，某一个地区出现重大故障后，可以无缝迁移到另一个地区。一个城市下面，要有三个机房，三个机房的网络和电力要是独立的。这样三个机房中出现一个故障，就不会对整体业务有影响。
这个要求是合理的，是微信过去踩过的坑。2013年，因为光缆被挖断，微信曾经断网几个小时，自此之后，多地三园区容灾，是微信的基本架构容灾要求。
类似的，有的业务因为架构老，还有固定IP的要求。但云原生的特点就是无状态，不关心容器的IP。这曾一度让CSIG团队怀疑，业务是不想上云，变着法提一些过分的要求。
但他们很快发现，这些看似不合理的要求，其实是帮助腾讯云发展出更强壮的肌肉，成为服务外部客户的新能力。
”我们的客户越来越专业，要求和标准也越来越高，这是好事“。
慢慢的业务也从最开始关注于稳定性问题，逐渐转变为了关注于服务是否跑饱和了。
打磨了内部这么多磨人的业务，腾讯云也更有信心去服务好更多的客户需求了。
在整个自研业务上云过程中，业务方是甲方，腾讯云是乙方，两者沟通上并不对等，建立相互之间的信任就非常重要。
”大家相互沟通几次，一起多解决一些问题，多做一些技术交流，一块多吃几次饭，很多问题都可以解决了。“
”把内部业务当客户来服务，怎么蹂躏我们都行，我们的目的是帮助他们做好。“
逢山过山，遇水搭桥，没有什么捷径。性能不行了，就把性能提上来；成本不行了；就把成本降下来，服务能力不够；就把服务细节做到位。
云原生可以覆盖开发质量、业务交付周期、业务运营难度，也可以帮助每个技术人员成长，提升技术人员幸福感，这是云原生的好处，也是大势所趋。
不优秀的架构、生产环境的缺陷是业务发展的债务，产品和业务团队要知道，不能债务过多，负债而行。每过一段时间，就要停下来偿还利息和债务。不然债务总有一天会反噬你。
每一个参与了自研上云的人，都可以总结出诸多上云的好处，它让腾讯云更强大了，让业务资源调度更从容了，技术人员视野更宽广了，公司技术交流更频繁了。
腾讯自研业务拥抱云原生，可以看作是腾讯这家公司”危机“文化的外显。
公司完成了既定战略，管理者降低了成本，拆掉了部门墙，新的技术平台让基层技术人员跟得上技术变革的潮流。
云计算的上半场是围绕云的集结、争夺、会战。而云计算的下半场，是自研上云，业务看不见云了，但云在脚下。