全面上云是怎么一回事？
现在是互联网时代，云服务改变了我们的生活，也改变了整个IT行业。到底什么是云服务呢？我们简单打一个比方
村子里有100户人家，每家都要盖自己的房子。如果每一家都亲自去准备木材和砖瓦，亲自打地基、搭梁木、砌墙铺瓦，这就相当于传统的自主研发；如果大家都去请村里专业的木匠、砖瓦匠、油漆匠，指挥工匠完成各种基础工作，这就相当于利用了云服务的资源。
云服务在国内发展十分迅速，近些年来涌现出很多优秀的云服务平台，腾讯云就是其中之一。
尽管腾讯云在国内有大量客户在使用，腾讯内部却面临着一些历史遗留问题腾讯各个业务线在当初开发的时候往往都是自己造轮子，依赖着五花八门的底层框架和接口。时间久了，一是导致技术与主流技术体系脱节，二是也会影响开发效率。
为了解决这个问题，腾讯内部在2018年启动了自研上云战略，直至最近，腾讯宣布内部海量自研业务已实现全量上云，这也是国内最大的云原生实践。
从一个一线码农来说，为什么要上云？上云是公司的“政治任务”还是程序员真正的心之所向？腾讯光子欢乐游戏工作室的技术总监马同星向我们分享了他和团队的“上云”故事。
“原来的架构好好的，为什么要上云？”
作为休闲游戏的国民级代表，“欢乐斗地主”用户体量庞大2019年日活用户数千万，在线玩家数超百万，直到今天仍保有千万级别的日活。
懂业务的人知道，这么一个常青树级别的业务，背后一定有着稳定的技术架构和成熟的运营在支撑。
那么问题来了之前这套架构运作得好好的，为什么要上云呢？
马同星给的回答很简短，“因为云就在那里。”在他看来，“云”是行业必然，更是大势所趋，云让所有的技术从业者都不能视而不见。
如果用一些关键词来描述马同星，大致可以用这些来概括技术大佬、健谈、学习能力超强、乐意分享、拥抱开源……作为腾讯光子欢乐游戏的技术总监，欢乐系列游戏上云也正是由他发起并主导推动的项目。
值得一提的是，早在2019年初，马同星便做出了决定基于开源方案，对欢乐游戏原有的技术架构进行重构，并将整体业务迁移上云。
不用公司现成的那些服务去改造，而是自研服务，推动他做出这个决定的，是当时社区日益收到关注开源服务网格（service mesh）——Istio 1.1版本推出。要从成熟的架构一下子切到这种开源没多久、没有经过大规模落地的方案，团队里不少同学都是没底的。“风险太大了”、“掌控不了”、“业务的压力太大”，类似的担忧不绝于耳。
但马同星不这么认为，他觉得一定要做“难而正确的事情”。马同星下面讲述的这个“上云”故事，希望能给大家一些启发
“如果我们不做，三年后就会差的很远”
事实上，在上云前的两三年我们就在讨论重构这个事儿了。
大概2018年下半年，我们开始做服务发现、流量治理的一些预研，调研社区的各种方案并关注到Istio。到19年初，也就是春节前2月份的时候，我们开始做技术验证。当时刚发布的Istio 1.1，是它的第一个Enterprise Ready版本，业界还鲜有大规模应用，腾讯内部也还没有这样的服务。
我们团队一起看一些技术资料，就开始研究这个。一开始我以为，微服务架构和服务网格的治理，是“新瓶装旧酒”——我以为进程多、把每个功能变小就是微服务，后来发现真不是，它这里说的微服务治理是指系统调度治理的能力细致入微。
如何理解这个治理能力呢？我举个例子，你有100个服务在做不同的事，这时A服务要访问其中的30个，B服务又访问其他的20个，C服务访问其他的15个，这15个里面的某个又要访问A服务…你把它想象成100个人的合作就知道——交互是星罗棋布的，牵一发动全身。
而真正的微服务治理能力，不管你的服务划分多细、结构多复杂，这些服务调度、容灾容错扩缩的细节都不需要额外关注了。它的治理难度不会随着你的系统变庞大而变复杂，不需要付出显著的额外成本。
，它是把服务和治理能力重构、下沉到基础设施层、避免侵入业务架构去做流量治理和调度的方案。在我看来这个设计思路的先进性超过以往传统分布式架构非常多。
这个开源方案所代表的微服务治理架构，就是我说的要做的“正确的事情”。
我们初期主要目标其实并不是为了省成本，大家上云一开始就是奔着提高流量治理能力的目标去的。
我们从大的技术趋势和机会一点点推演，当时想要实现某些业务模块的自动服务发现，其实也有其他低成本的方式可以做，但如果对照这个服务网格乃至云原生整个社区的技术架构能力，那就差很远了。
比如，大扇出系统出一个故障，以前你得通过分析日志来看哪个环节出了问题，但对于云原生来讲，整个调用链路非常清楚，自动生成调用链路拓扑给你，很快就能看到出问题的根源节点，对整个研运效能都是质的提升。
我个人觉得这一定是大的方向，甚至是对云业务利润率的提升是很重要的。这些能力都是行业大的机会和趋势，如果我们不做，现在也可以运营的很好，但三年以后，你可能就差很远。
“对技术的掌控和认知，是消除恐惧和担忧的有力武器”
在启动这件事情的时候，团队里不少同事是犹豫的。
我们工作室的负责人非常重视并不遗余力的投入技术创新，工作室专门设有公共技术团队负责技术预研类的工作，还有各个业务项目组内的技术团队，如果要去做这样一个大的架构调整，除了老板的支持还需要所有核心骨干发自内心愿意去做这件事情，才能走得下去。在项目组的同学，他会更多地去考虑项目迭代以及对版本稳定性的要求，会下意识焦虑一下子切到我经验之外的一个技术方案，会不会出很多问题，在原有架构下小步快跑是不是也挺好？
当时其实花了很多时间和各个项目组的技术骨干们谈心为什么要基于开源来做，做这个对团队和个人的发展有什么好处，技术架构调整的风险和挑战如何由组织而不是个人承受。
有一些同事是很热衷技术的，给的响应比较积极。另一些倾向于保障业务优先的同事还是会犹豫，我就接着提议说，我们用小体量项目先来试点，就这样把团队的信心初步聚拢了起来。