我遇到一群靠“造梦”改变世界的人_风闻

　　文 " alt=“500” />

　　故事的开头，是2013年那个风雨交加的夜晚。

　　窗外打着雷，屋里亮着灯。会议室里，头发蓬乱胡子拉碴的宅男们列坐两旁。如果不是有人电脑上粘着几只企鹅贴纸，估计你很难辨认出他们是腾讯的工程师。

　　气氛多少有点火药味，老司机们像辩论赛一样分成了两拨。

　　一拨人怀里揣着三个字母：Xen，另一拨人手里攥着另外三个字母：KVM。

　　这是要给什么新产品选名字吗？当然不是，技术宅选名字什么的都很随性的，绝不会打起来。比这厉害得多，他们是要给一个即将诞生的新产品选择“技术灵魂”。

　　啥新产品，值得这帮老司机大动干戈呢？

　　中哥不卖关子了，当时的情况是酱的：

　　2013年，腾讯做出了一个重磅决定，把自己旗下的腾讯开放平台改组为腾讯云，正式对外提供云计算服务。而会议室里这群老司机，就是在为腾讯云底层的“虚拟化架构”进行技术选型。

　　啥是“虚拟化架构”，你可能还不了解；但“腾讯云”这三个字在日后掀起了多少波澜，吃瓜群众有目共睹。

　　站在今天回望， 这场会议的结论曾拨动了鹅厂的一颗命运转轮。

　　（一）其实，我是一个“造梦师”

　　要想故事看得好，一波科普少不了。

　　在搞明白虚拟化技术的工作原理之前，中哥决不允许你往下看故事。别紧张，科普很快的，一点儿都不疼。

　　你看，这是啥：

　　这是一栋大厦。这是一栋充满魔力的“计算力大厦”。

　　腾讯把无数服务器堆积起来，建造了这座计算力大厦，起名为腾讯云。

　　然后他们的操作是把这幢大厦隔成一间间屋子租给有需要的人。（就是把计算力分割成小块租给企业。）

　　很快就来生意了。

　　有阔气的老板想租600平米，有刚毕业的年轻人想租15平米。于是，腾讯云就得按照人家的需要，打好隔断，交给他们。

　　没过两天，老板觉得用不到这么大的房子，想把600平米换成200平米；可年轻人突然事业爆发，要把15平米的房子换成2000平米。于是，腾讯云就要重新为他们打隔断，交付合适的“面积”。

　　腾讯云上的租户成千上万，难道要真的有一个“装修队”，每天手忙脚乱地打隔断吗？

　　并不是。

　　其实他们采用了一种更高级的技术——用代码做成一个个“梦境”，只需要修改参数就可以实时调节这个“梦境”的面积，从15平米，调到2000平米，就是一分钟的事儿。

　　而且，两个“梦”之间就像两个平行宇宙，既不透光也不透声，一切信息都无法相互交流，比隔断更安全，既干净又卫生。

　　这个营造梦境的技术，就是“虚拟化技术”。

　　中哥说得这么玄幻，其实是为了你方便理解。现实世界中虚拟化技术，就是在物理机上通过虚拟化技术创造出来的一个个相互隔离的“虚拟机”。让跑在虚拟机里面的操作系统感觉不到任何异常，而且可以像金箍棒一样随大随小。给你看个图就明白了：

　　如果拿一种职业作比较，虚拟化工程师非常像《盗梦空间》里的造梦师，不仅要把“梦”造得真实，还要让“梦”稳定运行——这是一个属于疯子或者天才的职业。

　　好，科普完毕。

　　现在你应该知道了吧，这个风雨交加的夜晚，屋子里坐的其实都是一群大内高手。正好他们的对决尚未分出胜负，你来帮忙评评理。

　　支持 Xen 的同学是大多数。Xen 有点像虚拟化界的“中坚派”，最主流。当时腾讯内部有很多地方也在使用 Xen。可是 Xen 也有缺点：它虽然是开源的，但代码过于复杂，工程师们很难100%把控它。有点像小时候家里的闹钟，你拆了就可能装不回来。。。

　　支持 KVM 的同学是少数。KVM 有点像虚拟化界的“少壮派”，它也是开源的，但代码简单清晰，有点像乐高积木，技术宅们可以随心拼拆，但它究竟能不能扛起云计算的底层架构，没有人验证过。

