云中发生了什么？
现在是互联网时代，云服务改变了我们的生活，也改变了整个IT行业。云服务到底是什么？我们来做一个简单的类比:
村里有100户人家，每家都要自己盖房子。如果每家都亲自准备木头和砖头，亲自打地基，搭起横梁和木头，砌起墙和瓦，这就相当于传统的自主研发；如果每个人都请村里的专业木匠、瓦工、油漆工来指导工匠完成各种基础工作，就相当于使用了云服务的资源。
云服务在中国发展迅速。近年来，涌现出许多优秀的云服务平台，腾讯云就是其中之一。
虽然腾讯云在国内有大量客户使用，但它面临着一些历史遗留的问题:腾讯各业务线刚发展起来的时候，往往是自己造轮子，依靠各种底层框架和接口。时间长了，一是技术与主流技术体系脱节，二是也会影响开发效率。
为了解决这个问题，腾讯在2018年启动了云自研战略。直到最近，腾讯宣布内部海量自研业务实现了全量上云，这也是国内最大的云原生实践。
从一个一线码农，为什么要上云？云是公司的“政治任务”还是程序员的真实愿望？腾讯光子趣游戏工作室技术总监马同星和我们分享了他和他的团队“上云”的故事。
“原来的建筑很好。为什么要上云？”
作为休闲游戏的国民代表，《开心斗地主》的用户规模庞大:2019年日活用户数千万，同时在线人数超过百万，直到今天仍有数千万的日活。
了解业务的人都知道，这样一个常青的业务，必须有稳定的技术架构和成熟的运营作为支撑。
那么问题来了:这个架构之前运行的很好，为什么要上云呢？
马同星简短回答，“因为云在那里。”在他看来，“云”是行业的必然趋势，云让所有技术从业者无法视而不见。
如果用一些关键词来形容马同星，大致可以概括为:技术大王、健谈、超强的学习能力、乐于分享、拥抱开源……作为腾讯光子快乐游戏的技术总监，也是他发起并主导的项目上了快乐系列游戏的云。
值得一提的是，早在2019年初，马同星就做出了决定:基于开源方案，重构开心游戏原有的技术架构，将整个业务迁移到云端。
没有改造公司现成的服务，而是开发了自己的服务，促使他做出了这个决定。当时，社区越来越关注开源服务网格-ISTIO 1.1版的推出。团队中很多同学在从成熟架构切换到这种实施时间不长，也没有大规模实施的开源方案时，都有些不知所措。“风险太大”、“控制太多”、“业务压力太大”都是类似的担忧。
但马同星不这么认为。他觉得自己必须做“困难而正确的事情”。马童星在下面讲述“上云”的故事，希望能给你一些启发:
“如果我们不这样做，三年后就会远远落后”
事实上，在云兴起的两三年前，我们就在谈论重构。
大约在2018年下半年，我们开始做一些关于服务发现和流量管理的预先研究，调查社区的各种方案并因此关注Istio。到19年初，也就是春节前的2月份，我们开始做技术验证。当时刚刚发布的Istio 1.1就是它的第一个版本Enterprise Ready。当时行业内很少有大规模的应用，腾讯内部也没有这样的服务。
我们团队一起看了一些技术资料，开始研究这个。一开始我以为微服务架构和服务网格的治理是“新瓶装旧酒”——我以为微服务是一个流程很多，把每个功能变小的过程，后来发现真的不是。这里的微服务治理是指系统调度治理的细致能力。
如何理解这种治理能力？我给你举个例子。你有100个服务在做不同的事情。这时，服务A会访问其中的30个，服务B会访问另外的20个，服务C会访问另外的15个，这15个中有一个会访问服务A……就把它想象成100个人的合作吧——交互点点滴滴，牵一发而动全身。
真正的微服务治理能力，不管你的服务划分有多细，结构有多复杂，都不需要额外关注服务调度、容灾和扩展等细节。它的治理难度不会随着你的系统变大而变得复杂，也不需要付出很大的额外成本。
简而言之，它是一个重建服务和治理能力的解决方案，下沉到基础设施层，避免入侵业务架构来管理和调度流量。在我看来，这种设计思想比传统的分布式架构要先进得多。
这个开源方案所代表的微服务治理架构是我说要做的“正确的事情”。
事实上，我们最初的主要目标不是节约成本。大家一开始上云都是以提升流量管理能力为目标的。
我们从大的技术趋势和机会中一点一点地推断出来。当时我们想实现一些业务模块的自动服务发现。事实上，有其他低成本的方法可以做到这一点，但如果我们比较这个服务网格，甚至是云原生社区的技术架构能力，那就差远了。
例如，当一个大的扇出系统出现故障时，你以前必须分析日志才能看到哪个环节出了问题，但对于云原生来说，整个调用链路非常清晰。自动为你生成调用链路拓扑，很快就能看到问题的根节点，对整个研究和运行效率都是一个质的提升。
个人认为这一定是大方向，甚至对提高云业务的利润率非常重要。这些能力是行业的大机会和大趋势。如果我们不去做它们，我们现在可以运营的很好，但是三年后，你可能会远远落后。
“对技术的控制和认知是消除恐惧和担忧的有力武器”
启动这个东西的时候，团队里很多同事都很犹豫。
我们工作室的负责人非常重视并不遗余力地投入技术创新。工作室专门配备了负责技术预研的公共技术团队，以及各个业务项目组的技术团队。要做这么大的结构调整，除了老板的支持，还需要所有核心骨干发自内心的愿意去做，才能走下去。项目组的同学会更多的考虑项目的迭代和对版本稳定性的要求，会下意识的焦虑:一下子切入一个我经验之外的技术方案会不会有很多问题？在原有架构下小步快跑也很好吗？
其实我花了很多时间和各个项目组的技术骨干交流:为什么要基于开源来做？这样做对团队和个人的发展有什么好处？技术结构调整的风险和挑战如何由组织而非个人承担？
有些同事对技术非常热衷，他们的反应也比较积极。其他倾向于业务优先的同事会有所犹豫，于是我接着建议先尝试小规模的项目，从而初步聚集团队的信心。
第二件事是统一团队的目标。当时我们团队做了多轮分享和研究，甚至翻译了K8S的一本书，最终统一了目标:基于一整套开源技术栈的重构，包括从底层协议，到开源远程过程调用系统GRPC，到服务网格和K8S服务布局。原因也很简单:这套东西已经逐渐成为行业事实上的标准。如果我们不跟上，就会慢慢落后，不可能做出自己的一套来打败别人。
到2019年6月，试点项目验证结果评估:方案可行。这个时候团队的氛围和当初完全不一样了，变得信心满满，因为我们已经彻底了解了这项技术。对技术的掌握和认知是消除恐惧和担忧最有力的武器。等到大规模重构云的时候，大家就都熟悉了。
五万人游乐场“干坤大挪移”
验证这是第一个节点。到了第二个节点，我们要做的就是把业务平稳过渡到云原生环境。
但是这个上云并不意味着把我们的服务搬到自研云就叫上云。假设我们只是把IDC的生产环境搬到腾讯云的自研云，但仍然使用原来的架构。在我看来，其意义大打折扣。
公司大力推进云上自研，营造非常好的技术变革氛围，2019年6月左右，TKE团队也开始做mesh，也和我们成立了联合支持团队。在此基础上，我们开始对原有业务逐一进行重组，放到云原生环境中。
重新配置的技术难度没那么高，但是业务的平滑迁移是个问题。当时我们的业务一部分在云原生架构上，另一部分在云下。在这种异构架构下，确保平稳的迁移过程和对用户没有感知对企业来说是一个巨大的挑战。
因为游戏不同于一般的互联网服务，比如你买了东西，失败了就要重新尝试，但是游戏是实时互动的。掉线回来的游戏过程到了新的情况，其他玩家不会陪你重复错过的游戏过程。这就好比你要把几十万人从一个游乐园搬到另一个地方，却无法让他们感受到。
其实在上云的过程中，业务方也有疑虑。2021年春节，我们和手机QQ合作了一个运营活动。当时大量用户瞬间涌入，所以出现了超负荷，也就是大量用户排队。
当时操作的学生并没有提前通知RD团队这个活动。当时我们的一些业务还在云下，不具备动态弹性计算的能力，所以出现了这个故障。后面我们和运营同学一起总结一下这其中的原因。他们不太理解，说我们的系统可以支持一两百万在线。50万人怎么做不到？
当时我给他们举了一个例子来说明:一个写字楼可以支持5000人上班，但是每天早上电梯排队都很长。我们的情况和这个一样。一个是容量，一个是登录并发负载。容量可以很大，但不代表我们的短期处理能力很强。目前这部分业务不具备动态弹性计算的能力，所以会这样。现在我们在做一个大的技术重建，叫做云原生重建。它的一个核心能力就是解决这个问题:如果只有一个人走，这个电梯会变得很小，节省资源；如果突然来了五万人，它会自动变宽，让那五万人快点过去。
讲了这个操作，同学们就明白了，后续协作起来就方便多了。所以这件事之后，我得出结论，技术经理应该给团队三个信心:
一是有充分的基础验证，证明方向可靠；
第二，重大重组必然充满技术风险。既然选择去做，就要对团队做出全身心投入。作为技术经理，首先要承担风险责任。出了问题不要一味指责团队，因为什么都不做是风险最低的；
第三，以非技术人员能够理解的方式，扩大技术的影响力以与其他上下游团队协作，获得他人的信任和支持，推动技术建设。
记得2020年11月17日上午11点，我们第一次在线升级跨集群网格。升级后，部分跨集群路由信息丢失，导致某重要游戏功能大量失效。RD学员全力做好失败业务的恢复，项目组的策划运作，学员公告，用户补偿方案，联系客服安抚玩家。大家都在无条件支持，没有人抱怨。在RD学生恢复服务并完成球员数据补偿后，他们彻底调查了TKE队问题的根本原因。终于在下午17: 44，项目组的一大群后台同学知道服务已经恢复，再次放到客户端功能入口，不仅没有任何指责和质疑。相反，我们GM关心每一个人。“很多后台同学都在忙着处理问题，还没吃午饭。很辛苦。”工作室对技术创新的期待、包容和耐心是大前提，稳健运营的项目是重构进化可以落地的场景，更可贵的是不同专业背景的快乐朋友的协同支持。这些都是快乐云原创改造顺利落地的重要保障。
早在2020年6月，Joy的所有游戏对游戏服务已经部署在云原生环境，复杂强态实时交互游戏对游戏服务也首次具备了弹性计算能力。据我们所知，这应该是游戏领域第一支达到这个水平的队伍。
更高的目标:从巅峰60%到全职70%
其实这三个阶段我们都有一个大原则，包括技术验证，包括核心服务的迁移，最后是存量服务的迁移:不赶时间，不算小时，只看一件事:云的原生弹性计算能力是否得到了充分的发挥。这个标准是在繁忙时至少可以达到60%的负载。
其实任何游戏产品都是有生命周期的。云下的时候，大家都在堆机器完成峰值负载，但是过了峰值期，那些机器的实际利用率很低。我们计算过，很多项目高峰期的负载率不到30%，在没有弹性计算的框架下，低峰期的负载率更低。
如果你的业务上了云，利用率和云下是一样的，我觉得是很差的结果。我们不能把云作为公司布置的被动任务来完成。仅仅完成基本的云量指数是远远不够的。
所以我们强调不要拼云的速度和核的数量，要拼云的质量。我们必须按照云原有的能力来重构业务系统，等我们上去了，它就有了真正的弹性计算、服务调度、流量管理能力。
老业务重构，异构系统废除后，相信整体资源利用率会更上一层楼。我的期望是未来能做到70%+全时利用率，不仅高峰期70%，低峰期70%。消峰填谷，将空闲置的计算资源用于线下计算业务，是长期目标。
如果真的做到了，我们使用的核小时数可能会下降到现在的1/3甚至更低。当然，这并不是一件容易的事情。
我还特别感动一件事:去年夏天，我们项目组组织团建之旅去江西武功山，徒步爬了好几个小时。最后人真的站到了云上，云在脚下五六十米或者100米。大家都很兴奋，开始拍照发给朋友。
“我们是真正‘在云上’的团队。”很多人在朋友圈写了这个。这时候我才知道，我们的“对的事”真的是对的。
开心团建照片
人们常说，船掉头很困难。腾讯体量庞大，光靠自己研究云的难度不言而喻。但正如上面的故事所讲述的，在腾讯有很多人马立克同行，他们凭借自己的技术经验和理念，进行了勇敢的尝试，最终完成了不可能完成的任务，让腾讯的很多老项目在云端焕发了青春。
IT人大部分时间都在从事琐碎的业务工作。赶上这样一个改造云的庞大工程，既是挑战也是机遇。当他们共同努力，通过不断的学习和尝试，克服各种困难，最终到达云端，相信每个参与者的个人能力都会有很大的提升。
这就是腾讯的技术人，这就是腾讯的精神。希望在这样一群可爱的技术人的支持下，腾讯云越走越远，越飞越高。
