导语 | 近日，云+社区技术沙龙“高效智能运维”圆满落幕。本期沙龙围绕运维展开了一场技术盛宴，从AIOps、Serverless DevOps、蓝鲸PaaS平台、K8S等分享关于业务运维的技术实践干货，同时带来腾讯海量业务自研上云实践，推动传统运维向云运维转型。本文是黄宏东老师关于腾讯海量自研业务上云方案与实践及过程中的问题解决方案的内容分享。
本文主要包括以下几部分：
腾讯业务为什么要上云？
业务上云的价值有哪些？
上云过程中的心得体会
简述QQ上云案例
思考与总结
一、腾讯业务为什么要上云？
在腾讯做开发既是幸福也有烦恼。腾讯的业务线非常广泛，比如IEG做游戏，PCG做信息流，WXG做微信，每个BG都有自己的业务线。运维资源体系、研发体系，每个BG都会有自己定制化的方案和架构。虽然也有公线部门来做基础的解决方案，但每个业务都在快速成长，公线的支持就力不从心，对于个性化的需求，各个BG都有自己的实现方式。每个BG也都会有自己的支持体系，就像烟囱一样，导致各个系统都不相通，开发人员、测试人员的工具也不一样，导致跨部门合作也出现一些障碍。
平台与组件这么多，对一个技术人员来说，并不是一个好事情。第一，选择多但方案不通用；第二个，轮子在重复造，资源浪费。技术人员都容易患一个毛病，就是互相看不起，我看不起你的方案，你看不起我的方案，这样对我们的成长是非常不利。缺乏统一的规范，技术支持也不足，造了很多轮子之后，轮子越来越旧，有一些老的服务还在用老的轮子，这些轮子，平时都用得挺好，也没有什么问题，越来越没有人去关注它，当它出问题的时候，就很难解决。各部门间数据也不互通，代码封闭，跟业界缺乏交流。最重要的一点是我们没有技术图谱，在计算、框架、存储、大数据应用等领域的技术图谱。业务开发要选型组件，内部有什么样的可以选？它的功能是怎么样的？组件适合的业务场景？优缺点是怎么样的？我们很缺技术图谱。
腾讯公司在2018年9月30日做组织架构变革，业务线和技术线都做了变革。业务线做了BG整合。我们不仅连接人、连接数据服务，在数据内容和服务上面还对产业和互联网做了升级。另一条线是从技术上来进行调整，有两大口号，也是两大战略方向，第一是开源协同，第二是自研上云。
开源协同就是将我们的源代码进行开源，然后互相协同来做一个事情。我们基线是同一条，上面有不同的场景，业务线可以各自进行开发。腾讯有自己的云，并且在国内也是第一梯队，早期也有一小部分业务是在云上成长。自研上云成为主航向，同时我们也在对云社区以及云生态做出贡献。
二、业务上云的价值有哪些？
业务上云的价值主要从三大方面：对业务的价值，对工程师的价值，对客户的价值。
第一，业务的价值，其实是最重要的。上云后研发效率会高很多。举个例子，在国庆期间，互娱游戏做了一个小活动，用了很多云上组件，包括人脸识别、位置信息等，用了很短的时间，两三周就将它上线了。能够支持这么大体量、高可用的服务，云功不可没。还有丰富的公有云海外资源，游戏出海帮助很大。云与自研的环境是一致的，运维体系、研发架构相互兼容，研发、测试、运维成本大大降低。上云使用业界标准的云原生服务，这对工程师非常有诱惑。运营环境和云直接相通，开发、构建、测试、运维整个过程非常高效，一天做到好几次发版。工程师输出优秀的组件到云上，成为标准服务，让更多的人用，共建开源生态。
第二，工程师价值，上云使用业界标准的云原生服务，这对工程师非常有诱惑。运营环境和云直接相通，开发、构建、测试、运维整个过程非常高效，一天做到好几次发版。工程师输出优秀的组件到云上，成为标准服务，让更多的人用，共建开源生态。
第三，客户价值，为行业输出公有云迁移经验，更丰富的云服务和工具提供给客户。这一块我们也在沉淀，供给行业架构师做解决方案。
三、上云过程中的心得体会
上云过程中的心得，我总结了两点，第一，如何提升上云的效率？第二，如何降低迁移风险，包括质量和成本。
标准的三层的架构包括接入、逻辑、存储，存储有数据存储和文件存储。公有云和自研IDC之间专线打通，这样就不存在IP无法访问的问题。将云原生的组件用好，能够高效解决问题。有一些业务的改造成本比较高，先搬上云，再跟着业务需求改造使用云组件。
通过实践与跟行业架构师交流，形成上云五步曲，分为规划、设计、实施、验证、维护五大阶段。在信息收集和评估这一块我们会做大量的拆解工作，分析使用的服务、规模、框架、PAAS组件等，找出业务与云不适配的地方，提出解决方案。风险分析，这里有几个方面：数据风险，架构风险，安全风险，特别是安全这一块，对我们有很大挑战。在腾讯IDC，是一个相对封闭的环境，只有自己的员工能够登陆，但在云上是相对开放的环境，通过VPC与安全组等策略进行隔离。方案设计，最重要的是资源、成本、规划。
上云计划阶段，将我们所有要做的事情罗列出来，根据轻重缓急、先后次序，制定一个整体的执行计划。业务上云碰到两个主要问题，第一，业务本身对云的适配，第二，云对业务的兼容。举个例子，游戏上云，游戏的接入层多端口和多个客户端通信，CLB不支持多端口，也不支持连续端口段，这个就需要云的改造适配。在业务层面，老的开发和运营框架，都不支持业务云的体系，需要改造适配。
到实施阶段，主要包括功能测试、性能测试、数据迁移和云上部署等。云CVM跟相同配置的物理机对比，性能损耗控制在5%之内，对成本没有太大的提升，随着硬件技术的发展，成本不会是大问题。数据迁移，数据上云在上云过程中是最重要的部分，数据没有问题了，再将接入和逻辑进行上云。
到验证阶段，逐渐将业务流量一点点导入到我们测试环境中，包括业务的验证、效果评估。评估云上云下的质量，做问题的回归和优化。
前面做完，就到真正上云阶段了。传统的运维工作，上完云之后，也是一个挑战，当然也是一个很大的机会。原来的自动化、批量操作、自动扩缩容、弹性调度、系统监控等可以用云原生的方案，例如用容器TKE的方案，就很好的解决了之前的痛点问题。
上云各个环节的注意点。测试阶段，会从功能、性能来进行对比，特别要对特殊的业务场景进行测试。基本上会做到，测一个上一个，当然越到后面上得越顺，速度也会越来越快。方案阶段，会对安全、容量、上云的难度、数据的保障、数据的一致性、完整性做很多方案，同时也要做回滚方案。上云最担心的问题就是质量，这个决定了我们整个上云是否成功。在服务和调度质量、用户的访问质量、服务可用率几大方面进行评估，当然我们这里也用到了前面分享智能监控和告警系统，这一块帮助我们做了很多事情，使异常能够快速发现。
上云一定是数据先行，有三大方案。第一，直接将IDC的数据dump下来，导到云上的数据存储组件里，增量数据继续添加。第二，我们会将自研的存储服务在云上搭建起来，再将数据和服务迁到云上，这种方式不好的是要自己维护与迭代，长期的成本很高。第三，比较推荐的方案，用公有云的DTS工具，开发人员和运维人员都可以将它配置好，它可以实时同步数据导云的存储服务，数据可以高效、高质量地传输。
接入层和应用层上云比数据层简单很多，因为数据层会涉及到一致性和准确性校验，而应用层和接入层只要将它测试通过就可以。使用腾讯的DNS服务GSLB将流量逐渐切到云上。这个是灰度上云的过程，最后都会在云上。
四、简述QQ上云案例
再举个例子，QQ是一个庞大的体系。腾讯公司已经有21年的历程了，它是跟着腾讯一起成长起来的，也是我们第一款最大的产品。QQ的上云挑战非常大，现在QQ已经全部在云上了。我们也用了很多云原生的解决方案。QQ主要是三地部署，如下图所示。按上面介绍的思路，将数据迁到云上，再迁移接入层与逻辑层。在广州云和深圳自研之间有一个堡垒机进行数据传输，QQ和其他业务可以互联互通。
前面反复提的一个概念：云原生，它是云原生计算基金会CNCF发起的项目，2015年由谷歌牵头成立，第一个毕业的项目叫Kubernetes，目前它是容器的事实标准。如何理解这个云原生的概念呢？第一，它是在云上生长的，不是一个产品，而是一套技术体系和一套方法论。包括Devops、持续集成（CI）、持续交付（CD）、微服务、云基础设施（laas）、容器（K8S）、12要素等几大主题。结合云原生的方法论我们给出了业务的最佳实践，都融合到了我们自研上云里面。
TKE是腾讯云容器服务的解决方案，它天生结合了腾讯云的基础架构，和底层网络做适配。TKE在业务管理、网络、路由、分批灰度升级，测试、预发布流程等都做了较大的优化。
CI/CD/CO是研发测试到运维、运营整个过程，蓝盾，这个大家可以在云上搜索一下相关的介绍。它是体系化的CI/CD/CO解决方案来提升研发运维效率。
五、思考与总结
总结，第一，拥抱云原生，云原生在近五年一定是个趋势。第二，借上云革新研发模式，全面Devops（CI/CD/CO）。第三，组件和工具的上云，如何对业务和客户更好的服务。工程师文化如何培养，如何将这种技术氛围给调动起来。如何去用开源的东西，将自己的效率提升起来，这个过程是坎坷的，但成果也是斐然的。第四，开源生态、合作共享。第五，云基础设施经受海量业务的锤炼也变得更加强大。
六、讲师介绍
黄宏东，腾讯云高级工程师，应用开发出生的运维，负责过多款业务的运维工作，目前主要参与腾讯自研业务上云，推动业务从研发到运营体系的标准化、专业化，完善腾讯云生态。
---------下方更多精彩----------
452
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