　　“中坚派”咄咄逼人：去饭馆吃饭还要挑人多的那家呢。先走一步的友商亚马逊 AWS 和阿里云都选择用 Xen 而不是 KVM 做虚拟化技术，难道是拍脑袋决定的吗？KVM 毕竟太新了，我们凭什么去踩坑啊？

　　“少壮派”据理力争：如果用复杂的 Xen，我们就不能100%驾驭它。技术最怕有漏洞，万一哪天发现了 Xen 有漏洞，我们又修不了，影响到上面的用户怎么办？

　　“中坚派”发出灵魂一问：担心 Xen 有漏洞，KVM 就没事了吗？

　　“少壮派”一拍胸脯放出豪言：如果我们能研发出一套“热升级技术”呢？

　　空气突然安静。

　　啥是热升级技术？就是能在系统一边运行的时候，一边升级的骚操作。就像老司机一边开车还能一边修车那样。如果真的能做出来热升级，那就相当于《终结者》里的自修复机器人，再多伤口也能愈合，妈妈再也不用担心我死翘翘了。

　　几秒沉默之后，领导发话：吹牛没用，代码说话。给你们两个月时间，要是你们真的能研发出来 KVM 的热升级，那我就同意让 KVM 做腾讯云的虚拟化平台。

　　散会！

　　少壮派同学们拿到令牌，前一秒还击掌庆祝，后一秒才意识到时间紧迫压力山大，赶紧滚回去撸代码。这时他们才恨自己没有三头六臂——人手这么少，先找几个志同道合的大牛来才是主要的。

　　王佳就是这个时候加入腾讯云的。

王佳

　　王佳是 KVM 的坚定支持者，听说腾讯云正在求贤若渴地寻找 KVM 大牛，满心欢喜地加入。哪成想一进腾讯云连气都没喘匀，就被同事们揪进了漩涡中心——分秒必争地开始研究 KVM 热升级技术。

　　精诚所至，金石为开。“少壮派”有如神助。一个月时间，王佳和同事们就把热升级模块的代码拍到了桌子上。

　　同事们惊为天人。

　　“现在回想起来，虽然有些代码实现并不优美，但我们却不小心成为了业界最早研发出 KVM 热升级的团队。”王佳笑。

　　枪杆子里面出政权，代码就是技术世界的马克沁机枪。

　　技术领导看着 KVM 团队六亲不认的眼神，终于同意从腾讯云上分出5%的机器，让他们用 KVM 来做虚拟化，之后根据表现再择机增加比例。

　　你可能觉得，5%也太抠门了吧。。。

　　别忘了，腾讯云的总体量很大，哪怕5%所对应的绝对数量也已经很惊人了。而且腾讯云是当时腾讯的重要尝试，一万双眼睛在盯着。此时，给这个没人用过的技术选型投信任票，技术领导们背了多大的压力，可想而知。

　　2013年，腾讯云正式上线。中国云计算猝不及防地进入“战国时代”。而腾讯云因为身体里流淌着 KVM 的血液，成为云计算列强里的一个“另类”。

　　故事讲到这里，反派就准备登场了。把镜头拉远，在远处的黑暗中，敌人正在蹑足潜踪，准备扼住我们主角的小咽喉。

　　“老司机，带带我。。。”那天晚上，王佳结束了愉快的加班，回家打开音乐。手机还没来得及扔到桌子上，就开始疯狂震动。

　　“大家赶紧上线，我们的 KVM 虚拟机挂啦！！”

　　（二）生死热迁移

　　担心的事情，终于还是发生了。

　　而且要命的是，这个事故还发生在腾讯云第一波大客户——某大型视频网站——身上。

　　客户的“梦境”里包含N台虚拟机，每挂一台虚拟机，就相当于一部分“梦境”没了。幸好出问题的只是占比5%的 KVM 虚拟机，客户主体的“梦境”还在，业务没受太大影响，怒气值暂未爆表。

　　但留给中国队的时间不多了。。。

　　王佳他们灰头土脸没日没夜地检查了好几天。结果非常气人：虽然看上去很严重，但原因只是 KVM 开源版本里有一个隐秘的小错误，只要修改掉就可以了。

　　如果这个问题发生在 Xen 上，那难免要把腾讯云整个暂停，来一次停机升级。可在 KVM 上，你还记得之前搞出来的“热升级技术”么？

