业务上云实践和架构演进思考

2019-10-22 17:18:26 浏览数 (1)

从17年开始，结合公司业务上云专项，在线教育从一开始的云IaaS层迁移，到更开放的开源中间件选型，再到思考云原生的研发模式，做了很多实践和思考，推动后台架构演进。这里把这些实践思考做下分享，欢迎沟通交流

目录

一、自研业务上云的背景

二、团队关于云原生的激烈讨论

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

四、优化微服务架构

五、调整中间件选型

六、完善DevOps工具链

自研业务上云的背景

历史“烟囱式”的业务研发

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

烟囱式.png

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

  • 重复造轮子，每个BG/部门一套
  • 缺乏部门间的分享和协作
  • 有影响力的开源较少
  • 数据不互通，部门间代码互相封闭
  • 没有统一技术图谱

腾讯930调整后的2大技术战略

意识到这个问题之后，腾讯930调整，成立新的云事业群，内部成立“技术委员会”，启动“开源协同”和“业务上云”的两大战略方向

2大技术战略.png

在架构演进中，上云的价值是什么？

1、业务价值

  • 聚焦业务，提升研发效率
  • 加快技术换代，保持技术优势（传统互联网 vs 云时代）
  • 使用更好的云开源组件服务（可用性、稳定性、文档API…）
  • 计算资源重用，弹性伸缩，优化成本
  • 标准化CI/CD流程

2、工程师价值

  • 扩宽技术视野，避免闭门造车
  • 掌握的技能更有价值
  • 输出优秀组件到云，提高影响力

3、腾讯云价值

  • 为客户输出业务上云经验
  • 帮助腾讯云打磨云组件

团队关于云原生的激烈讨论

云原生的关键技术和里程碑节点

从2013年Matt Stine首次提出云原生概念，到后面k8s、Mesh、serverless的普及，云原生的思路被越来越多人讨论到

关键里程碑1.png

关键里程碑2.png

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

从2个方面来看云原生定义：利用云平台优势，擅长解决这些互联网业务问题

  1. 云计算本质：按需分配资源和弹性计算
  2. 互联网业务特点：快速迭代、逻辑复杂、海量用户、流量突增、7*24小时高可用

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

应用区别.png

团队对云原生的思考

  1. 开始是问号脸： 听过无数的道理，却仍旧过不好这一生，囧
  2. 后面开始结合实际分析目标： 通过基础云平台、云中间件、面向微服务、容器编排调度，以及Devops流程的优化整合，来提升业务团队研发效率和质量，帮助业务降低风险、更快交付
  3. 最后开始实践上云：

理解上云的3个层次.png

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

腾讯课堂初期的后台架构设计

基于SOA的后台服务架构，简单的架构分层和周边基础支撑工具建设：

初期的后台架构设计.png

历史架构痛点分析

这些痛点list都是很有价值的宝藏，能够从中挖掘出最适合自己业务的架构演进方向：

来自于团队大家的问卷调查case.png

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

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

1、优化微服务架构

  • 约定应用统一开发规范，往云原生靠齐
  • 整合ApiGateway，统一微服务对外API调用入口
  • 推动服务复用，建设业务中台
  • 音视频等模块迁移腾讯云PaaS服务

2、调整中间件选型

  • 规划更开放的开源中间件选型图谱
  • 制定自研组件切换云组件计划
  • 借助工具，提升数据迁移上云的效率和质量

3、完善DevOps工具链

  • 建立业务统一的蓝盾CI流水线（CI）
  • 服务全面容器化，迁移腾讯云TKE平台（CD）
  • 统一全链路日志上报，聚焦调用链监控体系建设（CO）

优化微服务架构

约定应用统一开发规范，往云原生靠齐

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

云原生12-Factor.png

