在线教育上云实践和架构演进思考
从17年开始，结合腾讯业务上云专项，在线教育从一开始的云IaaS层迁移，到更开放的开源中间件选型，再到思考云原生的研发模式，做了很多实践和思考，推动后台架构演进。本文整理自QCon全球软件开发大会（上海站）2019上的演讲，欢迎沟通交流。
目录
一、自研业务上云的背景 二、团队关于云原生的激烈讨论 三、梳理痛点，规划业务后台架构演进方向 四、优化微服务架构 五、调整中间件选型 六、完善DevOps工具链
一、自研业务上云的背景
历史“烟囱式”的业务研发
腾讯历史研发模式，不同的BG或者部门，或多或少从上到下会有自己的一套技术栈，如下图：
一方面对做组件的同学是种锻炼，另一方面也积累了很多技术债务：
-
重复造轮子，每个BG/部门一套
-
缺乏部门间的分享和协作
-
有影响力的开源较少
-
数据不互通，部门间代码互相封闭
-
没有统一技术图谱
腾讯930调整后的2大技术战略
意识到这个问题之后，腾讯930调整，成立新的云事业群，内部成立“技术委员会”，启动“开源协同”和“业务上云”的两大战略方向。
在架构演进中，上云的价值是什么？
1、业务价值
-
聚焦业务，提升研发效率
-
加快技术换代，保持技术优势（传统互联网 vs 云时代）
-
使用更好的云开源组件服务（可用性、稳定性、文档API…）
-
计算资源重用，弹性伸缩，优化成本
-
标准化CI/CD流程
2、工程师价值
-
扩宽技术视野，避免闭门造车
-
掌握的技能更有价值
-
输出优秀组件到云，提高影响力
3、腾讯云价值
-
为客户输出业务上云经验
-
帮助腾讯云打磨云组件
二、团队关于云原生的激烈讨论
云原生的关键技术和里程碑节点
从2013年Matt Stine首次提出云原生概念，到后面k8s、Mesh、serverless的普及，云原生的思路被越来越多人讨论。
云原生的定义，解决什么问题？
从2个方面来看云原生定义：利用云平台优势，擅长解决这些互联网业务问题
-
云计算本质：按需分配资源和弹性计算
-
互联网业务特点：快速迭代、逻辑复杂、海量用户、流量突增、7*24小时高可用
云原生应用和传统企业应用区别：
团队对云原生的思考
-
开始是问号脸：听过无数的道理，却仍旧过不好这一生，囧
-
后面开始结合实际分析目标：通过 基础云平台、云中间件、面向微服务、容器编排调度，以及Devops流程的优化整合 ，来提升业务团队研发 效率和质量 ，帮助业务降低风险、更快交付
-
最后开始实践上云
三、梳理痛点，规划业务后台架构演进方向
腾讯课堂初期的后台架构设计
基于SOA的后台服务架构，简单的架构分层和周边基础支撑工具建设：
历史架构痛点分析
这些痛点list都是很有价值的宝藏，能够从中挖掘出最适合自己业务的架构演进方向：
规划业务后台架构演进方向
针对这些业务痛点，开始聚焦微服务、中间件、DevOps这3个方向，结合业务上云来帮助推动架构演进。这里把做的最核心的Top10的事情列出来介绍
1、优化微服务架构
-
约定应用统一开发规范，往云原生靠齐
-
整合ApiGateway，统一微服务对外API调用入口
-
推动服务复用，建设业务中台
-
音视频等模块迁移腾讯云PaaS服务
2、调整中间件选型
-
规划更开放的开源中间件选型图谱
-
制定自研组件切换云组件计划
-
借助工具，提升数据迁移上云的效率和质量
3、完善DevOps工具链
-
建立业务统一的蓝盾CI流水线（CI）
-
服务全面容器化，迁移腾讯云TKE平台（CD）
-
统一全链路日志上报，聚焦调用链监控体系建设（CO）
四、优化微服务架构
约定应用统一开发规范，往云原生靠齐
参考Matt Stine提出的云原生12-Factor，有很多点现在回头看起来感觉很有先见之明：
基于业务最佳实践的应用开发规范
统一的技术栈，包括语言、协议、开发框架等
-
外部只有通过ApiGateway才能访问
-
服务间只能通过Rpc或消息队列通讯
-
服务无状态化，能快速启动关闭
-
框架对同类组件可插拔，更换具体组件不改服务代码
-
基于PB自动代码生成，基于CI自动规范校验
-
尽量都走远端配置，修改配置不用发布或重启服务
-
数据库（KV/DB）按具体业务模块提供访问
-
… …
针对历史痛点优化微服务架构
下面是优化后的微服务架构，主要的几点：
-
接入层：整合ApiGateway，对内部微服务API统一进行认证、鉴权、生命周期管理、熔断、限流、监控告警等
-
逻辑层：追求逻辑代码越来越少，服务复用往下层抽
-
中台层：推动服务复用，建设业务中台，优先考虑云上PaaS服务，避免闭门造车，服务团队多个教育产品
-
容器层：微服务全量容器化，推动部署云TKE
-
中间件：制定数据迁移方案，统一切换使用腾讯云中间件
-
Devops工具链：聚焦运营痛点，推动适合业务的CI/CD/CO 工具链
音视频等模块迁移腾讯云PaaS服务
这个是课堂音视频迁移到云PaaS后的架构图，蓝色腾讯云负责音视频流处理，绿色业务只负责信令交互，让开发更聚焦业务逻辑。
下面是迁移云PaaS服务之后的一些优化数据
五、调整中间件选型
规划更开放的开源中间件选型图谱
关于技术栈或者中间件选型，这2年团队比较大的感受就是 从封闭到开放 。哪些是值得学习引入的开源项目？我们也在不断完善这样一个开源图谱xmind，去统一指导技术选型
对于开源的选型，团队也有自己的一些参考思路：
-
适合业务当前需求
-
优先参考 CNCF Landscape
-
开源社区热度
-
云平台支持情况
-
GitHub的Star、Issues等
-
公司和作者影响力
-
开源协议：GPL等
制定自研组件切换云组件计划
无论是自研CKV切到云Redis，自研Hippo切到云CKafka，里面涉及的细节很多就不展开，这里比较好的实践是切换比较制定好完整的方案规划，并且一步步来实施，防止踩坑
举2个实际的Badcase，证明为什么迁移前做完整验证很重要：
-
切云CDB，因为云上mysql5.6版本默认链接字符集和自研的不一样，导致没有手动设链接字符集的模块出现乱码
-
切云Redis，因为没有压测想当然，导致Redis的分片申请不够出现高负载
借助工具，提升数据迁移上云的效率和质量
基于腾讯云DTS做数 据迁移上云 和 异构数据同步 ，可以帮助业务解决很多繁琐的迁移细节
-
支持多种关系型和NoSql数据库
-
基于数据库binlog日志解析，简单配置，提供增量数据订阅消费
-
数据不停机迁移，最小化对线上业务影响
-
兼容公网、VPN、专线等多种网络环境接入
六、完善DevOps工具链
建立业务统一的蓝盾CI流水线
-
研发效率如何提升？统一服务流水线模板，GitHook一键部署，使用丰富的插件能力
-
研发质量如何把控？集成Coverity等代码检测，服务必须通过质量红线检查和自动化测试
服务全面容器化，迁移腾讯云TKE平台
1、基于docker全面容器化
-
统一镜像仓库，版本管理
-
基于镜像交付，打包二进制+运行环境
-
资源隔离，安全性高
-
快速部署，秒级扩缩容
2、基于kubernetes应用改造
-
持久数据挂载远程存储，防止Pod重启丢失
-
配置依赖k8s环境变量设置
-
服务无状态化，去除ip权限依赖等问题
-
服务快启动销毁，确保Pod便捷变更
-
补齐服务k8s相关日志监控
统一全链路日志上报，聚焦调用链监控体系建设
关于CO环节的设计思考
-
先明确痛点是什么（无效告警多？告警不及时？定位问题慢？）
-
对比大而全的指标监控，可优先把 调用链监控 做到简单极致（自动生成服务调用拓扑，发现链路 异常点 和 性能瓶颈 ）
-
通过云原生组件来搭建（ELK、Prometheus、jaeger）
正文到此结束
- 本文标签： 关键技术 CTO 软件 src 高可用 tk 协议 https sql 开源项目 需求 插件 MySQL5 id 微服务 目录 git 安全 PaaS 代码 架构演进 企业 自动生成 限流 云 ip 产品 redis IaaS list Uber 生命 架构设计 mysql 质量 互联网 GitHub 消息队列 同步 服务团队 乱码 自动化 教育 数据 API Docker http 本质 db 数据库 UI SOA 解析 开源 VPN 工程师 2019 认证 tar 配置 管理 Kubernetes 开发 运营 ELK 部署 测试 NOSQL
- 版权声明： 本文为互联网转载文章，出处已在文章中说明(部分除外)。如果侵权，请联系本站长删除，谢谢。
- 本文海报： 生成海报一 生成海报二
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