　　没错，终于派上用场了。

　　他们赶快对所有 KVM 虚拟机都进行了在线热升级。而云上的用户业务不仅没中断，而且几乎是没有感觉的。

　　接下来的剧情走向就很有意思了。

　　王佳心里凉了半截，本以为经过这次事件，KVM 技术在腾讯云里要被打入冷宫，没想到，由于 KVM 的热升级能力在众目睽睽之下经受住了考验，领导们做出了一个凶猛的决定：继续加大 KVM 虚拟机的比重。

　　就这样，KVM 在腾讯云里的比重加到了30%，稳定运行一段时间，又加到了60%，到了2014年底，KVM 就成为了腾讯云官方指定唯一白金钻石级底层虚拟化平台，虚拟化团队也全部转向 KVM 技术路线。

这是当时团队的合影

　　对于这些宅男老司机来说，看着自己从零呵护起来的技术路线支撑起整个腾讯云，比跟相恋多年的女友修成正果还开心。

　　此时，时间已经推进到了2015年，最愚钝的人，都发现了世界的变化。

　　北京杭州上海深圳的机场，巨幅的广告位被各家云计算大厂包揽一空。

　　这些一掷千金的广告背后，折射出云计算行业刺刀见红的竞争。各家云厂商也清楚，疗效比广告更重要，他们纷纷加大投入，打磨底层技术。

　　有一个细节，王佳后来才知道——就在那时，阿里云和 AWS 已经越来越感受到 Xen 的束手束脚，疼定思痛，成立了小分队，认真研究要把底层虚拟化技术从 Xen 切换到 KVM。

　　而由于两年前雨夜的那场“豪赌”，腾讯云幸运地最早拥抱了 KVM，在这一回合技术较量中占尽了先机。市场份额不会说谎，在诸多研究机构的报告中，那一年腾讯云的用户暴涨，开始奋起直追中国市场的领头羊阿里云。

　　真正让这群老司机感觉到鼓舞的，不是市场份额，而是聚光灯。彼时腾讯云成了国内 KVM 虚拟化技术的圣地，各路顶级英雄纷纷来投。

　　如今腾讯云虚拟化团队的负责人陈立东，就是在这个时候加入的。

陈立东

　　陈立东还记得，自己加入不久，腾讯云的总负责人汤道生就宣布，要在未来3年豪掷500亿，争夺中国云计算的权柄。

　　这时的腾讯云，已经不仅仅是一个“重要尝试”这么简单，就像一个弱冠年轻人，需要为整个家族的命运承担责任了。

　　“从那时起，虚拟化团队每天都是如履薄冰，一秒都不敢松懈。”陈立东回忆。

　　可问题还是来了，以一种妖娆的姿势来了。

　　2015年，陈立东他们在后台数据中突然发现了怪异现象：最近一些虚拟机好像故障率有点高。。。

　　在各家云计算混战正酣的时候，出了这个问题，无异于苏德交兵的时候，坦克突然掉链子。

　　正在他们努力定位问题的时候，商务同事开始在群里反馈：有用户说了，最近感觉腾讯云不如以前稳定了，要是不赶紧处理，他们可是要转投别人家了！

　　大家更紧张了。。。

　　问题找到了，果然不是软件问题，而是最近采购的部分内存有质量缺陷。

　　硬件是云计算的基础。就像组成一幢房子的砖石，非常重要。

　　内存厂家有错就认，挨打立正，同意把这批货全部更换。

　　可是，陈立东他们却犯愁了。如果换内存，虚拟机一定会被破坏。在那之前，得先把用户的虚拟机搬个家，可是搬家的时候，客户还得把机器关掉一段时间啊。

　　这可不是小事。当时腾讯云的客户有很多都是游戏厂商。你这给人家虚拟机停机再迁移，少说也得半小时。相应的他们就得给玩家停服半小时，这后面的损失算谁的？？

　　箭在弦上，陈立东他们必须火速研究出一种技术：热迁移。

　　顾名思义，热迁移就是一个搬家队，在系统不停机的情况下，把所有东西从一个虚拟机搬家到另一个虚拟机。打个比方，就像一个饭店，要一边炒着菜，一边从一个屋子搬到另一个屋子，还不能耽误给食客上菜的速度。这难度可想而知。。。

