浅友们大家好~我是史中，我的日常生活是开撩五湖四海的科技大牛，我会尝试各种姿势，把他们的无边脑洞和温情故事讲给你听。如果你特别想听到谁的故事，不妨加微信（微信号：shizhongmax）告诉我。
窗外打着雷，屋里亮着灯。会议室里，头发蓬乱胡子拉碴的宅男们列坐两旁。如果不是有人电脑上粘着几只企鹅贴纸，估计你很难辨认出他们是腾讯的工程师。气氛多少有点火药味，老司机们像辩论赛一样分成了两拨。一拨人怀里揣着三个字母：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%所对应的绝对数量也已经很惊人了。而且腾讯云是当时腾讯的重要尝试，一万双眼睛在盯着。此时，给这个没人用过的技术选型投信任票，技术领导们背了多大的压力，可想而知。2013年，腾讯云正式上线。中国云计算猝不及防地进入“战国时代”。而腾讯云因为身体里流淌着 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年，陈立东他们在后台数据中突然发现了怪异现象：最近一些虚拟机好像故障率有点高。。。在各家云计算混战正酣的时候，出了这个问题，无异于苏德交兵的时候，坦克突然掉链子。正在他们努力定位问题的时候，商务同事开始在群里反馈：有用户说了，最近感觉腾讯云不如以前稳定了，要是不赶紧处理，他们可是要转投别人家了！问题找到了，果然不是软件问题，而是最近采购的部分内存有质量缺陷。
硬件是云计算的基础。就像组成一幢房子的砖石，非常重要。内存厂家有错就认，挨打立正，同意把这批货全部更换。可是，陈立东他们却犯愁了。如果换内存，虚拟机一定会被破坏。在那之前，得先把用户的虚拟机搬个家，可是搬家的时候，客户还得把机器关掉一段时间啊。这可不是小事。当时腾讯云的客户有很多都是游戏厂商。你这给人家虚拟机停机再迁移，少说也得半小时。相应的他们就得给玩家停服半小时，这后面的损失算谁的？？箭在弦上，陈立东他们必须火速研究出一种技术：热迁移。顾名思义，热迁移就是一个搬家队，在系统不停机的情况下，把所有东西从一个虚拟机搬家到另一个虚拟机。打个比方，就像一个饭店，要一边炒着菜，一边从一个屋子搬到另一个屋子，还不能耽误给食客上菜的速度。这难度可想而知。。。战场上已经吹响了冲锋号。这群老司机没有退路，就是死也得把这个“搬家技术”搞出来再死。给一间小饭馆搬家比较容易，把屋里的东西装进一个箱子，搬到另一个屋子就行了。可是如果面对一间大饭店，各种东西琳琅满目，还有不少大件物品。这时就需要一个很大的搬家队，而且搬得时候还有可能磕碰损坏。陈立东他们遇到的就是你这个问题。如果虚拟机配置小，那么迁移起来就很容易成功；如果虚拟机配置大，就会有一定的概率迁移失败。还拿搬家打比方，这就像是搬家的时候，把家里的物品条理清晰地放进箱子里，让它们占用空间的方式最紧凑，这样就可以让箱子数量尽可能少，搬家时损坏的可能性也就更低了。那段时间他们没日没夜，尝试了各种工程方案，生生把内存里的文件压缩后的大小降低到了安全线以内。随之，迁移失败率大大下降。刚才说过，迁移的过程中，这个虚拟机还是要正常运行的。上一秒还在这间屋子里炒菜，下一秒就要在新屋子里继续炒菜。
由于 KVM 本身的设计问题，在热迁移处理某个特定逻辑的时候，同时只能交给一个 CPU 核心。这就好像饭店里的煤气灶，搬迁有危险性，必须由专业的师傅来搬。给一间小饭店搬家还可以，但是面对大饭店，煤气灶很多的时候，这个师傅就会手忙脚乱，宏观表现就是虚拟机在搬迁的时候性能“抖动”。最开始，这群技术宅的思路就是“多找几个煤气师傅一起来搬”。可是弄来弄去，并发的细节怎么都搞不定。结论很沮丧——只能由一个师傅来搬。眼看时间一点一点流逝，虚拟化团队的技术宅们心急如焚。一天早晨，商务的同事在技术群里恨恨地发了一条消息：客户走了。陈立东他们内疚极了。然而，他们每天仍然不断地被拉进各种客户群，面对像浪潮一样涌来的吐槽。虚拟化团队一口口呛水，拼命找出路。那段时间，根本连觉都睡不着，做梦都在尝试技术方案。
那天半夜，陈立东“垂死病中惊坐起”。冲到电脑边，开始记录他想到的方法。这个方案其实并不复杂。你还记得吧，之前他们的思路一直是多找几个煤气师傅，现在的思路是：就让这一个师傅来搬，但是用多种技术限制他同一时刻的工作量，这样就起码不会出现手忙脚乱（进程卡满）的状况，从宏观上看，虚拟机的抖动反而大大下降了。虽说这个技术方案不如之前的那么优美，但在当时却能堪大用——解决了大配置虚拟机平稳热迁移的问题。技术方案出炉，接下来就一马平川。依靠热迁移技术，客户们被平滑地般到了健康的主机上，这批问题内存也第一时间被换掉了，客户们的吐槽也以依次平息，没人再提要离开了。我们把镜头摇回这群技术宅，他们的打怪升级还在继续。就像一个人买彩票，一辈子都中不了奖，但是一千万人一起买彩票，那就几乎每期都会有人中奖。随着腾讯云上的客户越来越多，原本发生概率非常非常低的问题，渐渐开始显露。如果把一台电脑比作人的话，内存就是人的短期记忆。你日常生活里做任何事，都要时刻查询短期记忆。电脑也是一样，所以内存经常被读写，读写的次数多了，就难免出现内存错误。内存一错误，虚拟机就会宕机。虚拟机一宕机，客户就抄刀。可是人类目前的科技水平就是这样，内存就是有一个极低的概率会错误。在这个前提下，有没有办法让虚拟机依然不宕机呢？还真让他们找到了，解决的方案就在内存的好基友——CPU——里。众所周知，CPU 是一个计算系统的大脑，掌握着生杀予夺的大权。今天上午同事告诉你有一家新开的快餐店很好吃，出门左拐不远就到了。于是你把这个方位放在大脑的短期记忆（内存）里，决定午饭的时候去试试。结果中午的时候，你刚出楼门，瞬间就给忘了同事说的是出门左拐还是右拐。此时你就发生了一个内存错误。这个内存错误被迅速报告到你的大脑（CPU），这时你的大脑就懵逼了，你立刻站在原地。。。一旦内存在运行过程中存储发生错误，就会立刻汇报给 CPU，这时 CPU 为了防止错误继续扩大，最稳妥的选择就是先尬住，这就是死机。日常查看技术资料的时候，陈立东突然发现，其实 CPU 的制造商 Intel 也注意到了这个问题，并且研究出来一个解决方案。这个方案用白话解释起来挺简单：之前 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 社区贡献榜的中国区第一名。仅仅在过去的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 社区做的。”陈立东说。我从这句话里读到了自信。而在漫长的岁月里，自信恐怕是最美的东西。但自信也像稀世的珍宝，只有跟世界死磕，满身伤疤之后仍然傲视群雄，你才会拥有它。这群老司机虽然沉默寡言，虽然屡遭挫败，但好在从未想过停下脚步。他们把技术边界向前一点点移动，把我们的计算力基座一毫一厘地压实。注：本文头图以及文中“内存错误”科普用到的三张图修改自游戏《没有人知道的大冒险》，这是一款让人感动的游戏。它的作者同样是一位爱做梦，想要改变，并且不轻易动摇的程序员。我自愿为这个游戏做个广告，如果大家有能力的话，请去 Steam 多多支持啊。
再自我介绍一下吧。我叫史中，是一个倾心故事的科技记者。我的日常是和各路大神聊天。如果想和我做朋友，可以搜索微信：shizhongmax
转载文章，请加微信：woshimantoujie
既然是做梦