原因

背景：

1、xx业务经过多轮的业务决策和调整，存在非常多技术包袱，带了不好的用户体验和极高的维护成本

2、多套机房部署，服务部署复杂，性能可靠性无法保证

3、多套后端接口，前端接入标准不统一，通用逻辑不一致（扣费、试用、商业化）

4、单机房单应用，服务的高可用需要进一步提升

5、缺失前后端通用业务组件设计，复用性不高

背景总结：

业务的调整，合并多个服务，前端接入多套后端接口，通用的扣费、试用等逻辑不一致，所以服务拆分，以及需要做统一的微服务网关；

之前是多个单机房单体应用，需要提高服务的高可用，以及数据的高可用；

改造方案

新架构图

技术选型

项目	技术选型	集成能力
xx服务网关	Traefik	用户鉴权、限流器
go框架	goframe

思考

对于微服务网关的调研，为什么选用这个云原生网关，跟传统网关的区别，以及这个网关服务跟普通服务有什么区别？

服务拆分

序号	服务	代号	拆分定义	技术选型
01	服务网关	xx-gateway	xx全流量网关，支撑xx全部业务流量，提供用户鉴权、限流器、微服务转发基础能力	Traefik
02	接入层	xx-api	负责xx产品所有API的注册、参数验证、服务调度	goframe
03	用户服务	xx-usersrv	主要负责用户相关业务服务提供	主要包含 授权、积分、产品管理模块
04	应用服务	xx-appsrv	主要负责xx业务服务能力提供，主要包含 1、编辑器 2、轻编辑 3、工具箱（媒体处理、AI生成）4、存储服务（凭证、签名、转存、删除、分享）	goframe
05	用户运营管理后台	xx-admin	提供xx整理业务运营数据可视化呈现、运营配置、权益流水等	Dcat Admin(php)

公共组件设计

序号	组件	职责
01	外部服务调用SDK	统一封装外部服务的SDK组件，整合公司中台依赖所有服务，只负责网路请求，重试，相关错误返回给调用方
02	任务组件服务	统一封装任务组件，支持分布式，实现重试、延迟、定时、回调、任务记录、任务编排相关能力

自部署算法服务

各种算法的部署+ 有个中间服务调度算法任务

例如 视频压缩算法的调用：

排期计划

序号	项目	责任人	预计上线时间
01	整体架构文档方案输出	One Two
02	代码拆分改造（接入层、用户服务、 应用服务、构建发布改造搭建）	One
03	服务结构拆分、配置分离、boot、vars、components结合作组件初始化、组件配置化	One
04	服务网关的搭建	One Two	阶段1改造：第一个月底
05	基础组件搭建，抽出基础组建层，定义相关标准	Three
06	基础组件搭建，外部云服务SDK封装	Three
07	基础组件搭建，任务通用组件封装	One Two
08	基础组件搭建，其他通用组件封装	Three
09	IBM服务替换接入云平台新接口	Three
10	接入层代码逻辑迁移	Three
11	用户服务和应用服务代码迁移，逻辑改造（服务级的调用方式）	Two Three
12	数据库的拆分（用户库、应用库）	Two
13	服务网格接入	Two
14	全局流量管理开发，整体架构多活适配改造与验证	One
15	全球多活节点部署	One
16	部分流量的验证	One
17	全部流量的上线	One

全球多活改造