自研业务上云的背景历史“烟囱式”的业务研发

　　自研业务上云的背景历史“烟囱式”的业务研发

　　17年以来，结合公司业务云专项项目，在线教育从一开始的云IaaS层迁移，到更加开源的中间件选择，再思考云原生的研发模式，并做了大量的实践和思考，推动了后端架构的演进。在这里分享这些实用的想法，欢迎交流

　　内容

　　一、云上自学业务背景

　　二、Team 关​​于云原生的热烈讨论

　　三、梳理痛点，规划业务后端架构演进方向

　　四、优化微服务架构

　　五、调整中间件选择

　　六、Perfect DevOps 工具链

　　自研业务上云“烟囱式”业务研发背景历史

　　腾讯的历史研发模式，不同的BG或部门，或多或少都会有一套自上而下的技术栈，如下图：

　　烟囱样式.png

　　一方面对做组件的同学来说是一种锻炼，另一方面也积累了很多技术债：

　　腾讯930调整的两大技术战略

　　意识到这个问题后，腾讯930进行了调整，成立了新的云事业群，内部成立了“技术委员会”，推出了“开源协作”和“业务上云”两个战略方向

　　两大技术战略.png

　　在架构的演进过程中，上云有什么价值？

　　1、商业价值

　　2、engineer 值

　　3、对齐云值

　　团队就云原生关键技术和里​​程碑节点展开激烈讨论

　　从2013年Matt Stine提出的云原生概念，到k8s、Mesh、Serverless的普及，云原生的想法被越来越多的人讨论

　　关键里程碑1.png

　　关键里程碑2.png

　　云原生的定义解决了什么问题？

　　从两个方面看云原生的定义：利用云平台，善于解决这些互联网业务问题

　　云计算的本质：资源按需分配，计算灵活 互联网业务特点：迭代快、逻辑复杂、用户海量、流量突增、7*24小时高可用

　　云原生应用与传统企业应用的区别：

　　应用差异.png

　　团队对云原生的思考开始打了个问号：听过无数道理，却依然过得不好。后来我开始结合实际分析目标：通过基础云平台、云中间件、微服务、容器编排调度，以及Devops流程的优化和整合，提升业务团队的研发效率和质量，帮助企业降低风险、加快交付速度，并最终开始在云端实践：

　　了解上云.png的3个层次

　　梳理痛点，规划业务后端架构演进方向。腾讯课堂初始后端架构设计

　　基于SOA的后端服务架构，简单的架构分层及周边基础支撑工具搭建：

　　初始背景架构design.png

　　历史建筑痛点分析

　　这些痛点列表都是宝贵的财富，从中可以挖掘出最适合自己业务的架构演进方向：

　　来自团队成员的问卷调查case.png

　　规划业务后端架构演进方向

　　针对这些业务痛点，我们开始聚焦微服务、中间件、DevOps三个方向，结合云上业务，帮助推动架构演进。这里列出最核心的Top10事情做介绍

　　1、优化微服务架构

　　2、调整中间件选择

　　3、Perfect DevOps 工具链

　　优化微服务架构，同意统一开发规范，原生上云

　　参考Matt Stine提出的云原生12-Factor，有很多点，现在回过头来看很有先见之明：

　　云原生 12-Factor.png

　　基于业务最佳实践的应用开发规范针对历史痛点优化微服务架构

　　以下是优化后的微服务架构，要点：

　　优化的后台架构.png

　　音视频模块迁移至腾讯云PaaS服务

　　这是课堂音视频迁移到云PaaS后的架构图。蓝色腾讯云负责音视频流处理，绿色业务只负责信令交互，让开发更专注于业务逻辑

　　音视频模块架构.png

　　以下是迁移云PaaS服务后的一些优化数据

　　使用云PaaS后的数据优化.png

　　调整中间件选型方案，开放开源中间件选型图

　　关于技术栈或者中间件的选择，团队这两年更大的感觉是从封闭到开放。哪些开源项目值得学习和引进？我们也在不断完善xmind这样的开源地图，统一技术选择的指导

　　开源 Atlas.png 选择指南

　　对于开源的选择，团队也有自己的一些参考思路：

　　优先参考CNCF Landscape.png

　　制定自研组件转云组件计划

　　无论是自研CKV切入云Redis，自研Hippo切入云CKafka，涉及的很多细节就不展开了。这里更好的做法是制定一个完整的计划并逐步实施。防止踩坑

　　引用 2 个实际的 Badcase 来证明为什么在迁移前进行完整验证很重要：

　　切云CDB，因为云上mysql5.6版本的默认链接字符集与自研版本不同，导致模块代码乱码，无需手动设置链接字符集。砍云Redis因为没有压力测试，导致Redis。分片应用不够，负载高

　　制定转换计划.png

　　借助工具，提高数据上云的效率和质量

　　基于腾讯云DTS进行数据上云和异构数据同步，帮助企业解决很多繁琐的迁移细节

　　腾讯云 DTS.png

　　完善 DevOps 工具链，建立统一的 Blue Shield CI 管道。如何提高研发效率？统一服务管道模板、GitHook一键部署、丰富插件能力的使用，如何把控研发质量？集成Coverity等代码检查，服务必须通过质量红线检查和自动化测试

　　商务蓝盾流水线.png

　　全面服务容器化，腾讯云TKE平台迁移

　　1、基于docker的完全容器化

　　2、基于kubernetes的应用改造

　　统一全链路日志上报，重点建设调用链监控系统

　　关于 CO 链接的设计思考

　　首先明确痛点是什么（无效告警过多？告警不及时？定位慢？） 相对于大而全面的指标监控，可以优先考虑简单极端的调用链监控（自动生成服务调用拓扑和发现链接异常点和性能瓶颈）通过云原生组件（ELK、Prometheus、jaeger）构建

　　从头到尾的数据统一自动埋藏.png

　　基于jaeger.png的全链接分析