腾讯在命运的棋盘上砸下一颗钉子
文 | 史中
2013年，腾讯市值冲破千亿美元，反超百度，一骑绝尘。
在当年举办的腾讯WE大会上，人们眼巴巴等着马化腾说出豪言壮语。他说：
“我们很怕。”
（一）“危险的土地”和“迷惘的动物”
张志东的QQ号是10002。
自1998年和马化腾一起注册腾讯，他就撑起了底层技术架构，坊间传说，他写的QQ架构，直到用户过亿，还能微微一笑，轻松扛住。
腾讯16岁时，张志东急流勇退——辞任首席技术官。从那之后，鹅厂 CTO 的椅子一直在熠熠的阳光下空缺，像是半首等待续句的诗。
而这把空椅子，正是我们故事的开端。
放手前，张志东主导做了两件事：
第一，把腾讯最王牌的技术团队安顿在技术工程事业群（TEG），托付给老部下卢山。
第二，在腾讯建立了一个内部论坛，名叫“乐问”。
这两件事看似平常，其实，他们都与“危险”二字相关。
表面直言快语的卢山，内心其实奔涌着对技术细腻的珍视。这种珍视，会在腾讯面对危险时爆发出强大的力量；
而“乐问”论坛，恰恰能够发现危险。成立第一天，乐问就定下规矩：哪怕最普通的工程师也可以毫无鸭力发帖吐槽。一线战士的声音未经修饰，虽然刺耳，但必定真切。总裁办只有每天被这样的声音“锥心刺骨”，才不至于沉溺在幻象中。
但是，岁月奔流。
危险的脚步终究还是迫近了。
2018年，卢山面前屏幕闪烁，乐问上的一个帖子赫然写着：来到腾讯就像来到技术沙漠！
吐槽来自一位新员工——他怀着憧憬加入腾讯，为了快速进入状态，想要参考一些其他团队的代码成果，然而翻遍了全公司系统，他懵了。竟然什么都找不到。。。
眼前每一个字都像一根钉子，把卢山的心绞得生疼。
事情为何变成了这样？
隐喻也许就藏在腾讯的 Logo——那只企鹅身上。
QQ的企鹅是动物，腾讯的王牌产品微信、腾讯视频、王者荣耀等等也都可以看成是动物。
《动物世界》里的剧情大家都熟悉：要想统领狮群，新狮王必须先打败竞争者，然后终其一生随时准备迎战新的挑战者。
同理，当年每一个从腾讯跑出来的王牌产品，都是先在腾讯内部击败了所有类似产品，才冲进“大草原”，在众目睽睽下和其他对手博弈的。
如此残酷的生存筛选下，造就了世人熟知的“赛马文化”。
赛马
想要马儿得第一，不仅要速度快，还要动作灵活。一旦和别人的协作，就怕遇上“猪队友”，那还不如小团队自己干，把所有的技术都抓在自己手中。
回到2018，从卢山眼里的倒影，我们恰恰可以窥见整个腾讯的版图：
每个“动物”（产品）都坐拥一座自己的庄园，庄园里运转着支撑它主人一切的肥美牧草（底层技术）。然而，庄园的大门紧闭，谢绝参观。。。
沙漠并非没有草，只是绿洲都被围在了栅栏里。
这让对技术负责的卢山感到脊背发凉。五指毕竟难敌一拳。时间分秒流逝，腾讯技术将越来越分裂，越来越脆弱。
他当然奋力尝试过拆掉各个庄园的围墙，比如尝试把各个业务的技术拿过来“托管”。但是，时间一长，被托管团队就觉得自己失去了对技术的控制权，很没有安全感。
“我凭实力打下来的阵地，来接管的人水平还不如我，凭什么让我缴枪？”有员工曾经发过这样激烈的朋友圈。
事实上，卢山的数次冲锋都以不了了之告终。
作为顾问的张志东时不时回来找卢山，强烈建议他赶紧推进。卢山心里难受，没压住火：“我不是不知道这件事重要！但硬推根本不靠谱！”
杠到最后，卢山 emo 了，跟张志东说：你就不应该退休。。。
故事进展到这，有浅友可能会出主意：那不拆围墙就不拆呗，只要腾讯这片土地上的动物们都活蹦乱跳，又有什么问题呢？
怎么可能没问题？
每个“动物”都心知肚明，还有另一圈玻璃幕墙就高耸在草原周围，这个围墙就是——人口天花板。
一个普通人大概不需要两个QQ号或者微信号；每个人每天也只有24个小时，娱乐休闲的时间必然存在恒定上限——消费互联网的空间是有边界的。
况且，中国“消费互联网”的土地上，当然不只有腾讯。放眼望去，各大厂商的“动物们”扩展空间都已十分有限了。自然法则非常残酷：一旦生存空间难以继续扩展，等待它们的将是惨烈的“内卷”宿命。
到时候，各自庄园里储备的这些“牧草”（底层技术），还够不够鲜美（先进），够不够廉价（成本低），能不能支撑得住惨烈的竞争，谁都打不了包票。
两条路摆在腾讯面前。
向左走，守在原地和挑战者们拼个你死我活；
向右走，走出大草原，寻找一片新的栖息地。
当时（2011年），手中资源充足的腾讯选了“我全都要”：
“留下一半人马在原地厮杀”
+
“派出另一半人马擎旗远征”。
现在，我们把目光转向这支“远征军”。手握旌旗的人，并不是想象中铁面长髯的骠骑大将军，而是有一张和善面孔，他就是汤道生。
这支远征军伍叫“腾讯云”。
（二）向“中央草原”进发
讲到这里，不妨暂停几秒，插播一下汤道生的“艺术人生”。
“偏师远征”，是汤道生不断重复的人生剧本。最著名的就有三次：
第一次，是2005年之后，汤道生带着QQ秀和QQ空间杀出重围，让QQ不再只是一个聊天工具，还成了大家展示自我的明媚舞台。
第二次，是2012年之后，微信异军突起，汤道生又带着QQ出走，在“年轻人”这片肥沃的用户群体中安顿了下来。
而这第三次，就是腾讯云了。
“腾讯云”比“腾讯”多了个云字，干的事情自然大有不同。简单区分，就两句话：
过去，腾讯钻研的是“技术上面的产品”（也就是那些动物）；
未来，腾讯云要钻研“产品下面的技术”（也就是动物吃的牧草）。
好，了解这些背景后，我们不妨再回到2018历史现场，站在汤道生身边，我们同样能看到他眼里倒映的“危险”。
他去和企业客户聊生意的时候，人家一定会问：既然你腾讯说要用技术来服务我，那么，腾讯自己的微信、王者荣耀到底用没用腾讯云的技术？
他的答案有点羞涩：只用到了一些。
“你自己都不全用，凭什么让我用？”
汤道生无言以对。他清楚，如果陷入这个死循环，腾讯云这支远征军终究也很难帮腾讯找到新出路。
讲到这，估计浅友们都看明白了。站在当时，解开“汤道生的外患”和解开“卢山的内忧”的方法竟然是相同的，那就是：
一秒都不要等！
赶快拆掉各业务的“庄园围墙”！！
让他们住进一片“中央草原”上！！！
此时，在腾讯技术栈的博弈天平上，汤道生也坚定地站在了“统一派”这一边，和卢山并肩成为两个重磅砝码。
即便这样，形势仍然很微妙，各个业务的负责人虽然也理解上云对腾讯的意义，但受到各种内部阻力，很难形成共振，同时把手术刀挥向自己。
这就像七个葫芦娃分头行动，就会被妖精“各个击破”，爷爷总也救不出来。。。
动画片的结尾已经昭示了答案，只有一个办法能成功：让七个葫芦娃合体！
2018年夏末，耳听马蹄奋急，远方悬崖迫近，CEO马化腾和总裁刘炽平下定决心，把所有业务线负责人紧急集合起来，开了三天三夜的会，讨论改革方案。这就是著名的“香港会议”。
憋坏了的卢山和汤道生，终于有机会在大家面前把计划和盘托出。
卢山的建议是：把腾讯的技术宅们重组一个“联合战队”，合力研发像积木一样的“基础技术模块”，从此所有模块完全代码透明，腾讯各业务需要哪块就用哪块，这就是“开源协同”。
汤道生的建议是：这些积木，请大家不要再拿回“庄园”里，索性你们都来腾讯云这片“中央草原”上，搭建起没有围墙的新庄园。这就是“自研业务上云”，简称“自研上云”。
表决时刻，所有业务负责人一致举手。
历史的天平，倒向“统一派”。
2018年9月30日，大事甫定，腾讯鼓起勇气打开胸膛，让体内积聚数年的暗流对外奔涌——重组架构，成立新的事业群，史称“930变革”。
此时俯瞰腾讯这片土地，迷惘的动物们眼神重新锋利，葫芦娃们开始合体成小金刚。
自研上云的故事，也由此拉开大幕。
（三）效率！效率！效率！
如塞伦盖蒂大草原上的角马迁徙，腾讯自研上云必然是一首混杂着雄壮与凶险的命运之歌。
香港会议上，各路老板同意上云之后，一起看向汤道生：“那你定个时间表，多长时间能干完？”
汤道生想了一下，伸出手指：三年！
你知道，腾讯的管理方式不是“从上到下”的，虽然大方向定了，但上上下下这么多人，还是要慢慢说服。人家业务就是不上来，你也强迫不了的。。。况且，腾讯云还要做好技术准备，怎么能支撑好腾讯的海量业务，我们也要花些时间。
这事本身确实是有挑战的，三年有一定拍脑袋的成分，但当时也没办法算得非常仔细。
汤道生回忆。
可是，君子一言，驷马难追。“三年”说出口的一瞬间，倒计时就开始了滴答作响。。。
好消息快马加鞭送回腾讯云。首先感觉鸭梨山大的，就是邱跃鹏。
邱跃鹏是腾讯云总裁，也是刚刚成立的云与智慧产业事业群（CSIG）的COO。腾讯云服务了这么多客户，如今迎来了最大的客户——腾讯自己。这对腾讯云来说是超级大的挑战。
同样的压力，也很快压到王慧星身上。
王慧星是腾讯云的 CTO，专门负责腾讯云的技术，技术但凡有裂缝的话，面对超大客户的重压肯定是要跪的。。。如今，是骡子是马，到了出来遛遛的时候了。
汤道生还向腾讯云这群人转达了总裁刘炽平的“灵魂拷问”：
搬家上云之后，腾讯的运营成本会怎么变化？
刘炽平是个温和的人，话一向说得委婉。我帮他翻译成大白话就是：腾讯各个业务都搬到你腾讯云上，要是运行起来比以前花的钱还多，那绝对不行！
等等！咱们之前一直默认，大家搬上云一起过日子肯定会比原来更省钱。可是。。。真的是这样吗？
“真的是这样！”邱跃鹏斩钉截铁。
他给我科普了其中的原理，我用图画翻译给你。
咱们刚才一直把计算力的底层技术比作草原，现在不妨放大一点，看看“草原”的内部结构。
我们可以把它分成两层：
1、基础设施层（IaaS）
要想支撑用户上亿的产品，你需要成千上万的服务器，每台服务器都一刻不停地计算，咱们掀开机箱盖，把它想象成无数个不知疲倦的“工人”。
2、平台层（PaaS）
有一群只会“傻算”的工人还不够，还需要一些不同种类的“工头”（可以理解为特定的程序），负责调动“工人”去算具体的任务，比如是去存储数据，还是转发消息，还是查询信息等等。
有点抽象么？咱们拿微信举个例子吧：
“消息模块”就是一个“工头”。
你给媳妇发一条微信，你的消息会先传到微信的服务器里做临时中转，“消息工头”看到这个任务：“哦是我们小组的工作”。它就会指挥手下的“工人”，找到你媳妇的微信端口，然后把消息转发过去。
“存储模块”也是一个“工头”。
你在朋友圈发了一张照片，这个照片也被送到了服务器里，然后微信的“存储工头”会调动手下的一群“工人”把你的照片放好，然后你的朋友们就能刷到这张照片了。
注意！这里藏着一个有趣的真相：无论是微信、QQ还是王者荣耀，虽然他们看起来是完全不同的 App，但在最底层，为他们干活的“工人”是一毛一样的。
这样的话，就出现了一种可能：
如果把微信、QQ、王者荣耀等等腾讯的业务同时放到腾讯云的“大资源池”上，它们不就可以共享底层的“云工人”了么？
你用完了我用，我不用的时候给他用。反正服务器里的“云工人”只吃电，也不知道累。就像共享单车一样，大家一起骑车，肯定比每人霸占一台单车利用效率要高多了。
你看，这就是云计算能省钱的基本原理。
好了，科普结束，回到我们的故事。
2019春节一过，游戏、QQ、微信的基层技术团队就“响应上级号召”，排着队来腾讯云考察。
虽然眼里有藏不住的怀疑和审视，但大家还是客气地在云上开了测试账号，把自家的“测试用例”放上去。（所谓“测试用例”，就是一套模拟成千上万用户“极限并发”的程序，只有扛过测试用例的爆锤，在实战中才能堪大用。）
腾讯云这群人焦急等待，就像期末考试等待老师念分的孩子，大气不敢喘。
第一天，沉默，第二天，沉默。。。第三天，无数问题像乱箭一样射来。。。
比如，微信的同事就发现了一个关键的事儿：你这个“云上工人”为啥比我们的“云下工人”弱啊？只有我们工人85%的水平？
这个问题，剑指云计算的核心软肋——虚拟化损耗。
刚才我们说了，云的本质就是把“工人”让大家共用。可是，直接共用的话，就像好几拨大妈在一起跳广场舞，这边放“套马的汉子”，那边放“小苹果”，相互之间难免冲突——所以必须在“云工人”之间打好“隔断”，这个过程就叫虚拟化，隔出来的隔间叫“虚拟机”。
腾讯云的虚拟机，名字叫 CVM（Cloud Virtual Machine）。
打隔断的工作谁来做？没别人，还得是“云工人”自己来做啊，所以。云工人们得分出15%的力气用在维护“隔断”上，留给 CVM 就只剩下85%的力气了。。。
微信的老师傅摇摇头：这可不行啊。
一来，白白损失了15%的计算力，为了和原来的计算力持平，我们就得多加15%的虚拟机，成本扛不住；
二来，在搬迁的过程中，肯定会存在一半在云下一半在云上的“脚踩两只船”的时刻，此时两边的计算力差太大，会造成服务不稳定的问题。。。
刘炽平的直觉果然准，他担心的事儿眼看还是要发生——算理论账的时候，怎么算都是效率更高；可是真到了实际搬迁时，各种边边角角的问题一来，到底效率如何还真不好说。。。
微信团队回去算了半天，然后提出来：
虚拟化损耗不用降到0，咱们降到8%，行不？
CVM 的技术宅们几欲先走。。。心说：这个损耗水平，在地球上也没人能达到啊，要不您去火星问问？
但正如前两章所讲，自研上云事关腾讯接下来20年的生死安危。这个时候 CVM 要是缩回去，那就妥妥成为让腾讯变成“技术沙漠”的历史罪人。。。
不能退，说什么都不能退！
CVM 团队的刘洁欣回忆，为了搞定“8%”，那几个月他们一群工程师就快要把虚拟化系统给拆碎了。
说白了，虚拟化要想提效，主要就是和 CPU 死磕——为了把 CPU 之间的通信时间降低几毫秒，老师傅们甚至要重写处理器之间的通信方式；更夸张的是，还有一个小分队深入芯片内部的指令层，一条条筛选优化，哪怕只省出几颗电子传输的路程，也会在大规模运算的时候把效率提高一点点。
功夫不负苦心人，几百项优化一个个堆叠，别说，虚拟化损耗直接干到了5%。
但 CVM 这群人半口气都顾不上歇。
因为。。。虚拟化损耗仅仅是诸多“乱箭”中的一根。。。这边微信话音还没落，那边QQ团队又找来了：为啥测试的时候网络丢包率这么高？网络稳定性要提高哦！那边游戏团队又找来了：我们原来自己部署了很多运维工具，现在上了腾讯云，有的工具对接不上了，这可不行哦！
刘洁欣瞬间感觉到一股强大的人肉DDoS。。。
此刻，我们不妨从混战中把视线抽离出来，再回到空中俯瞰。
2019年的腾讯，人心如海潮涨落：
各个业务线的人，一会儿解决了一个技术难题，觉得上云之后效率就是高；一会儿又发现了新麻烦，觉得上云效率也一般嘛。。。就这样一会儿信心满怀，一会儿垂头丧气，反反复复来来回回地摩擦。。。。
不过，王慧星心里倒很笃定：这样的摩擦不会一直持续下去。
因为，他手里握着一个“大杀器”！
（四）星星海
2018年，就在“930变革”前不久，腾讯云的一支名为星星海的团队拜访了AMD。
此次行程，他们有一项重要的议程——敲定腾讯第一款自主研发服务器“星星海”的定制CPU的技术参数细节。
端详着手里这颗 AMD 的处理器，这帮人既激动又纠结：
一方面，测试指标显示，这一代 AMD 处理器非常符合腾讯云的要求，预计可以把计算效率提升一大截。
但另一方面，AMD 作为服务器处理器还是个新鲜事物，当时的云计算厂商中没人敢把它大规模投入使用。
冒险上 AMD，万一搞砸了，就会浪费巨大的研发资源和宝贵时间；不上 AMD，腾讯云就可能错过弯道超车的历史机会。。。
从某种程度上说，星星海团队手里攥着一枚硬币，这枚硬币的正反，将会决定腾讯云的未来的发展。
要不要冒这个险？
讨论了一上午，他们决定做。
“技术人只能相信技术。看过技术参数，大家找不到不用 AMD 的理由。后面哪怕遇到很大的 Bug，也要死活搞定。”星星海团队的同学回忆。
故事闪回到2019年，就在腾讯云 CVM 被各个团队“DDoS”到晕头转向时，好消息传来，定制的 AMD 版“星星海服务器”开始量产了！
腾讯云工程师们喜大普奔。
因为无论是微信、QQ还是王者荣耀，他们都只能作为客户（最多是大客户）去市场上买已经存在的服务器。就像去饭店点菜，只能选菜单上有的菜品；可是腾讯云作为一个巨大的计算资源提供者，完全有能力亲自下厨，做“菜单上没有的菜”——按照最优的技术路线定制服务器。
没错，这就是王慧星他们心心念念一整年的“大杀器”。
正如汤道生所说，“我是没有杀手锏的，只能一点点说服人家上来”。星星海服务器，就是最“香”的论据。
冥冥中，“基础设施层（IaaS）上云”的天平第一次确定无疑地倾斜向腾讯云这一方。
“唯一的问题就是时间。”刘洁欣回忆。
每年春节，是腾讯各个业务服务器最忙的时候，因为要支持大家过年玩游戏、发微信、摇红包。。。CVM 团队特别想在2020年春节就抛出这颗“震撼弹”，让业务们都用上星星海。
但是，星星海裸服务器2019年10月才交付到 CVM 团队。
毕竟是新款处理器，很多地方需要调整，CVM 团队又加班加点用了两个月才搞定虚拟化系统适配，交给各个业务进行测试时已经到了年底，距离春节只有1个月时间了。
大家双手合十，祈祷不要出问题。
祈祷果然。。。没用。。。
各个业务汇总的 Bug，又如乱箭射来。
问题有多少呢？多到需要列在 Excel 表格里才能捋清楚。
时间分秒流逝，CVM 这群人只能拼了：他们同时对接N个团队，手动维护了20个 Excel 表格，每天半夜都要把各个项目的进度检查一遍才能睡着，第二天起来，还得接着接受新的“灵魂拷问”。
过年前两周，CVM 进入了“至暗时刻”。。。
微信团队为了保证除夕全国人民能顺利抢红包，提前对所有服务器都进行了一轮“压力测试”。可是，压到星星海服务器的时候，报出了意料之外的失败。
大家一下懵了，要是星星海存在什么 Bug，那14亿人春节发微信红包。。。。
这一刻，星星海实验室、CVM 和微信技术团队根本顾不上切分是谁的责任了，像下河救人一样，一起跳进代码的汪洋。
很快，问题定位出来：是 CVM 网卡虚拟化模块存在一个小问题，很多虚拟机同时进行大吞吐作业的时候，就会把网卡堵死。
微信技术架构部的负责人Stephen Liu回忆：
那种情况下，很多深层改动都来不及了，我们紧急商量，决定把虚拟机切分得更细，然后把消耗网络的应用和不消耗网络的应用混部在同一台设备上，减轻网卡并发压力。
总之，先扛过春节再说！
春节前五天，代码修改完毕，微信的师傅们颤抖着双手开始压测。
10%、20%、50%、100%。。。压测通过！！！
全国人民发红发的大事儿，总算稳了。。。
春节假期转眼来临，微信团队和 CVM 团队的同学们虽然肉身回到老家团聚，但灵魂还守在电脑前，一直盯着后台监控，生怕再有什么问题。
从除夕到初七，人们拜年、传视频、发红包，一波波洪峰冲击微信服务器，但是星星海丝般顺滑，没有任何问题。
所有人长出一口气，高悬了几个月的心终于放在了平地上。
然而，就在这群人准备返回深圳生命不息折腾不止时，全国各地的鹅厂同学收到通知：暂缓复工。
新冠疫情爆发了。
（五）断壁残垣
故事讲到这里，就要花开两朵各表一枝了。
一边是腾讯各个产品投入史诗级别的抗疫战争，另一边腾讯云“自研上云”的工作进入了最艰苦卓绝的阶段。
我们先说腾讯云吧。
你还记得我们的比喻吗？云计算分为“云工人”（IaaS）和“云工头”（PaaS）两层。
之前我们说的“上云”，其实只完成了第一步：自研业务共用了“云工人”这样的底层计算力（云IaaS）。
但是别忘了，调度这些云工人的，依然还是各家的“旧工头”。
这有什么问题吗？
打个比方：这就像我住进了酒店，却不用酒店的客房服务，而是用自己的厨师生火做饭、用自己的服务员洗衣服晒被子。
你说这是住进了酒店，也可以，但这。。。似乎和真正的住进酒店又不太一样。
真正的上云，显然是要完成第二步：把自己家的“工头”解雇，共用“云工头”（云PaaS）。
之前说过，“工头”的种类很多，包括“计算调度平台”、“数据存储平台”、“AI和大数据分析平台”等等。这里为了简化认知，我们就说最有代表性的一个，“计算调度平台”。
腾讯云上的计算调度平台，使用了最流行的 Kubernetes “容器调度技术”，名叫 TKE（Tencent Kubernetes Engine）。
TKE 这个“工头”的原理很有趣：
你可以想象一下，它就像个“泡泡机”，把“云工人”包裹在一种叫做“容器”的泡泡里；
假如来了任务A，它就把任务A的代码塞进泡泡，让工人干。干完活儿，就把泡泡扎破，工人就被释放出来了；
下一秒来了任务B，TKE 就再吐一个泡泡，把任务B的代码塞进去，让工人继续干。如此反复。
从远处看起来，每秒钟都有无数个泡泡产生，也有无数个泡泡寂灭，就像孙悟空吹毫毛，左边变出百万猴子猴孙，右边收回成一把毫毛。
这一套以容器调度为核心的技术体系，可以大幅提高计算调配的效率，也能短时间扩容缩容。由于它最适合在云上部署，人们又叫它“云原生技术”。
如果非要比较的话，“云原生”和“非云原生”的技术差距，那就像加特林机枪和半自动步枪的差距那么大。
怎么样，听起来很厉害吧？
但是，问题来了：
相比上云第一步（使用 CVM 虚拟机），大家完成上云第二步（使用 TKE 为代表的云原生技术）的热情远远不足。。。
为啥不用呢？王慧星一个团队一个团队地跑，询问大家的困难所在。跑了一圈下来，反馈很残酷：
过去十几年，每个业务为了极致服务自己的用户，都对自家的“计算调度模块”做了很多定制化的功能。如果换成标准的 TKE，那好多功能就实现不了。。。
打个比方：我原来的半自动步枪上有刺刀，可以开罐头，你现在让我换机枪，我知道机枪更好，但你的机枪上有刺刀吗？能开罐头吗？
平胸而论，人家说得也有道理。
局面一度尴尬：强推标准化技术，微信、王者这样的国民 App 对用户的服务就可能降级，那肯定不行；不强推，腾讯自研上云的进度条就可能一直卡在50%，留下一屁股残垣断壁。。。
这个死结要怎么破呢？
回到历史现场，我们不妨再推开腾讯总办会议室的大门，来听听2019年腾讯云对总裁刘炽平的一次关键汇报。
会上，由于感受到大家上 TKE 的困难，腾讯云同事特地使用了“迂回话术”，说：“只要用了 CVM，那也勉强算是上了腾讯云吧 。。。”
他们心里想的是：留得青山在，下来再慢慢推动，总有办法。
可是，旁边一个人听到他这样讲，突然一嗓子打断：“不行！”
大家齐刷刷看向他。
这个人是卢山。
卢山对刘炽平一通输出，给他掰开揉碎讲了半天“云原生”的原理。然后给结论：“如果不采用云原生技术，仅仅用了云上的虚拟机，那根本就享受不到云的核心好处，最终，腾讯的技术仍然是割裂的，上云就是失败的！”
卢山心里急，话说得很重。
但是刘炽平完全听懂了他的意思，当即明确表态支持：所有业务必须走到“云原生”这第二步，才算完成上云。各业务必须配合！
站在今天回看，卢山这挺身一喊无比重要，它直接把自研上云的船头扶正，远离浅滩暗礁，节省了金子一样的时间。
其实，在腾讯内部，大家都听说过卢山的一句名言：“往死里帮云”。
这句话背后，有个颇为动人的故事。
之前我们提到，早年间为了统一腾讯的技术，卢山的大多数冲锋都没能成功，唯一成功的少数，就是在汤道生所带领的SNG（也就是当时QQ和QQ空间所在的部门）中实现的。
那时候汤道生刚刚开始他的第一次“远征”，率QQ空间杀出重围。
QQ空间里，藏着很多人杀马特的“黑历史”。
众所周知，QQ空间的一个重磅功能就是“相册”。而相册的底层技术就是“存储系统”。
汤道生本身就是做数据库出身，在彼时赛马文化浓郁的腾讯，他完全可以拉起队伍自己造一套存储系统，但是，他思来想去，把机会让给了卢山带领的 TEG 众将，原因是统一技术底座对腾讯更有利。
也正是因为汤道生的历史担当，才让 TEG 有机会磨练了一支存储队伍。
而后，存储团队的负责人谢明带着一群技术战士筚路蓝缕，不仅让存储系统服务了腾讯几乎所有产品，成为人人称道的技术底座，也在后来衍生出了腾讯 CDN、数据库等等领先于世界的基础技术。（有关这个内容，可以参考《腾讯的硬盘里，有中国互联网的昨天、今天、明天》、《腾讯数据库的三场战役》。）
而卢山钦佩汤道生的格局，才在汤道生第三次“远征”之初，说出了“往死里帮云”这句话。
卢山不仅是这么说，他还是这么做的。
拿到总办的认可之后，卢山把配合上云的工作交给了“运营管理部”。
运营管理部手握“尚方宝剑”，专门评估各业务对计算资源的使用情况，如果认为不达标，运营管理部是有权力让你整改的。
运营管理部的负责人 Eric 组织大家制定了一套“云成熟度模型”，每个季度都对所有业务云原生的程度进行评估，得高分不仅给奖状，还有奖金拿；落后的自然就会有压力。
各个业务线的中的“阻力派”一看，技术委员会这是要玩儿真的了。。。
卢山对云的“往死里帮”，甚至都到了魔怔的程度。
那天，卢山碰到了20年的老同事，平台内容事业群（PCG） 的技术负责人曾宇，他上来就劈头盖脸：“兄弟，你们得赶紧支持 TKE 啊！”
曾宇哈哈一笑：“怎么没支持？我都跟我们做容器的技术同学说了，要想继续做容器就加入 TKE 团队，不然就在内部找位置，找不到就走人，反正我们 PCG 肯定不会继续保留自己的容器平台了！”
听到这话，卢山反而有点蒙：“啊？你们都支持到这种程度了吗？”
当时我就感觉，20多年一起走来的老同事，虽然后来各管一摊，交流变少了，但大家的心其实在一起。很多老腾讯人嘴上不表达，但关键时刻全都在默默推动。
卢山感慨。
宜将剩勇追穷寇。为了掰正更多人的思想，那之后不久，卢山在一次内部大会上，当着曾宇的面又把这个故事讲给现场的基层同事。
也许有一天，我们会离开腾讯，但如果那时我们回头看，留下一堆技术上的残垣断壁，我们的心会不会痛？
卢山说。
说完，他看了一眼身边的曾宇。曾宇的眼里有闪光。
老战友卢山不遗余力，汤道生自然更是百倍加油。
“930变革”之后，在卢山和汤道生的联合推动下，腾讯成立了一个神秘的部门——“技术委员会”，这个部门由各大业务的技术负责人组成，相当于一个“分布式 CTO”。
而在技术委员会下面，又成立了很多 Oteam，每个 Oteam 对应一个技术（也就是我们比喻中的“工头”）。
TKE Oteam，就是诸多 Oteam 中的一个，非常重要的一个。
在总办定调“云原生才算完成上云”之后，汤道生也诚恳地跟大家说：“上 TKE 有什么困难，请拿到 Oteam 例会来讨论，我们一定服务好大家，找到两全其美的技术方案！”
私下里，汤道生又告诉腾讯云的同学：只要兄弟团队遇到自研上云相关的技术问题，一定要百分百给出解答，要像服务外部客户爸爸一样服务腾讯兄弟团队。
就这样，汤道生的诚恳，感染了所有腾讯云的同事，腾讯云的同事们又把这种诚恳传递到了他们对接的业务线的基层团队中。
一点一点，一天一天，虽然没什么轰轰烈烈的投票，但大多数腾讯人都默默站在了“彻底上云”的一侧，阻力的声音越来越少。
“云原生”的天平，也渐渐倾斜了。
腾讯大大小小几百个业务，就这样开始了轰轰烈烈的云原生改造。
（六）在机枪上装刺刀
腾讯云容器产品中心的负责人邹辉内心冰火两重天。
一边是集团用百万雄师下江南的气势推进各个业务冲上 TKE；另一边，邹辉不想让任何人觉得自己团队的兄弟们是躺在政策下面吃红利的人。
他们要用技术证明 TKE 就是最棒的选择。
没有之一。
可是，各个业务定制的“刺刀”，到底能不能插在 TKE这挺机枪上呢？
“肯定没问题！”
抢过话头的人，是于广游 ，TKE 的负责人，说到容器的核心技术 K8S（Kubernetes），他的眼神里闪烁着教徒一般的光芒。
TKE 不是人们想象中“坚固而不可改造”的平台。我了解 K8S 的技术，它就像是一个核心操作系统，兼容性非常强。无论什么定制化需求，一定有办法做成“插件”形式，插在我们的容器平台上。我对 K8S 一统江湖坚信不疑！
于广游说。
第一个找来的是腾讯游戏。
游戏，其实是腾讯所有业务里软件结构最特殊的一个。为什么呢？因为像电商、社交这些互联网业务，它们的系统可以拆分成标准的“微服务”模块，分别塞进容器里。
而游戏业务，比如《王者荣耀》和《和平精英》，后台服务模块比较重，很难拆分成比较小的微服务模块。
另一方面，游戏服务的镜像一般比较大，有的甚至达到十多GB。这么大的镜像，在部署的时候，如果都从集中的仓库下载，“仓库大门”就会成为比较大的瓶颈。
邹辉他们和腾讯游戏的老师傅在 Oteam 会议上讨论了无数次，决定搞一套“镜像分发系统”，一个容器启动之后，会从相邻的容器来拉取系统镜像，而不是都访问同一个中心点。这样就能大幅提高容器的使用效率。
游戏这边刚解决了一两个问题，那边微信又找过来。
微信自研的容器调度平台叫 YARD，但是这套系统和 TKE 有很大的区别。一个显著区别就是：比如当年为了保证稳定服务，每个容器对应的 IP 是固定的。随着历史沿革，“固定 IP”也就保留了下来。
简单来说就是，一个容器关闭之后，必须原地复活才能继续提供服务，否则就会引发错误。
但是，在 K8S 的哲学里，这却是“不当操作”。一个容器关闭之后，应该随便找个什么地方复活，这样才能实现灵活调度。
两边老师傅切磋了好几个来回，最终微信团队决定做出改变，向 K8S 的主流技术靠拢。
他们研发了一个插件，让容器绑定了一个弹性地址，这样，既不损害微信的历史设计架构，又能实现容器异地重启。
于广游告诉我，在解决这些问题的时候，他的心里其实一直在“滴血”。
作为 K8S 的原教旨主义者，他感觉每一个插件都在让这个轻盈的技术变得沉重。“在机枪上装刺刀”并不是他心目中云原生该有的样子。。。
有时候，夜里回家路上，自己一个人郁闷，他甚至萌发出“这些人是不是在故意搞我”的疑问。
但是，跟业务团队开过几十场会以后，他渐渐改变了想法。
业务侧的老师傅并不是有意为难。因为技术的生长就像生命的进化，在历史特定阶段，为了给用户提供最好的服务，不得已必须把技术设计成那样。而随着产品继续演进，这些旧架构就成为产品的一部分，很难推翻重来了。
技术最终还是要为人服务的。慢慢地，我也成长了。我仍然坚信 K8S 技术是未来，但一个技术成熟的标注，不恰恰是它能够兼容更多的旧架构吗？
于广游感慨。
当然，上面举的例子，只是九牛一毛，比如 TKE 团队还和游戏团队一起，做了适合 Windows 的容器；和微信团队做了多地三园区的高可用容器调度架构等等，细节繁复，这里不一一介绍。
其实，从另外的角度看，这些细微繁琐的技术点，正是腾讯这群人在20多年里服务十亿用户积攒下来的宝贵经验。
在腾讯内部，这些技术还有一个共同的名字，叫“海量之道”。
把各个业务的细微模块一点点塞进 TKE 的过程，正是把腾讯“海量之道”搬上云的过程，也是把腾讯这二十年的“传家宝”搬上云的过程。
不知道你有没有想到一个问题。
你我前两年都一直在用微信，但微信底层悄悄更换技术时，我们好像没有任何感觉啊。
借用张志东的话，海量服务之道的核心就是“碰到不可抗力的时候，还能用技术保证用户的体验最小程度受损”。
微信基础架构的同事 Edsel 告诉我，为了实现用户无感，他们把微信迁移到 TKE 的过程可以用“事无巨细”来形容。
我们做了详细的预案。每一步迁移都有监控系统在关注，如果指标出发某个逻辑，就会判定迁移失败，就能回退到旧的 YARD 系统，而整个迁移过程哪怕失败了，微信的用户也不会有任何感觉。
他说。
你还记得我们之前要“花开两朵，各表一枝”吗？现在轮到了另一枝。
正如贝多芬的《命运交响曲》，最不朽的音符恰恰迸发自命运向你挥动重拳的那一刻。
2020年的春天，就这样降临了。
（七）2020年的春天
就在 CVM 团队和微信团队紧张地盯着星星海服务器的春节档口，疫情已经来势汹汹，越来越多的公司通知员工暂缓返回岗位，远程办公。
随之而来的，就是在线会议的用户指数级飙升。
当时的腾讯会议，总共只有几十个人，团队原本的计划是慢慢来，一点点发展市场，做大做强。
然鹅，疫情来了，容不得你慢慢来了。。。
从过年开始，腾讯会议在线人数一天翻一番，原本为5万并发设计的系统架构，眼看已经扛到了10万、20万、40万并发，还一直在上涨。
最先扛不住的肯定是 IaaS 层的计算力资源。
这件事情在几天内就惊动了总办，批示各团队协作在最短时间内扩容。
可是，程序上批准了，技术上能实现吗？
粗略估算，在一天之内就要加几十万核 CPU 资源，目测只有 CVM 的虚拟机可以做到。
于是，腾讯历史上从未发生过的奇迹开始上演：腾讯云上所有的剩余资源全部被唤醒，统一做成支持腾讯会议的虚拟机型号，偌大的腾讯，带宽资源和计算力资源被双双用满了。
即便这样，计算力还是有缺口。
慌忙中，运管部门看到了库房里还有刚刚退役的几千台旧机器，这时也管不了那么多，旧机器总比没机器好。赶紧又拉回机房重新上线，接入腾讯云。
就这样，巨大的底层计算力像无尽的弹夹，填进了腾讯云的枪膛，如火舌一般奔涌而出。
工人这一层总算勉强撑住，接下来，考验的就是工头了。
腾讯会议使用到的核心模组就是“音视频实时通信组件”，负责高效传递会议各方的图像和声音。
这个组件在腾讯里名叫 TRTC（Tencent Real-Time Communication），他的负责人是薛笛。
薛笛早在手机QQ刚推出不久，就开始研发语音通信功能了，算算这已经是多少年的“老革命”了。
可是，老革命也遇到新问题。。。
这么疯狂增长的用户潮，TRTC 也没见过啊。很快，架构就出现了瓶颈，无法继续放大。薛笛赶紧带队杀向代码的战场，紧急升级架构。
“当时的感觉，就像站在洪峰中抗洪。”他回忆。
可即便是这样，TRTC 开发团队的人数还是有限的，眼看工期就要延误。。。
就在这时，腾讯各个技术团队的负责人听到腾讯会议爆了，全都主动请缨，想要给予技术支持。
史诗级的画面出现了：
已经赶回深圳的人，就在办公室吃住开发；仍然在老家的，就远程贡献代码。
擅长做分布式的就做分布式，擅长做负载均衡的就做负载均衡，擅长流量调度的就做流量调度。
所有人都毫无保留地把毕生经验和珍藏代码奉献出来。
这个瞬间，被大家吐槽了十几年的“独立庄园”不见了，出现在眼前的人只有一个身份——“腾讯人”。
升级后的 TRTC 代码被紧急部署在腾讯云的100万颗核心上，在腾讯云遍及全国的网络专线中纵横脉冲。
虽然很多模块是临时加增的，来不及仔细整理，但腾讯会议却没有给腾讯技术人丢脸，它彪悍地撑起了数亿人在网上的图像和声音互动，进而撑起了千万家公司跨越大江南北的会议沟通。
在各自冰封的城市中，人们通过电流看到同事们熟悉的脸，听到同事熟悉的声音，一切也显得并没那么糟糕了。
由此，社会生产得以一点点复苏。
尘埃稍稍落定，从硝烟中走出来的腾讯人相视一笑。虽然彼此无言，但每个人都确凿无疑地感受到，有些东西永远地被改变了。
仿佛空气中弥漫起新鲜的氧气，再也没人怀疑“开源协同”和“自研上云”的意义，曾经无比坚固的“庄园围墙”就这样如冰雪消逝，再无人怀恋。
其实，这世界上哪里有围墙，所有的围墙不过是在人心里罢了。
腾讯会议，就这样阴差阳错地成为了腾讯第一个诞生在云上的应用。它用自己核弹般的爆炸证明了云计算的狂暴力量。
由此，自研上云吹响了总攻的号角——最难啃的骨头，数据库、大数据平台、AI平台等等都纷纷开始了摧枯拉朽的云上迁徙。
（八）命运棋盘上的一颗钉子
如果从自研上云正式启动的2018年底开始算，2021年底应该是汤道生的“三年之约”到期之时。
他的承诺实现了。
站在命运之河的对岸回头看，汤道生却惊出一身冷汗。
过去三年，互联网行业环境已经发生了天翻地覆的变化——业务受阻、用户饱和、监管趋严、估值下降，过去的那片草原一夜之间寒霜降临，“动物们”悉数进入严冬。
如果“自研上云”不是此刻完成，而是此刻才启动，难以想象寒冬中的腾讯将付出比现在多几倍沉重的代价。
由此观之，“自研上云”的过程，仿佛历史的机会之门微微张开了窄缝，腾讯刚刚狂奔而过，回头望，大门已经紧闭。
腾讯众将逃过了命运的绞杀，正如一头角马冲过鳄鱼环伺的马拉河，回望血色的河水。
“确实很庆幸，当年做了这个选择。”汤道生感慨。
“自研上云成功之后，你们有没有搞一个庆祝会？”我问汤道生。
“好像没有诶，我们就这样每两周一次总办会议，每次都复盘、微调，就这样过去了。。。”
汤道生的回答很腾讯。
在这家公司的历史上，你最难找到的就是“轰轰烈烈”。翻开历史，这群人似乎总是在问题还没坏到不可收拾的时候，就聚在一起研究解法；而在波涛平复后，他们又马上恢复到平凡的节奏里。
他们小心翼翼地不让自己陷入“步兵趟雷、万岁冲锋”的境地。
这样的“无趣人生”，属于普通的腾讯员工们，也属于总办的这些“老男孩”们。
虽然从外表观看，企鹅还是企鹅，并无任何异样；但如果你剖开它的躯体，内部已经移髓换血：
腾讯游戏技术运营部负责人刘栖铜告诉我，过去一到逢年过节或者宣传节点，腾讯游戏就要提前一个月申请购买服务器，扩充资源；重大节点过去一个月，才能慢慢把服务器撤下来。
而现在，云上扩缩容只需要几个小时——明天要扩容，今天在腾讯云上点几下按钮就OK。
腾讯会议的技术负责人陈健生告诉我，在2022年新的一波疫情来临时，腾讯会议已经承载了千万级并发，这个数量已经远超2020年的量级。但这次，整个团队心情平静，完全不会有上次的惊慌。
微信技术架构部负责人 Stephen Liu 还记得，当年北京下了一场大雪，人们纷纷在朋友圈晒图就把朋友圈的存储系统给打挂了；如今存储系统跑在腾讯云上，也不会再出现容量不足的情况。
“运维起来就像自动驾驶。”他说。
微信视频号后台开发工程师 Bok 告诉我，过去使用云下系统，一次更新发布至少要一个半小时，但是上云之后，直接销毁旧容器，拉起新容器，全过程只用35分钟就能完成。
2022年，微信视频号异军突起。巨大的放量面前，直播、短视频却没有遇到瓶颈，也为腾讯云的技术做了最好的证明。
虽然腾讯云交出的答卷很圆满，但邱跃鹏仍然觉得不够。
“腾讯内部的业务大多都是互联网业务，而腾讯云对外服务的有很多都是实体行业。怎么把服务互联网的经验拿出来服务他们，是我们一直要思考的。”邱跃鹏说。
为了让这些经验适应更多行业，王慧星的眼睛必须穿透服务器，进入最底层的板卡、芯片和电流。
从虚拟化的角度说，现在我们已经做到把虚拟化交给专用的芯片来做，虚拟化损耗已经降低到0%。
从计算密度的角度说，现在很多人工智能服务器的耗能很高，如果能有办法抑制GPU芯片的空转，那么大型数据中心就还能把能耗降低一大截；
从芯片指令集的角度说，其实云计算日常只用到了所有指令集里的一部分，同样是计算“1+1”，普通指令集也许需要2000次运算，但经过优化的指令集，也许只需要1000次运算。这样就能一下子把能耗砍掉50%。
从云上开发的角度说，我们还可以提供更多云上的开发工具，让大家不用写代码，拖拖拽拽就能开发出下一个“腾讯会议”。这样，技术就不再是创意的绊脚石，任何人都有机会在云上做出国民级的应用。
他说。
他关心的，其实还是云计算的根本命题——效率。而云计算的效率，怎么关心都不过分。
我们不妨把目光重新投向那片草原，那个兵分两路的腾讯。
那些留在寒冬中“动物”们，只有不断提高计算效率，才能得到更多“养料”，从而更好地服务消费者，在越来越惨烈的生存大逃杀中走到最后；
而带队远征的腾讯云，也必须依靠最高的计算效率，才能翻越“玻璃幕墙”，可以在更广阔的世界里提供“牧草”，支持国计民生和无数有梦想的创业企业。
2022年，汤道生仍然像从前一样冲在一线。不是见客户，就是在见客户的路上。而这次，面对用户的诘问——“你们腾讯产品是不是跑在腾讯云上”，他的答案是：是！
至此，汤道生的第三次远征跳出了“玻璃幕墙”，在9年的念念不忘后，终究听见回响。
“动物”和“牧草”的比喻，贯穿了这篇文章。其实，我一直没有明确回答一个问题：腾讯为什么不老老实实做“动物”，而是心心念念要做“牧草”？
因为我想把这个问题留给腾讯的创始人马化腾亲自回答。
在接受《故事硬核》采访时，马化腾曾经说过一段话：
如果一个非洲大草原，你是一群动物，你没有了，人家还会换一批。但如果没有草原、没有雨露，没有生态中的一环的话，那就是不行的。所以要到这个程度，才是我们的价值。
由此可证，命运如棋局，任何一种动物，都只是棋盘上的棋子，随时可以被吃掉，被牺牲，被清除；而当你成为草原和雨露，你便不再是棋子，而是命运的棋盘上钉下的一颗钉子。
腾讯云，就是那颗钉子。
（九）星星们
汤道生也有被刺痛的瞬间。
不是腾讯云丢了大订单时，也不是自研上云遇到阻力时。而是在乐问上看到基层同事对云发出特别“狠”的批评时。
批评当然没问题，但是汤道生敏感地意识到，当人们开始用“狠话”的时候，一定是沟通出了问题。
每逢这时，他就更加努力地去疏通沟通渠道，解开误会。他于是定了规矩，“内网上的吐槽，腾讯云必须在一小时内给出回复和解答方案”。
“后来，乐问上有夸你们的帖子吗？”我问。
“乐问上好像不夸人的。”汤道生笑。
但确凿无疑的是，对腾讯云尖锐的批评减少了。
即便有批评，评论区也会有其他团队自发上去解释，帮忙澄清真相。每当看到这样的评论，汤道生就会心底涌过一道暖流，这比什么都开心。
因为这是他心中腾讯该有的样子。
在和我聊天的时候，卢山经常会把2018年口误说成“98年”。
1998年，也许有的读者还没出生，但那一年，却是卢山从中科大计算机毕业的年份。
如果遥想当年，大学毕业的卢山也和如今的年轻人一样，对未来充满憧憬，热切地想要发光，也对人生的种种锋利有些许怯场。
1998年，也是腾讯成立的年份，那时的马化腾还在勤勤恳恳扮妹子，吸引QQ最初的100个用户，并不知晓几年后自己会差点卖掉烧钱烫手的腾讯，更不知道工商注册时唯一可用的“腾讯”二字有机会在中国互联网的历史上留下浓重的一笔。
1998年，也恰好是汤道生从斯坦福大学硕士毕业一周年，每天用英语跟美国同事研究数据库技术的他，不曾想到自己将要回国，辗转参与到云计算的伟大历史进程中。
但是，岁月奔流。
2022，卢山终于打破了腾讯的“庄园藩篱”，硬是把开源协同写进了企鹅的基因，把“技术沙漠”的帽子抛进了大海中央；
2022，喜爱幻想的汤道生也完成了华丽的转型，把手中的萌萌哒的QQ安放在时代的河流中，抽刀挥旗，带领腾讯众将找到新的丰美草原；
2022，张志东没有回来，但腾讯 CTO 的椅子却不再是那首“等待续句的诗”，“技术委员会”的新铭牌在阳光下星点闪烁。腾讯的技术理想，将由这些穿过时光荆棘的人共同守卫。
2022，腾讯“自研上云”轰轰烈烈的“迁徙之歌”也度过了高潮部分。大草原上奋蹄扬起的烟尘背后，“马拉河”里的鳄鱼也慢慢潜入水下，等待下一次咬断猎物喉咙的时机。
草原的黄昏下，生命的舞剧经久不息地上演，其中具体的面孔也许终会被人遗忘，但背后对于现状的不甘和改变的勇气，却是和草原一样永恒的存在。
2013年的“WE 大会”上，说出“我们很怕”的马化腾还分享了一个小故事：
在腾讯上市之前，他偶然和同事聊起来，发现很多人也和自己一样喜欢天文。于是感慨，现在不仅没有时间观测星空，光污染还特别严重。
说着说着，他们开始幻想，有朝一日，能不能在远处安装一个望远镜，然后通过信号连接，在家里的电脑或手机上就能观测天文。
当时大家觉得这就是天方夜谭，谈资罢了。
然而，几年过去，有位同事真的跑来，说自己在云南买了一个民居，在里面专门搭了天文台，代码远程控制，画面自动传回。
马化腾很有感触。他的结论是：现实残酷，偶尔会怕，但有些火花无论如何不能磨灭。因为热情恰是人们坚持的动力。
人总有无奈。马化腾喜欢星星，刘炽平喜欢火箭，汤道生喜欢哆啦A梦——但可能很长时间内，腾讯没办法造火箭，更造不出时光机。
但把“腾讯云”作为这个阶段自己人生命题的答案之一，也未尝不可。
毕竟，在神降临前的日子，凡人的双脚被埋在土地中，也许究其一生都要在沟壑纵横的棋盘上和残酷的命运作战。
可是，每当凉夜降临，你抬头看，星星一定会在那等你。
它们如彼闪耀，它们如彼宽容。
再自我介绍一下吧。我叫史中，是一个倾心故事的科技记者。我的日常是和各路大神聊天。如果想和我做朋友，可以搜索微信：shizhongmax。也可以关注微信公众号浅黑科技：qianheikeji