　　战场上已经吹响了冲锋号。这群老司机没有退路，就是死也得把这个“搬家技术”搞出来再死。

　　热迁移起码要解决两个问题：

　　1、迁移成功率；

　　2、服务可用性。

　　先说“迁移成功率”。

　　之前说过，虚拟机就像大厦里的隔间，有大也有小。

　　给一间小饭馆搬家比较容易，把屋里的东西装进一个箱子，搬到另一个屋子就行了。可是如果面对一间大饭店，各种东西琳琅满目，还有不少大件物品。

　　这时就需要一个很大的搬家队，而且搬得时候还有可能磕碰损坏。

　　陈立东他们遇到的就是你这个问题。如果虚拟机配置小，那么迁移起来就很容易成功；如果虚拟机配置大，就会有一定的概率迁移失败。

　　这怎么解？

　　他们的办法是：压缩！

　　还拿搬家打比方，这就像是搬家的时候，把家里的物品条理清晰地放进箱子里，让它们占用空间的方式最紧凑，这样就可以让箱子数量尽可能少，搬家时损坏的可能性也就更低了。

　　那段时间他们没日没夜，尝试了各种工程方案，生生把内存里的文件压缩后的大小降低到了安全线以内。随之，迁移失败率大大下降。

　　再说“服务可用性”。

　　刚才说过，迁移的过程中，这个虚拟机还是要正常运行的。上一秒还在这间屋子里炒菜，下一秒就要在新屋子里继续炒菜。

　　解决这个问题，就要求搬家的动作又快又稳。

　　但是，陈立东和同事们被生生卡在了这里。

　　由于 KVM 本身的设计问题，在热迁移处理某个特定逻辑的时候，同时只能交给一个 CPU 核心。这就好像饭店里的煤气灶，搬迁有危险性，必须由专业的师傅来搬。给一间小饭店搬家还可以，但是面对大饭店，煤气灶很多的时候，这个师傅就会手忙脚乱，宏观表现就是虚拟机在搬迁的时候性能“抖动”。

　　最开始，这群技术宅的思路就是“多找几个煤气师傅一起来搬”。可是弄来弄去，并发的细节怎么都搞不定。结论很沮丧——只能由一个师傅来搬。

　　眼看时间一点一点流逝，虚拟化团队的技术宅们心急如焚。

　　一天早晨，商务的同事在技术群里恨恨地发了一条消息：客户走了。

　　言下之意，是谁的责任，你们心里有数。

　　陈立东他们内疚极了。然而，他们每天仍然不断地被拉进各种客户群，面对像浪潮一样涌来的吐槽。虚拟化团队一口口呛水，拼命找出路。

　　那段时间，根本连觉都睡不着，做梦都在尝试技术方案。

　　陈立东回忆起来，仍然心绪难平。

　　说出来你可能不信，方案真的是做梦时候想出来的。

　　那天半夜，陈立东“垂死病中惊坐起”。冲到电脑边，开始记录他想到的方法。

　　这个方案其实并不复杂。你还记得吧，之前他们的思路一直是多找几个煤气师傅，现在的思路是：就让这一个师傅来搬，但是用多种技术限制他同一时刻的工作量，这样就起码不会出现手忙脚乱（进程卡满）的状况，从宏观上看，虚拟机的抖动反而大大下降了。

　　虽说这个技术方案不如之前的那么优美，但在当时却能堪大用——解决了大配置虚拟机平稳热迁移的问题。

　　技术方案出炉，接下来就一马平川。依靠热迁移技术，客户们被平滑地般到了健康的主机上，这批问题内存也第一时间被换掉了，客户们的吐槽也以依次平息，没人再提要离开了。

　　我们把镜头摇回这群技术宅，他们的打怪升级还在继续。

　　就像一个人买彩票，一辈子都中不了奖，但是一千万人一起买彩票，那就几乎每期都会有人中奖。随着腾讯云上的客户越来越多，原本发生概率非常非常低的问题，渐渐开始显露。

　　这让虚拟化团队的游戏难度陡然升为“变态模式”。

　　这不，2017年，新课题又来了。

　　事情还是出在老冤家——内存——身上。

　　如果把一台电脑比作人的话，内存就是人的短期记忆。你日常生活里做任何事，都要时刻查询短期记忆。电脑也是一样，所以内存经常被读写，读写的次数多了，就难免出现内存错误。

