传统行业转型的过程中，腾讯向来扮演的是数字化助手的角色，腾讯云作为帮助企业数字化转型的入口，也已经成为腾讯的“独角兽”业务。
然而伴随着云业务的增长，腾讯内部业务如何上云，对于外界来说一直是个秘密。近日，腾讯自研上云项目负责人周小军首次披露，腾讯如何把内部海量的自研业务搬上云端的故事。以下是他的分享内容。
如何把 QQ 的所有用户搬上云？
前面讲了业务上云的思路和方法，QQ 上云是走了这样一个经历。下图就是一张全国地图， QQ 业务有三大区域的数据中心，有华北自研，2015 年这里曾发生了一个很大的爆炸事件，当时我们还把天津的用户调回了华南和华东区域。上海有华东自研机房，深圳有华南自研机房，在香港还有一些海外的出口。三大区域各有三成多的 QQ 在线用户。
根据用户分布情况，QQ 上云时，在华东、华南、华北三地，在腾讯云建设的云机房上，我们创建了业务的公有云网络，然后把 QQ 业务从各地的自研机房往云上迁移。
QQ 上云中业务架构图分成了三大区域，分别是华北、华东、华南，而华南分成了广州云和深圳自研机房两大机房。目前是“三云一地”。每个区域都是完全独立的存储和业务逻辑服务。可以把华南的整个用户全部都调度到华北和华东区。业务随时将用户从不同的云区域和自研区域来回调度。
- MySQL 数据搬迁
我们接着看下业务的 MySQL 数据搬迁案例，详细见下图，它有主—从的模式。我们没有通过 IP 和 PORT 来寻址，而是通过内部的 DNS 类名字服务来寻址。先分配业务一个实例的名称，然后通过 DNS 拿到这个实例的 IP 端口，再去访问具体的实例。从自研的 IDC 使用腾讯云 DTS 迁移工具，把数据导到云的 MySQL。数据自动导入完成后，开发团队只需要在云上切换服务就可以完成数据实例的迁移。这种适合一些数据体量不大的业务数据迁移。
还有一种是主—备的模式，即在深圳自研有数据库服务器的主和备，在云机房新部署几台备机。通过主备同步的方式，把所有数据都同步到云机房。然后将云机房的某台备机切换成主机，将自研的主机降级为备机。这样就切换为云机房主备，自研机房备的模式。
- 数据同步中心
还有更复杂的是数据同步中心。这种是适合业务量非常大，有全国多地分布的业务。服务模块写数据的时候，统一写到各地的接入代理，代理统一写一地，譬如深圳自研的写服务。
- 写服务的转发存储会将新增记录同时写到各地自研、各地的云机房，实现最终数据一致性。
- 用户就近读，比如华北的用户，就读华北云的这个数据存储集群，华南就读华南的数据存储存储。
- 通过同步中心的方式完成大规模数据的混合云同步。当要增加一个成都云区域，我们只需在当地好一套同步服务，增加路由服务规则，同步服务就会自动把数据同步到成都的云机房。
这种方式适合对延迟不敏感的业务，譬如社交业务的点赞、发表说说等。一般从深圳自研同步到上海和天津的时候延迟达到几十毫秒，延迟非常高，不适合金融行业等延时高敏感业务模式。
- 混合云红包的架构
从 2014 年开始，每年春节腾讯都有春节红包活动，今年春节我们首次在公有云和私有云之间做了红包的两地混合。我们在广州云部署了与自研相同规模的红包服务模块，包括数据集群，在春节前演练及预热阶段，充分对广州云服务做了各种测试和验证，包括跨城专线延迟对业务的影响程度。
红包活动期间，用户在接入的时候根据用户的 ID 分片或用户来源，通过路由策略分流到广州云机房和深圳自研机房。春节期间，混合云扛住了整个红包活动的用户流量。验证了跨地域的混合云完全能支持亿级的业务大并发流量。当然我们也做了很多方案，比如万一公有云的红包模块没有扛住，我们怎么办？如果我们发现用户在云上有大量失败，我们就把用户在几分钟以内切回到深圳云，甚至把整个业务从云上切回本地，我们有信心去扛云机房的压力。
在上云过程中，QQ 研发自身也对业务进行了优化，积极拥抱变化，做了很多处服务的改造，以能够适应新一代的基础设施。
服务逻辑上，很多个业务直接使用云 PaaS 服务，如长消息、加群逻辑等用了云 Redis 存储服务。更多的服务迁移到 TKE 之上，一些内存存储服务，譬如资料、关系链等数据存储层做了链接数、数据副本扩展、混合云单元分布等架构层级的优化改造。
上云前后，上云团队对业务质量非常关注，不断对比二个云之间的可用率、客户访问质量、服务间调用延迟等质量数据。上云前后， 经过各个架构层的优化，业务质量数据最终保持私有云和公有云一致，保证了用户访问体验。
- 云原生
上云不仅是为了上云，我们更多要拥抱业界开源生态。要用云上优秀成熟的产品和服务。在开发方法、业务交付、云原生服务等方面，业务上云前后已经是部分甚至全部拥抱云原生的体系。我们已经把 TAPD 研发管理工具、工蜂代码仓库，还有蓝盾、橘子 CI、QCI、coding 等集成为工具链，在云上打造了一个持续集成、持续部署的 DevOps 流水线闭环。
目前在云上的交付，业务每周都有几百次的交付是通过容器来完成的，从以前的包交付变成容器交付。
在微服务这块，像 SF2、SPP、TAF 等，我们内部不同业务已经使用了很多微服务框架，并计划在公司内迭代升级更优秀的微服务框架。
- TKE 引擎
K8S 平台上，我们用了腾讯的 TKE 引擎，这是一个跟 K8S 完全兼容的引擎。我几天前跟一个业界公司聊，他们在腾讯云、阿里云上买了 K8S 服务，自己内部也部署了 K8S 集群。他们的容器可以随时、同时交付到腾讯云、阿里云和他们本身的 K8S 集群，而不用做任何改动。通过容器交付，业务可以不用考虑环境依赖等问题，交付变得更敏捷和轻松。
我们基于 TKE 之上做了功能定制和优化。TKE 有基于 CPU 负载等基础容量的弹性伸缩能力。在 TKE 优秀的伸缩能力之上，我们还做了功能叠加，包括业务画像，就是根据业务长期的趋势和业务突发活动，去做趋势预测和活动预测，通过算法来预估容量在什么时间窗会达到多少水位，以准备相应的容器资源来提前几小时扩容，应对突发流量。
上云团队、业务研发跟云的 TKE 团队合作，我们把业务特性跟 TKE 相融合，来做出一个特性更加丰富、满足业务场景的 K8S 应用功能。譬如 QQ 是三地分布，特别是上云后又增加了自研和云的机房属性。原生 K8S 不支持跨地域的，因此我们做了跨地域的特性。
除此之外还有权限限制，业务对权限要求非常严格，是基于 IP 鉴权的。比如内部的业务模块访问 MySQL 时，要授权 MySQL 要给这些 IP 放行。容器是很难去做这种基于 IP 的权限管理，我们的容器都是用了固定 IP，每个容器都有自己的 IP，交付时注册到 CMDB 上，并完成鉴权等自动化交付流程。
内部的 CI/CD，我们有很多的优秀工具，让业务自行去选择使用，开发团队喜欢什么样的工具，从镜像仓库、到 CI、CD、CO 都能保持业务自己的习惯。还有包括管理体系、安全、审计、服务监控、日志、告警等功能特性，我们增加和优化了近百个特性，满足 TKE 与海量业务结合。
于是，我们总结了八类的 TKE 业务应用适配，从业务管理、网络、路由与服务发现、分批发布、权限控制、镜像仓库、网络存储到远程日志。
- 蓝盾支持云上 DevOps 的范例
这是蓝盾支持云上 DevOps 的范例，能够实现计划、需求管理、设计、研发、构建、测试、部署、搭建、监控到运营等一整套工具闭环。
所以，从腾讯自研业务上云，再到一些合作伙伴的案例，对于上云的的趋势，我们总结了五点经验：
- 第一，彻底拥抱云原生，用云来满足业务快速迭代，资源弹性伸缩的需求。
- 第二，全面拥抱 DevOps，研发效率更高效。
- 第三，内部的优秀工具上云，给云提供更好的服务。
- 第四，整个开发团队心态更加开放、更加开源，主动与开源社区协同，贡献更多的功能特性。
- 第五，公有云经受了 QQ 海量流量的锤炼，我们在上云过程中，经历很多的经验教训，边上云边解决问题，边上云边优化，将整个公有云的基础设施和服务锤炼成更加成熟。
作者介绍：
周小军，腾讯云资深运维专家。加入腾讯以来先后负责腾讯社交事业群数据存储运维、接入架构运维、社交业务运维等运营工作。拥有十几年互联网 IT 运维经验，精通互联网海量业务规模技术架构、云计算基础架构、自动化运营系统、监控系统等领域。带领团队维护亚洲最大的数据库集群，以及春节 QQ 红包、天津大调度等海量规模业务的运营保障项目。所负责社交业务在线用户 3 亿 ，月活 8 亿，20 多万台服务器集群，全国三地三活数据中心。
本文转载自公众号云加社区（ID：QcloudCommunity）。
原文链接：
评论