一、业务简介和系统现状
我先对外渠业务做一个简单的介绍以及系统现状是什么样的
分销商/加盟商这些商户通过协议入驻到平台，享受平台提供的盘源与作业工具，平台也会分发一些商机，也就是客源，主要是商户自己的吧。最终成交后，按照协议比例分佣金。
外渠商家要在平台作业，需要渠道经理维护带着签署协议，然后挂到门店经纪人，在平台上查看盘源，进行作业流程，成交之后给根据协议商家分佣金。
系统现状是几个具有相似业务主体和业务流程的单体服务在运营，拿分销商举个例子。
总结了几个痛点
现象：整体外渠作业工单不断，系统不稳定。大大影响作业效率。整个治理过程伴随着外渠GMV提升占比30%多。
- 业务逻辑混乱
- 模型不统一
- 数据不标准
- 架构混乱，各服务职责不清晰
领域驱动设计实践 juejin.cn/post/713118…
二、主要做的事情
单体如何拆解微服务
具体拆解场景的解决方案
1、数据库外键引用关系-> 停止外键引用，改为rpc调用
2、共享静态数据-> 统一配置中心
3、共享基础数据-> 沉淀基础服务
4、共享数据库-> 分阶段重构数据
1. 业务逻辑复杂性治理
自顶向下结构化分解
结构化分解是流程的，是面向过程的，需要考虑面向对象的。
外渠商家要在平台作业，需要渠道经理维护带着签署协议，然后挂到门店经纪人，在平台上查看盘源，进行作业流程，成交之后给商家分佣金。
统一语言
简历核心领域词汇表
业务 运营 技术 产品 等
业务概念、PRD文档、日常沟通、设计文档、代码
2. 应用架构治理
应用结构的核心就是把业务复杂度和技术复杂度分离，业务系统出了业务复杂之外还要处理比如微服务的一些东西比如消息队列、缓存、限流等各种分布式系统的技术复杂度在里面。这个时候如果我们不把业务复杂度和技术复杂分离的话，当我们的业务很复杂，技术也很复杂，当两种复杂交织在一起的时候就会让事情变得更糟糕。让上帝的归上帝，让凯撒的归凯撒。
1.1 统一数据，统一模型
商户数据统一沉淀到中台，伴随数据治理 根据领域拆分沉淀数据模型，定义协议基础数据（协议编码、协议主体、协议类型、协议状态）商家基本数据（统一编码、信用代码、商家类型、法人信息、账户信息）人店数据（组织编码、组织关系）
1.2 微服务拆分
协议中心、商机中心、人店中心
各微服务通过事件驱动解耦
1.3 服务分层设计与解耦设计（事件驱动）
1.4 应用架构组件化 （做解耦与防腐）地址库/mdm标准库/模版库/组织信息库
业务组件解耦与防腐
防腐层
解耦性更好，但是成本稍微大一些
3. 稳定性治理
基础监控（内存/CPU/组件redis/mysql/kafka等） 应用监控（外部接口异常/当前服务接口异常）
基本原则 基础监控全面覆盖，应用监控划分业务等级，一级核心重点覆盖，小步快跑。提前预判、及时影响。
- 关键节点与关键路径识别（基于业务）
- 完善监控报警
- 值班策略，及时跟进。沉淀常见问题解决手册。
- 完善限流降级、预案演练
三、方法论沉淀
- 复杂系统重构
DDD本身概念很多，DDD是一种思想，关键不在于这些教条的概念，真正的内核是统一语言、边界上下问题、领域划分、领域模型、
应用结构的核心就是把业务复杂度和技术复杂度分离，业务系统出了业务复杂之外还要处理比如微服务的一些东西比如消息队列、缓存、限流等各种分布式系统的技术复杂度在里面。这个时候如果我们不把业务复杂度和技术复杂分离的话，当我们的业务很复杂，技术也很复杂，当两种复杂交织在一起的时候就会让事情变得更糟糕。让上帝的归上帝，让凯撒的归凯撒。
- 多应用方接口迁移的想法
统一语言
简历核心领域词汇表
业务 运行 技术 产品 等
业务概念、PRD文档、日常沟通、设计文档、代码
防腐层
解耦性更好，但是成本稍微大一些
四、挑战
- 整个实施过程中 数据一致性的问题/步骤问题
- 常规需求与重构的平衡点（两个原则，1、优先重构独立中心如协议 2、协同pm界定常规需求优先级，评估是否重构后能满足诉求）
- 下游迁移推动问题
五、实施阶段
概述
-
数据写迁移
- 增量数据双写
- 历史数据迁移
-
灰度读迁移+diff验证
- 读取旧数据，新数据+历史数据验证
- 读取新数据，旧数据验证
-
验证完成切全量，灰度与diff功能退出
1 数据写迁移
- 第一阶段 写逻辑重构到微服务，完成新接口逻辑的初步回归测试
- 第二阶段 历史数据迁移，主要借助DBA在凌晨低峰迁移（历史数据前置，主要是数据量和请求量较低）
- 第三阶段 增量双写开启，保持原逻辑，异步请求新的微服务接口
- 第四阶段 两点保证异步diff，数据巡检+打点数据回归，核心出问题还是在业务逻辑中。修复回归
数据写迁移阶段完成后，历史数据迁移完成、增量双写切换，初步保障数据一致性
2 数据读迁移
- 第一阶段 读逻辑重构到微服务，完成接口逻辑的初步回归测试，同时打造公共组件（支持灰度策略/异步diff/打点统计等）对新旧数据结果进行对比、Diff验证，Diff结果埋点、统计。
- 第二阶段 读取旧数据，新数据+diff
- 第三阶段 读取新数据，旧数据验证 （部分业务迁移+后续推动其他业务迁移）
后续两个部分 1、自闭环页面与接口整体迁移
2、其他业务方推动迁移
这个阶段完成后，异步对比数据已全部对齐（根据埋点统计结果），全量diff和读diff可以下掉
3 验证切全量
异常处理&回滚
由于旧库数据，在双写切单写前，一致在写入全部数据，所以我们一直拥有一份全量的干净数据，方便我们读回滚，同时不存在写回滚的问题。
在写阶段，发现diff有问题时，需要case by case排查原因，一般是逻辑梳理或者代码bug导致，需要回溯原因，修复bug/修复数据
在读阶段，diff很少出现问题，主要用于结果统计与灰度等
