传统行业转型的过程中，腾讯向来扮演的是数字化助手的角色，腾讯云作为帮助企业数字化转型的入口，也已经成为腾讯的“独角兽”业务。
然而伴随着云业务的增长，腾讯内部业务如何上云，对于外界来说一直是个秘密。近日，腾讯自研上云项目负责人周小军首次披露，腾讯如何把内部海量的自研业务搬上云端的故事。以下是他的分享内容：
大家好，我今天分享的核心内容有三个：
1、腾讯自研业务如何从私有云的模式搬迁到公有云;2、如何把这些大体量的业务搬到云端;3、如何拥抱云原生。
腾讯的业务量非常庞大，社交业务包括和空间的体量有近二十万台服务器，分布在全国三地。要把如此庞大体积的业务搬到云上，可以称之为“把大象搬到云端”。
今天我就分四个方面向大家介绍腾讯自研业务上云的故事。第一是腾讯业务为什么要上公有云，第二个是业务上云的价值，第三个是如何上云，第四个是以上云的案例分享业务上云的过程。
2018年以前，腾讯业务的烟囱模式
为什么要上云？
2018年以前，腾讯的业务线是类似烟囱一样的模式，每个业务事业群从逻辑层、数据层到后端的容器或虚机层，都是独立一套技术框架和技术体系。每个事业群之间的框架多数是不通用的，一个腾讯的员工从IEG转岗到事业群，发现他的开发框架可能都要重新熟悉。一个新人来到腾讯之后，面临那么多的服务框架，也不知道如何选择合适的框架着手。
甚至在腾讯的内部论坛上，经常有很多新人发帖问，我该选什么样的工具，我该选什么样的框架，这种情况就导致三种困惑。
第一个是很多工程师不断抱怨为什么腾讯内部有这么多名词，不同的工具、不同的框架、不同的平台、不同的数据库和不同的存储等等。
第二个是很多部门都开发和使用自己的一套东西，跟其他部门缺乏分享和协作。
第三个是开源文化氛围不强。很多部门的代码不开放，或者缺乏文档。我们知道成为一个优秀的组件，组件的文档、支持、社区都是非常重要的，没有这些支持的话，你很难把一个组件做到最优，但是在腾讯内部很多组件是缺少文档，支持力度不足，甚至出现很多无人维护的孤儿组件。
两大开放战略并行
基于以上问题，为了技术体系革新，930调整后，腾讯内部做了大变革，包括成立新的云事业群，公司内部成立“技术委员会”，启动“开源协同”和“自研业务上云”的两大战略方向。
首先，开源协同就是在腾讯内部，所有的开发团队代码都是开放的，腾讯内部有统一代码库，所有的团队及个人的代码都要在上面公开提交、公开发布。团队与团队协作更好，随时可以去创建个分支，或者提交更丰富的特性功能，形成公司内的开源代码文化，创建更好的工程师氛围。
其次是“自研业务上云”。基于公有云的研发模式，使用云上丰富的组件、丰富的服务，把内部的一些优秀的工具和组件上云，对外开放，在云上做服务。在客户的激励驱动下，不断迭代成为行业内的领先水平。
这是腾讯技术领域一个很大的变革。
那么，上云的价值是什么？
第一是业务价值，业务的研发效率更高，从0到1开发一个新产品短短一周就能完成，微服务框架、数据库、容器资源、持续集成、持续交付、统一配置中心等等，云上都有现成的服务，研发团队不需要到处拼装各种组件和工具，可以更专注业务研发。
第二是工程师价值，工程师可以使用到整个业界最标准化的服务，基于公有云的研发模式，能够离开封闭的开发环境和组件，同时工程师还可以输出非常优秀的组件到云上成为服务，这也是大多数工程师的梦想。
第三是客户价值，可以给行业输出非常多的公有云的经验。
截至2019年初，腾讯正式发布的对外开源项目将近70个，诸如腾讯云T stack、蓝鲸智云BlueKing CMDB、开源系列和TARS等，都是腾讯开源的典型案例。
业务上云的三个阶段
腾讯自研业务上云也并不是一蹴而就的，而是有三个阶段。
第一阶段是从2017年开始直播类业务的上云。直播业务上云模式是一整套直播业务从自研机房搬迁到公有云机房，在腾讯云上提供服务，完成国内和海外几十个节点的建设，服务于自研的直播业务和外部客户。上云时打通了内部的运营管理系统和监控系统，同时支持跨云的管理。
第二个阶段是沙箱云，这个阶段是在腾讯云上建立一个逻辑隔离的私有网络空间，利用腾讯云的IaaS服务，使用云的虚拟机、云的网络、云的机房来支撑自研业务的服务。不过这类模式只属于基础平台上云，并不是整体业务体系完整上云。
第三阶段，是在腾讯“930”变革之前， 2018年6月我们就已经开始拥抱公有云，启动自研的整个业务从私有云迁到公有云，这是把整个业务连根拔起搬迁到云上。
上云之前，2017年，我们所有用户还在私有云上，到了2018年年底，就已经把一成半的用户从华南区迁到广州云。到了2019年的6月，已经有三成的用户在云上，每6个用户就有2个是在云上。我们计划到2019年年底，实现华南、华东和华北三大区域的所有用户全部都迁到云上，实现完整的公有云上服务。
上云有哪些流程，如何规避风险？
在上云的过程中，我们可以直观的感知到，跟之前烟囱式的架构不同，上云后像IEG、PCG、G等事业群等，都将在公有云上运行各自的业务。业务会使用公有云的CLB、接入服务、服务框架，云PaaS服务，包括Redis、MySQL、Kafka、ES、CBS、COS等等，还有像K8S这些公有云上的原生服务。
为了实现这一点，我们做了一些改造，在每个区域的公有云和私有云机房之间拉了专线，实现了公有云私有网络到私有云机房的互通，保证业务能够来回迁移及访问内部服务能力。
根据业务体量不同，业务采用三种方式上云，有改造后上云，有边改造边上云，有先上云再改造。业务可以根据自己的人力资源和上云计划，选择对应的上云方式。
第一是测试，包括公有云上的网络、存储、虚拟机、核心服务，以及单机性能、服务吞吐性能、存储读写性能、业务模块性能等等都经过测试。通过测试之后，我们和云团队一起优化了服务性能，对业务也相应做了改造适配。
第二是业务上云方案，包括安全方案、容量评估、服务迁移方案和数据迁移方案等。
第三是业务迁移，迁移包括接入层、逻辑层、数据层及文件存储等的迁移。
第四是混合云共存，业务会逐渐灰度迁移到云上，比如在线用户从5%、10%、20%、30%到100%等，是一个灰度迁移过程。在灰度过程中可以及早发现各种问题，逐一解决，避免大规模上量时出现灾难性后果。这个过程中就存在公有云和私有云的混合部署模式，就要重点关注专线使用容量，做好专线在业务高峰期的预案，以及业务跨混合云访问的服务延迟，及时做好用户在不同云之间调度的策略和方法。
最后是业务监控。上了云之后使用立体化的监控体系，度量服务调用质量、用户访问质量和服务可用率等，譬如跟踪用户在私有云和公有云的访问延迟有没有变差，不能变坏，运营质量有没有跟原来保持一致，甚至变得更好。
从测试、方案、迁移、混合到监控，这是我们上云团队所实施的上云迁移整体流程。
根据腾讯自研业务上云，团队所积累的经验之上，我们抽象出完整的上云方案，也十分符合很多企业上云的实际情况，方案分五个阶段。
第一阶段：规划。规划中要对业务系统化的梳理，包括业务评估、容量评估、业务架构、组织体系。组织体系是指上云后组织架构和职能的变化，包括运维职责的变化：例如不再有中间件的运维人员，研发流程的变化;研发、测试和生产环境如何在混合云甚至多云中共存;资源预核算的变化;以前是购买机架和服务器，现在是先充值再按量计费;故障处理流程的变化等。技术体系的组织都要准备跟着公有云转变。
第二阶段是方案规划和设计。要做好详细的迁移方案，风险预案，回滚预案，混合云预案，多云预案等，譬如上云过程中数据迁移有问题，出现丢数据，我该如何解决等等。
第三阶段是验证。这个是非常核心的阶段，上云前，要有预测试、预验证的过程。可以把一些核心模块，譬如高并发，或延迟非常敏感的模块，在云上做好充分的压测，并跟云服务团队一起优化解决各种问题。
第四阶段是业务迁移。迁移就更复杂了，包括服务和数据怎么迁、怎么做好备份，迁移过程中对业务有没有影响，我们用云的通用迁移工具，还是我们自己开发的迁移工具。上云过程中，做好对灰度模块的观察，通过客户端服务质量，服务间调用延迟，全网拨测等监控指标观察业有没有问题。
第五阶段是持续运营。整个服务运营体系都变了，基础运维和公共运维团队变成由公有云的运维团队来支持。内部使用的开源监控工具，或者改造成支持公有云的资源监控，或者使用云上成熟的监控SaaS服务。CMDB要支持多云管理。运营流程也发生很大的变化，服务SLA要跟公有云服务商一起制定。
当然，上云的过程中，安全是不可或缺且关键的一环，腾讯是一个非常注重安全的公司，特别是用户数据安全。我们在上云安全这块做了很多安全方案。自研内部、企业内部我们有一整套自研的安全体系。上云后，我们结合云上的一些安全产品，以及原来自研的安全服务和安全策略，制定混合云的安全通用体系。
首先在公有云的大网里，我们会划出一个独立的私有网络VPC，业务分别去部署。之上有网络防护以及网络安全的产品服务。主机上有主机防护，漏洞扫描等。业务层有应用防护，运维有运维安全，云上有丰富的产品可以去使用。然后我们也打造了一些内部积累的安全方案，并回馈到云上。形成了公有云安全产品和自研安全产品两者相互匹配融合的上云案例解决方案。
事实上，整个公有云的安全策略和私有云是一样的，没有什么根本性的差别。
在上云过程中，也必然会遭遇到一些比较大的挑战，比如数据的迁移。在私有云到公有云的数据搬迁模式中，我们有四种模式给业务选择。
首先是私有组件数据迁移到公有云的模式。腾讯内部有很多自研的数据库，像的Grocery KV存储使用的是内部私有协议，云上没有对应服务。业务需要将数据从私有组件迁移到Redis。
我们采取冷迁移的方式，先将数据全备，然后把数据导到云上Redis集群，导完后开始做新增数据追加。怎么追加呢？我们用数据同步中心来实现。后面会有同步中心实现的架构。数据同步完之后，我们通知业务可以切割，留一个业务低峰期时间，比如晚上凌晨2点，花1分钟把数据路由服务从自研IDC切到公有云Redis集群上。
第二、三种模式可以统称为开源组件到公有云。我们内部有一些业务，在开源组件之上做二次开发，譬如基于单机Redis实现自研分布式Redis集群。这些基于自研或开源组件的数据迁移到公有云上对应的数据服务，可通过DTS迁移工具来实现。
这个非常简单，也是业界非常通用的做法，我们直接用云上的DTS来做自助迁移。这个工具甚至不需要运维操作，开发团队自己在DTS窗口上输入几个参数，点个搬迁按纽后就可以自助搬迁。搬迁完成后自助切换或自动切换。
第四种模式是私有组件直接上云。因为有一些组件云上没有，业务也没有资源将私有组件改造成云的标准服务，这个时候业务就将组件集群直接在云上部署一套，数据通过同步中心或主备备等方式搬迁到公有云上。
比如说我在深圳的自研有一台主两台备，那么我再把备3、备4放到广州云，数据同时同步到私有云的两个备和公有云的两个备机模式。所有的主备数据完全同步完成之后，我们再把公有云的备变成主，自研云的主变成备，就相当于是做了切换。
还有一点非常核心的就是云管平台。之前内部的配置系统、监控系统、CMDB等等，都是基于私有云的管理模式。业务上云之后，我们很多运营系统要改造成支持混合云，支持多云的管理模式。譬如业务模块会有50个实例在腾讯云上，30个实例在海外亚马逊云上，30个实例在内部私有云里，那么我们的CMDB必须要支持多云的资源管理。从图中可以看到，底下是我们的整个业务线，下面这些帐号体系、预核算、企业安全、监控等等其他的应用工具或平台，都要改造以适应混合云模式。就拿帐号体系来说，内部员工以公有云的帐号登录云官网来购买、使用和运营公有云上的资源。但内部如何把帐号所使用的资源成本核算到对应的业务，员工离职或转岗后资源怎么回收或转移，如何把帐号绑定给企业组织架构，云官网帐号登陆如何与内部OA鉴权等，都是必须要考虑和解决的问题。
如何把的所有用户搬上云？
前面讲了业务上云的思路和方法，上云是走了这样一个经历。上图就是一张全国地图，业务有三大区域的数据中心，有华北自研，2015年这里曾发生了一个很大的爆炸事件，当时我们还把天津的用户调回了华南和华东区域。上海有华东自研机房，深圳有华南自研机房，在香港还有一些海外的出口。三大区域各有三成多的在线用户。
根据用户分布情况，上云时，在华东、华南、华北三地，在腾讯云建设的云机房上，我们创建了业务的公有云网络，然后把业务从各地的自研机房往云上迁移。
上云中业务架构图分成了三大区域，分别是华北、华东、华南，而华南分成了广州云和深圳自研机房两大机房。目前是“三云一地”。每个区域都是完全独立的存储和业务逻辑服务。可以把华南的整个用户全部都调度到华北和华东区。业务随时将用户从不同的云区域和自研区域来回调度。
我们接着看下业务的MySQL数据搬迁案例，详细见上图，它有主—从的模式。我们没有通过IP和PORT来寻址，而是通过内部的DNS类名字服务来寻址。先分配业务一个实例的名称，然后通过DNS拿到这个实例的IP端口，再去访问具体的实例。从自研的IDC使用腾讯云DTS迁移工具，把数据导到云的MySQL。数据自动导入完成后，开发团队只需要在云上切换服务就可以完成数据实例的迁移。这种适合一些数据体量不大的业务数据迁移。
还有一种是主备备的模式，即在深圳自研有数据库服务器的主和备，在云机房新部署几台备机。通过主备同步的方式，把所有数据都同步到云机房。然后将云机房的某台备机切换成主机，将自研的主机降级为备机。这样就切换为云机房主备，自研机房备的模式。
还有更复杂的是数据同步中心。这种是适合业务量非常大，有全国多地分布的业务。服务模块写数据的时候，统一写到各地的接入代理，代理统一写一地，譬如深圳自研的写服务。
写服务的转发存储会将新增记录同时写到各地自研、各地的云机房，实现最终数据一致性。
用户就近读，比如华北的用户，就读华北云的这个数据存储集群，华南就读华南的数据存储存储。
通过同步中心的方式完成大规模数据的混合云同步。当要增加一个成都云区域，我们只需在当地好一套同步服务，增加路由服务规则，同步服务就会自动把数据同步到成都的云机房。
这种方式适合对延迟不敏感的业务，譬如社交业务的点赞、发表说说等。一般从深圳自研同步到上海和天津的时候延迟达到几十毫秒，延迟非常高，不适合金融行业等延时高敏感业务模式。
从2014年开始，每年春节腾讯都有春节红包活动，今年春节我们首次在公有云和私有云之间做了红包的两地混合。我们在广州云部署了与自研相同规模的红包服务模块，包括数据集群，在春节前演练及预热阶段，充分对广州云服务做了各种测试和验证，包括跨城专线延迟对业务的影响程度。
红包活动期间，用户在接入的时候根据用户的ID分片或用户来源，通过路由策略分流到广州云机房和深圳自研机房。春节期间，混合云扛住了整个红包活动的用户流量。验证了跨地域的混合云完全能支持亿级的业务大并发流量。当然我们也做了很多方案，比如万一公有云的红包模块没有扛住，我们怎么办？如果我们发现用户在云上有大量失败，我们就把用户在几分钟以内切回到深圳云，甚至把整个业务从云上切回本地，我们有信心去扛云机房的压力。
在上云过程中，研发自身也对业务进行了优化，积极拥抱变化，做了很多处服务的改造，以能够适应新一代的基础设施。
服务逻辑上，很多个业务直接使用云PaaS服务，如长消息、加群逻辑等用了云Redis存储服务。更多的服务迁移到TKE之上。
一些内存存储服务，譬如资料、关系链等数据存储层做了链接数、数据副本扩展、混合云单元分布等架构层级的优化改造。
上云前后，上云团队对业务质量非常关注，不断对比二个云之间的可用率、客户访问质量、服务间调用延迟等质量数据。上云前后， 经过各个架构层的优化，业务质量数据最终保持私有云和公有云一致，保证了用户访问体验。
上云不仅是为了上云，我们更多要拥抱业界开源生态。要用云上优秀成熟的产品和服务。在开发方法、业务交付、云原生服务等方面，业务上云前后已经是部分甚至全部拥抱云原生的体系。我们已经把TAPD研发管理工具、工蜂代码仓库，还有蓝盾、橘子CI、QCI、coding等集成为工具链，在云上打造了一个持续集成、持续部署的DevOps流水线闭环。
目前在云上的交付，业务每周都有几百次的交付是通过容器来完成的，从以前的包交付变成容器交付。
在微服务这块，像SF2、SPP、TAF等，我们内部不同业务已经使用了很多微服务框架，并计划在公司内迭代升级更优秀的微服务框架。
K8S平台上，我们用了腾讯的TKE引擎，这是一个跟K8S完全兼容的引擎。我几天前跟一个业界公司聊，他们在腾讯云、阿里云上买了K8S服务，自己内部也部署了K8S集群。他们的容器可以随时、同时交付到腾讯云、阿里云和他们本身的K8S集群，而不用做任何改动。通过容器交付，业务可以不用考虑环境依赖等问题，交付变得更敏捷和轻松。
我们基于TKE之上做了功能定制和优化。TKE有基于CPU负载等基础容量的弹性伸缩能力。在TKE优秀的伸缩能力之上，我们还做了功能叠加，包括业务画像，就是根据业务长期的趋势和业务突发活动，去做趋势预测和活动预测，通过算法来预估容量在什么时间窗会达到多少水位，以准备相应的容器资源来提前几小时扩容，应对突发流量。
上云团队、业务研发跟云的TKE团队合作，我们把业务特性跟TKE相融合，来做出一个特性更加丰富、满足业务场景的K8S应用功能。譬如是三地分布，特别是上云后又增加了自研和云的机房属性。原生K8S不支持跨地域的，因此我们做了跨地域的特性。
除此之外还有权限限制，业务对权限要求非常严格，是基于IP鉴权的。比如内部的业务模块访问MySQL时，要授权MySQL要给这些IP放行。容器是很难去做这种基于IP的权限管理，我们的容器都是用了固定IP，每个容器都有自己的IP，交付时注册到CMDB上，并完成鉴权等自动化交付流程。
内部的CI/CD，我们有很多的优秀工具，让业务自行去选择使用，开发团队喜欢什么样的工具，从镜像仓库、到CI、CD、CO都能保持业务自己的习惯。
还有包括管理体系、安全、审计、服务监控、日志、告警等功能特性，我们增加和优化了近百个特性，满足TKE与海量业务结合。
于是，我们总结了八类的TKE业务应用适配，从业务管理、网络、路由与服务发现、分批发布、权限控制、镜像仓库、网络存储到远程日志。
这是蓝盾支持云上DevOps的范例，能够实现计划、需求管理、设计、研发、构建、测试、部署、搭建、监控到运营等一整套工具闭环。
所以，从腾讯自研业务上云，再到一些合作伙伴的案例，对于上云的的趋势，我们总结了五点经验：
第一，彻底拥抱云原生，用云来满足业务快速迭代，资源弹性伸缩的需求。
第二，全面拥抱DevOps，研发效率更高效。
第三，内部的优秀工具上云，给云提供更好的服务。
第四，整个开发团队心态更加开放、更加开源，主动与开源社区协同，贡献更多的功能特性。
第五，公有云经受了海量流量的锤炼，我们在上云过程中，经历很多的经验教训，边上云边解决问题，边上云边优化，将整个公有云的基础设施和服务锤炼成更加成熟。