基于业务最佳实践的应用开发规范

  • 统一的技术栈，包括语言、协议、开发框架等
  • 外部只有通过ApiGateway才能访问
  • 服务间只能通过Rpc或消息队列通讯
  • 服务无状态化，能快速启动关闭
  • 框架对同类组件可插拔，更换具体组件不改服务代码
  • 基于PB自动代码生成，基于CI自动规范校验
  • 尽量都走远端配置，修改配置不用发布或重启服务
  • 数据库（KV/DB）按具体业务模块提供访问
  • … …

针对历史痛点优化微服务架构

下面是优化后的微服务架构，主要的几点：

  • 接入层：整合ApiGateway，对内部微服务API统一进行认证、鉴权、生命周期管理、熔断、限流、监控告警等
  • 逻辑层：追求逻辑代码越来越少，服务复用往下层抽
  • 中台层：推动服务复用，建设业务中台，优先考虑云上PaaS服务，避免闭门造车，服务团队多个教育产品
  • 容器层：微服务全量容器化，推动部署云TKE
  • 中间件：制定数据迁移方案，统一切换使用腾讯云中间件
  • Devops工具链：聚焦运营痛点，推动适合业务的CI/CD/CO 工具链

优化后的后台架构.png

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

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

音视频模块架构.png

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

使用云PaaS后优化数据.png

调整中间件选型

规划更开放的开源中间件选型图谱

关于技术栈或者中间件选型，这2年团队比较大的感受就是从封闭到开放。哪些是值得学习引入的开源项目？我们也在不断完善这样一个开源图谱xmind，去统一指导技术选型

开源图谱选型指导.png

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

  • 适合业务当前需求
  • 优先参考 CNCF Landscape
  • 开源社区热度
  • 云平台支持情况
  • GitHub的Star、Issues等
  • 公司和作者影响力
  • 开源协议：GPL等

优先参考CNCF Landscape.png

制定自研组件切换云组件计划

无论是自研CKV切到云Redis，自研Hippo切到云CKafka，里面涉及的细节很多就不展开，这里比较好的实践是切换比较制定好完整的方案规划，并且一步步来实施，防止踩坑

举2个实际的Badcase，证明为什么迁移前做完整验证很重要：

  1. 切云CDB，因为云上mysql5.6版本默认链接字符集和自研的不一样，导致没有手动设链接字符集的模块出现乱码
  2. 切云Redis，因为没有压测想当然，导致Redis的分片申请不够出现高负载

制定切换计划方案.png

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

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

  • 支持多种关系型和NoSql数据库
  • 基于数据库binlog日志解析，简单配置，提供增量数据订阅消费
  • 数据不停机迁移，最小化对线上业务影响
  • 兼容公网、V**、专线等多种网络环境接入

腾讯云DTS.png

完善DevOps工具链

建立业务统一的蓝盾CI流水线

  1. 研发效率如何提升？统一服务流水线模板，GitHook一键部署，使用丰富的插件能力
  2. 研发质量如何把控？集成Coverity等代码检测，服务必须通过质量红线检查和自动化测试

业务蓝盾流水线.png

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

1、基于docker全面容器化

  • 统一镜像仓库，版本管理
  • 基于镜像交付，打包二进制 运行环境
  • 资源隔离，安全性高
  • 快速部署，秒级扩缩容

2、基于kubernetes应用改造

  • 持久数据挂载远程存储，防止Pod重启丢失
  • 配置依赖k8s环境变量设置
  • 服务无状态化，去除ip权限依赖等问题
  • 服务快启动销毁，确保Pod便捷变更
  • 补齐服务k8s相关日志监控

统一全链路日志上报，聚焦调用链监控体系建设

关于CO环节的设计思考

  1. 先明确痛点是什么（无效告警多？告警不及时？定位问题慢？）
  2. 对比大而全的指标监控，可优先把调用链监控做到简单极致（自动生成服务调用拓扑，发现链路异常点和性能瓶颈）
  3. 通过云原生组件来搭建（ELK、Prometheus、jaeger）

从端到后台的数据统一自动埋点.png

基于jaeger的全链路分析.png

云直播 云点播 云API 微服务

0 人点赞