开发痛点
先来张图看下吧。
1. 逻辑散乱到几个service中,大量的transaction script类代码。
2. 一部分逻辑就花了200多行,大量平铺代码,难以复用。
3. 充斥着大量入参,维护性极低。
4. 等等等等……
原始思路
· 对于渠道路由于后期肯定是需要有很多可变因素,步骤的, 所以需要考虑流程可编排 便于后期动态调整。
· 流程可控后为保证数据随时可用,可传递考虑 控制流与数据流分离原则。
· 结合路由领域来说,需要实现 过滤、规则执行 等特殊功能组件。考虑PipeLine管道模式 进行实现。·
· 具体领域逻辑中有: 不同PaymentMethod、 不同版本setting数据等都会综合影响整个渠道过滤流程,考量因素差异性比较大,考虑不同代码实体实现主要变化点逻辑隔离 。
演化历程
以下总结了一下重构的整个的思考过程。
· 按照之前原始思路定好了主要组件与设计框架开发。 →
· 后来发现setting的不同version与不同paymentMethod都可以影响Rules的组合与逻辑。→
· Pm、Version、Rule三者存在共同影响。
a. 代码硬隔离实现,灵活度低,复杂度会高,需要新增许多类但执行效率可控。
b. 通过反射实现,灵活度高,复杂度也高,但执行效率偏低。
· 有木有一种方法既可以实现高灵活度的自定义又不需要用反射呢? →
· 组件、流程元数据配置化 + Spring Ioc + 无状态组件 + 数据context流实现插件式开发。 →
· 实现后发现SettingFilter中要体现version概念,又不想有version逻辑判断与不同version的Pipe嵌入主流程。→
· 想到用Strategy模式注入VersionalSettingService,让其自感知版本并处理过滤SettingDimension逻辑。 →
· 为了组织Dimension在一起避免太多类,需要统一Dimension接口,考虑Enum组织SettingDimension。 →
· 分析发现原来考虑的每个Dimension需要统一的XXXDimensionSetting对象结果用于切面逻辑。Version需要VersionSettingResolver去处理不同version的setting到XXXDimensionSetting的适配逻辑。 →
· 初期感觉代码复杂度与空间复杂度过高,且不确定未来情况下统一的XXXDimensionSetting对象是否可满足要求。 怎么办? →
· 进行争议选项分析,具体见下节。综合考虑选择:移动计算到数据的模式。考虑不同version数据维持在一个结构中,让计算逻辑XXXDimension在统一version的结构中被运用。 →
· 则SetttingDimensionEnum也可以分不同version的Dimension。 →
· 在发现不同version的DimensionEnum中处理有些公共逻辑,再用composite方式注入公共Dimension Strategy类 →
· 后发现有不同version的Resonpon逻辑要处理,抽象出VersionalResponseBuilder供调用 →
· 为了简化依赖,统一用VersionalSettingService处理,其代理VersionalResonseBuilder逻辑。利用Kotlin委托实现Adaptor模式
最后细化细节,譬如日志,缓存等。
争议选型:
设计选型:
a方案: 以SettingDimension为主,新建settingObject与不同version的VersionResolver适配Dimension方法进行过滤,让数据适配逻辑。 单独SettingDimension,单独VersionResolver,单独SettingObject。
b方案: 以versionSetting为主,不同的VersionalSetting对应于多个SettingDimension方法,不转换对象,让versionSetting结构逻辑内化到自身,让逻辑适配数据。
时间复杂度之争:
时间复杂度基本与以前相同
空间复杂度之战:
移动计算到数据设计vs移动数据到计算设计
结论: 同样策略模式-> 数据具体封闭在一起去除多余转换与转移,比较灵活可控。 计算策略移动到数据源去处理某些情况下前者更小空间复杂度,更灵活
d: 过滤维度 v: setting版本 p: 渠道数量
空间复杂度:m+v=o(n)vs mv=o(n2)
譬如:数据有n个版本data,计算有m种strategy
data: 分为 d_v1,d_v2 ...., d_vn strategy: 分为 s_1, s_1, ... s_m
目的基本就是:找到对应策略执行各种版本数据
方式一:if 移动数据到计算的方式, 这么设计: strategy.process(common data) 。某些情况下,需要定义一个针对此strategy的common data,用于具体strategy 处理此common data结构
方式二:if 移动计算到数据的方式, 这么设计: data.processBy(strategy) 此种情况下,数据具体封闭在data 类中,比较灵活可控。 计算策略移动到数据源去处理
实现步骤:
1. 定好基调:
2. 快速实现框架流程:
3. 填入细节:
4. 细节方案选型:
5. 评审与验证方案
6. 实施方案并反复修改推演
7. 修缮细节:优化日志,缓存,错误处理等细节。
8. 测试与细节再修缮:
最终结构
Configer: 配置管理器,管理核心配置的获取,
包含 Pipe, Rule, Filter, Dimension, PaymentMethod, Version等编排元素的配置获取。
Pipe: 支持动态编排的管道系统。通过Configer获取Pipe配置动态编排管道流程。
DataAssemblerPipe:查询setting数据,pipe line 数据装配准备。
RulePipe:根据rule规则执行rule逻辑。
DecisionPipe:实现决策最终pmp的逻辑。
Rule: 支持动态编码的Rule规则。通过Configer获取Rule配置动态编排管道流程。
FiltersRule:支持过滤逻辑的规则。
TransactionData Rule,RiskControlRule:暂未实现。
Filter: 支持动态编码的Filter。通过Configer获取Filter配置动态编排管道流程。
SettingFilter:组织执行版本化的setting的过滤。
ProbabilityFilter:根据概率逻辑执行过滤。
VersionalSettingService: 支持版本化的setting服务。 通过Configer获取Dimension配置动态编排SettingDimension执行流程。
AssembleDimension:组织dimension流程。
Execute:执行Dimension并过滤pmp。
VersionalResonpseBuilderHolder:委托相应version的ResponseBuilder执行buildResponse逻辑。
VersionalSettingDimension: 支持版本化的setting匹配维度
组织各个版本的不同dimension数据,并调用DimensionStrategy匹配共有dimension逻辑。
实现
DimensionStrategy: setting维度匹配策略,校验相关setting中相应内容是否匹配。
包含PaymentMethod,Region,TransactionCcy等策略
VersionalResponseBuilder: 支持版本化的返回数据构建器
SettingModel: 具体setting领域对象
最终效果:
废话不多说,上图吧:
基本每个类代码不超过200行,各个组件按照意图分离,流程控制可配置化
总结
· 实现 Rules 规则组件统一控制各种规则执行。
· 实现Filters 过滤器组件统一控制转发与短路。
· 流程元数据配置化。通过组合维度可以灵活控制主要流程。
· 规则配置化。利于插件式开发。
· 不同版本setting数据的一些共有逻辑内置化到充血领域模型,便于复用。
重构心得
· 类比service mesh领域: 控制平面与数据平面分离
· 类比大数据、边缘计算领域: 移动计算逻辑到数据的设计方法 (某些情况下可提升灵活性、减少空间复杂度)
· 渐进性设计:重构一些,多想备选方案,综合比对后优化
· 架构分析方法论: 设计 → 编码-> 难点方案进行多维度选型 → 重设计与编码 → 评估 → 再循环
未来展望:
routing service规划:
1. 统一setting获取逻辑
2. 加入更多日志
3. 实现decision决策逻辑
4. 实现配置运行时可编排
5. setting调用并行
6. 基于版本号的配置推拉机制
7. 考虑多filter并行处理
基础PipeLine库规划:
1. PipeContext中支持通过配置自编排
2. Pipe支持DSL编排
3. Pipe支持版本化
4. Pipe支持异步逻辑
5. Pipe支持fork-join逻辑
6. Pipe支持背压缓冲机制
插件式开发规划与设计
通过合理的设计,让配置元数据的修改可动态下推到客户端并解释执行,无需修改服务端代码。 通过统一的控制平台管理执行规则,实现 控制平面 + 数据平面 分离。
1. execute client端
springboot插件:
a. rule本地存储(或本地文件等存储):rule存储(记录具体rule规则,rule执行代码),rule agent存储(代理具体信息入端口地址等),rule strategy存储(记录rule执行策略,如是否开启本地执行开关,降级,熔断,重试,指标等)
b. 注册rules 代码编译加载器(启动时,运行时执行)
c. 注册代码执行器 -> 反射执行rules代码
d. 注册rule message(包含rule代码)controller端口,接受信息
e. 启动rule job(比对本地存储版本与最新版本,如果旧了,拉取最新rules并执行编译加载逻辑;如果远程服务不可用,暂停本地执行逻辑,快速报错并开启断路器)
f. 断路器
g. 远程执行代理(根据rule message信息加载远程代理),当选择远程执行时自动远程调用
h. 提供本地rule执行入口方法
2. execute service:
a. 提供rule存储服务
b. 提供安全认证服务
c. 提供rule message发送消息中间件服务
d. 提供rule message发送配置中心推送
3. 通用安全的配置下发协议:
前期可考虑http实现简单
4. msg载体中间件
a. 中转消息