　　内存一错误，虚拟机就会宕机。虚拟机一宕机，客户就抄刀。

　　可是人类目前的科技水平就是这样，内存就是有一个极低的概率会错误。在这个前提下，有没有办法让虚拟机依然不宕机呢？

　　还真让他们找到了，解决的方案就在内存的好基友——CPU——里。

　　（三）深探 Intel

　　众所周知，CPU 是一个计算系统的大脑，掌握着生杀予夺的大权。

　　我们假设一个场景：

　　今天上午同事告诉你有一家新开的快餐店很好吃，出门左拐不远就到了。于是你把这个方位放在大脑的短期记忆（内存）里，决定午饭的时候去试试。

　　结果中午的时候，你刚出楼门，瞬间就给忘了同事说的是出门左拐还是右拐。此时你就发生了一个内存错误。

　　这个内存错误被迅速报告到你的大脑（CPU），这时你的大脑就懵逼了，你立刻站在原地。。。

　　刚才这个场景其实就模拟了内存错误时的情况。

　　一旦内存在运行过程中存储发生错误，就会立刻汇报给 CPU，这时 CPU 为了防止错误继续扩大，最稳妥的选择就是先尬住，这就是死机。

　　日常查看技术资料的时候，陈立东突然发现，其实 CPU 的制造商 Intel 也注意到了这个问题，并且研究出来一个解决方案。

　　这个方案就叫做 MCA Recovery。

　　这个方案用白话解释起来挺简单：之前 CPU 的逻辑是，无论遇到什么内存错误，都直接宕机。MCA Recovery 就是让 CPU 在遇到内存报错时先不要慌，抽根烟，对内存发生错误的严重性做一个判断，如果判断这个错误不会影响程序进程，就忽略掉这个错误，继续运行；如果严重，再死不迟。

　　“踏破铁鞋无觅处，得来全不费工夫！”陈立东正准备高兴，突然发现备注里写着一行小字，只有在4路和8路的服务器里，Intel 才支持这个功能。（4路服务器指的是在一台服务器里有4颗 CPU。）

　　然鹅，腾讯云的很多服务器都是2路的，感觉有被忽略到。

　　没有没关系，我拿钱砸到你有。

　　在2016年，腾讯云对 Intel 提交了定制芯片的订单，里面就明确了需求，要在2路服务器上加入 MCA Recovery 功能。

　　半年之后，虚拟化团队激动的心颤抖的手，终于拿到了定制 CPU。

　　放到测试环境里一试，结果感人：虚拟机还是想死就死，不给任何人留情面。。。

　　这群老司机愣在原地，为这个世界的不科学深深叹服。

　　仔细寻找问题才发现，仅仅 CPU 支持了 MCA Recovery 还不管用，还要服务器里的很多其他模块跟着调整，虚拟化平台也需要大量修改适配。

　　问题是，当时这些服务器都不是腾讯自己研发设计的，而是从供应商那里买的。所以他们赶紧提出需求，让供应商开发完整支持 MCA Recovery 的服务器。

　　然而，由于 MCA Recovery 是新技术，不同的服务器供应商“悟性”不同，有的支持得好，有的支持得屎。于是虚拟化团队还专门编写了一套测试软件，告诉硬件采购的同事：以后通过这套测试的机器才能进入采购名单，不通过的一律不要。

　　站在现在回望， 这件事也坚定了腾讯云自研服务器的决心。当然这是后话。

　　这张照片就是后来腾讯云自研的星星海服务器。

　　折腾了几个月，总算是服务器都支持 MCA Recovery 了，这群老司机又发现，MCA Recovery 还是有很小的概率会在不该死机的时候死机。所有的证据都表明，问题出在 Intel 芯片里面，需要了解芯片的内部处理机制才有机会进一步优化。

　　陈立东赶紧联系了 Intel 中国的技术人员，对方研究了一个礼拜，最后还是建议：“你们去一趟美国总部吧，跟芯片开发工程师直接聊聊。。。”

　　就这样，陈立东和同事又买了去美国的机票，跟 Intel 的工程师当面“对质”。

　　在 Intel 总部，美国的技术宅也很坦诚，把芯片的内部逻辑都展示给陈立东他们，开诚布公地一起研究。果然，在 Intel CPU 设计 MCA Recovery 的时候，确实存在一些有待改进的空间。这些问题很隐秘，一般很难触发，除非使用的机器足够多。不巧，腾讯云上的服务器就足够多。

