what
面对“单据种类多、状态机制多、状态间存在时效差异、时效监控缺失或各自实现”这样的背景，需要一个统一的解决方案，我称其为单据时效监控系统。
简述为“从单据类型，单据状态，监控时间等维度构建数据模型，根据状态机制与时效规则，对单据履行过程进行监控、报警、补偿处理等”。
意义：支持各种单据，提供时效监控和报警、补偿接口回调，规则可配置。
第一阶段：业务间关系
第二阶段：系统内部组件关系
可以将系统分为三个组件模块，本别为：数据获取模块、监控引擎模块、结果处理模块。
思考内容：
状态机制与时效
- 任何单据的履约过程均可通过多个状态的线性关系进行体现，即为状态机制。
- 状态机制各不相同，依赖具体业务。
- 状态A转移到下一状态B之间的时间要求，即为状态间时效。
- 时效各不相同，依赖单据类型，具体状态，业务要求等
- 节点分类
- 正常状态节点
- 即单据履约过程一切顺利的情况下，出现的节点
- 异常状态节点
- 即单据履约过程不顺利的情况下，出现的分支节点，但之后会到达正常节点。
- 由于这些节点，在业务方的流程中可能已经存在报警，所以配置该节点可选择忽略报警，避免报警重复。
数据来源模块
原始数据来源
- 推，业务方主动调用系统提供的RPC/restful接口。
- 拉，由系统定义接口规范，业务方按照规范提供接口，由系统调用以获取单据基本信息。
- 对业务方：无侵入，无推失败影响。
单据当前状态
- 需要业务方提供接口
监控模块
监控引擎，提供统一的流程，具有根据不同状态机制进行监控的能力。
外部验证模块
调用业务方接口，让其进行当前状态的其他验证并返回true/false，例如多系统间状态是否同步
报警模块
- 根据状态机报警配置，进行报警处理。
- 报警限制优先级：不允许报警时间>报警积累阀值
- 提供多种报警方式。如：短信，邮件，IM
- 报警频率控制
回调补偿处理模块
- 方便业务方控制异常节点
- 根据状态机的回调处理配置，进行回调处理。
- 例如：调用业务方配置的rpc/restful接口
页面功能模块
- 单据类型申请
- 配置页面
第三阶段
构建数据模型 ，绘制时序图、流程图。
如下为主要模块的流程图
以拉方式获取数据的流程：
监控引擎的流程：
结果处理组件的流程：
总结
单据履约监控系统，是一个业务无关的系统，而且对业务方几乎没有侵入性。
后续我看普罗米修斯文档时，发现与其设计思路很相似。
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
