开发痛点
先来张图看下吧。
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. 中转消息