中美两波工程师还抽空合了影。

　　可是在了解了芯片内部逻辑之后，陈立东也发现，这个问题修复起来并不容易。

　　最后，两拨工程师商量出一个方案：在 KVM 里把有可能触发异常的逻辑禁用 ，提升 MAC Recovery 的成功率。

　　你看，内存错误发生的概率本来就不大。可就是为了搞定这个概率极低的宕机问题，这群技术宅定制了服务器，又定制了 CPU，还去 Intel 美国总部杀了一遭，揪着芯片里几个特定的回路跟 Intel 工程师掰扯了一个底朝天，横跨东西半球，才终于让这个问题得以缓解。。。

　　就这样，腾讯云的稳定性指标，在小数点几位之后，又增加了那么一块。虽然很多粗心的用户甚至体感不到腾讯云每年稳定性的提升，但是陈立东他们却一刻不敢懈怠。

　　如今，这些代码所承载的腾讯云，已经不是可有可无的玩物，而是银行、制造、商品流转、衣食住行，是无数人的箪食瓢饮，是很多人的工作生计。每一行代码都在悄无声息地改变着这个社会的命运转轮。

　　在我们的故事里，“造梦师”们一步步把腾讯云建造成梦想中的样子，终于为自己迎来了荣耀时刻。

　　（四）吃自己的狗粮

　　2018年，腾讯集团做出了一个决定：吃自己的狗粮——腾讯内部所有业务，包括QQ、微信、游戏等等全部切换到腾讯云上。

　　这就是腾讯轰轰烈烈的“自研业务上云”运动。

　　你可能有点纳闷：咦，原来腾讯自己的业务都没有在腾讯云上啊。

　　你说得没错。对于腾讯来说，是先有的QQ、微信，再有的腾讯云。所以那些较早的大业务其实并没有使用腾讯云，这是历史原因造成的。

　　那么，这些业务之前使用什么作为底层计算力呢？使用的是物理机。

　　你还记得那个房子的比喻吗？使用物理机，相当于自己盖一座计算力的别墅，因为全是自家的，所以根本不用打隔断，不用虚拟化。

　　现在全集团上云，每个业务都得放弃自己的房子，进驻腾讯云大厦里的一个个隔间，这样既可以节省成本，又能依靠虚拟化技术“伸缩自如”的优势增强业务弹性。

　　你可能会想，毕竟是兄弟部门，让内部业务上腾讯云应该很简单吧。

　　呵呵你错了，亲兄弟才明算账呢。

　　由于业务部门是从别墅迁移到大厦的隔间里，自然会把现在和过去的体验作对比。虚拟化虚拟化，毕竟是虚拟的，肯定在某些地方比不上真实的物理机。

　　其中有一个最主要的地方，叫做“性能损耗”。

　　简单来说，在物理机里造出并维持虚拟机的梦境，是需要耗费一部分性能的。也就是说，在一台物理机上运行一台虚拟机，虚拟机的绝对性能是要低于物理机的。

　　假如虚拟机只有物理机性能的95%，我们就说它的虚拟化损耗是5%。至于此时此刻虚拟化损耗到底是多少，取决于跑在上面的应用是什么。

　　按理说，全员上云应该从比较小的业务开始。不过腾讯“艺高人胆大”。2018年第一个吃螃蟹的，就是最重磅的应用之一——微信。

　　为了判断性能损耗有多严重，微信先拿了一部分虚拟机做测试。结果证明，微信的很多功能恰恰是对虚拟机很不友好的。在这种情况下，虚拟机的性能只能达到同样物理机的70%，损耗达到了将近30%。也就是说原本100台物理机能搞定的事情，现在需要140台同等配置的虚拟机才能搞定。

　　微信的同事把测试结果的屏幕转到陈立东面前：请开始你的解释。

　　没啥好解释的。陈立东带着同学们回到办公室，重新来过。

　　团队专门派出两个最资深的老司机，就以微信为例，看看哪里还有能降低虚拟化损耗的地方。

　　山重水复疑无路，柳暗花明又一村。他们发现 KVM 在虚拟化损耗方面的优化空间还是很大的。只不过降低虚拟化损耗这件事，恨不得比外科手术还要精细，其中的技术细节太高深。

　　不过为了满足你的好奇心，这里中哥还是简单给你举个例子：

　　KVM 下面连接物理机，上面连接虚拟机，再上面是操作系统。操作系统对 CPU 的某些操作，在虚拟机里是无法执行的，需要由 KVM 跳出到物理机层面执行。这个跳出跳入的过程，就造成了损耗。

　　而降低这种损耗的一种方法，就是具体分析这些指令，看是否可以把很多需要跳出执行的指令归在一起执行，这样就避免了频繁的跳出跳入，从而让系统减少负担。就像你去超市之前先列一个清单，一趟就买齐，就会比频繁往来超市节省时间。

　　类似这种逻辑，团队发现了很多 KVM 的优化点，每做好一个优化就把微信的同事们拉过来测一次。果然，虚拟化损耗渐渐地从30%降到5%。

　　微信之后，很多应用都陆续来做上云测试，提出了各种问题。我们没白没黑集中搞了半年以后，突然有一天，发现大家都没什么意见了。那一刻我知道我们成了，别提多高兴了。

　　陈立东回忆。

　　于是，微信、QQ、王者荣耀、穿越火线等等你耳熟能详的腾讯应用，开始了正式的“上云大迁徙”。

　　腾讯轰轰烈烈的自研业务上云，其实只是一个缩影。把镜头拉远，是烟尘中的千军万马，几乎全中国的企业都在奋勇地跨越河流，从传统的 IT 架构跳向云计算的彼岸，成为更自信的数字中国的一部分。

　　正在读文章的你，当然也是这一切的见证者。

　　有一件事不得不提。这些年为了改进腾讯云的底层技术，虚拟化团队积累了很多硬核代码。他们陆续把这些改进都整理清晰，提交给了 KVM 开源社区。在过去的三年，腾讯云团队一直是 KVM 社区贡献榜的中国区第一名。

　　在 KVM 大会上演讲

　　仅仅在过去的2019年，腾讯提交了40个改进，其中Exitless Timers、Yield to IPI target、Per-VM cap to disable exits 等等都被认为是年度重大改进。腾讯云毫无疑问地成为了 KVM 社区的重要贡献力量。

　　之前中国人一直被开源社区诟病，认为我们总索取，不贡献。客观来说，我们确实有做得不好的地方。但我们希望用行动说话，为开源社区贡献真正硬核的好东西，慢慢改变开源社区对中国的偏见。

　　陈立东说。

　　（五）靠“做梦”改变世界

　　2019年底，KVM 已经成为所有主流云计算厂商的虚拟化方案。

　　同一时刻，在最新的行业报告中，腾讯云市场份额位居中国第二，和领头羊阿里云的差距进一步缩小。考虑到腾讯在阿里之后才进入云计算市场，这样的成绩值得赞叹。

　　不过老司机的步伐丝毫没有停止。

　　用了几年时间，基本搞定了 Intel CPU 的虚拟化优化之后，他们又马不停蹄地开始了 AMD CPU 的虚拟化优化，而基于更多种类 CPU 的虚拟化，也在他们的计划之列。

　　你还记得当年非常困扰他们的“热迁移”技术吗？（就是那个一边炒菜一遍移动煤气灶的技术。。。）当年他们采用了“妥协方案”，而这几年他们并没有停止思考，最近他们终于解决了全部技术难题，正在仔细地写新模块的代码。

　　陈立东告诉我，这个模块也会贡献给 KVM 社区，这之后，所有使用 KVM 的云计算产品，就将会自动具备强大的热迁移功能。

　　“把这些核心功能贡献出来，不是给竞争对手增加武器吗？”我问。

　　“虽然你说的也没错，不过我们不从这个角度想。KVM 正在成为这个世界云计算的基座，我们的贡献，是代表腾讯云为 KVM 社区做的。”陈立东说。

　　告别之后，我反复回想这句话。

　　我从这句话里读到了自信。而在漫长的岁月里，自信恐怕是最美的东西。但自信也像稀世的珍宝，只有跟世界死磕，满身伤疤之后仍然傲视群雄，你才会拥有它。

　　这群老司机虽然沉默寡言，虽然屡遭挫败，但好在从未想过停下脚步。他们把技术边界向前一点点移动，把我们的计算力基座一毫一厘地压实。

　　这么重要的任务交在这群老司机手上，我感到很靠谱。