一、引言
最近看一些狙击手题材的电影的时候,发现这些狙击手身边多了有一个角色------观察员。
之前看得一些狙击手都是个人英雄主义,一个人扛着杆枪,又是找地点,又是一埋伏就一动不动的埋伏好几天。
看来可能也是战场形势变化了,狙击手也组织架构升级了。
出于好奇,特意去搜了一下观察员是干嘛的。
一、文字记录,大致就是目标是谁、任务时间之类的。
二、目标区域速写图,画出目标区域景物的相互关系(比例,透视关系等)。
三、射程卡,用若干同心圆标示出不同目标的方向、距离、仰角等,还要标上风速风向,这个是用来计算弹道和偏移的。
四、训练的时候还要写其它的数据资料卡,记录一些详细的参数。
五、观察狙击手的弹着点,确认射击结果。如果一枪未中,需要根据弹着点再次给狙击手建议。
看完这个观察员职责的介绍,突然感觉这个也是一种系统架构升级的思路。
二、结合工作
2.1、工作概述
最近在负责财务域的付款核销组件,给大家简单介绍一下这个组件的功能
付款核销组件会受理一大堆上游系统产生的账款数据,我们会把这些数据抽象成待核销流水,关键字段如下:
待核销流水id |
租户 |
财务结算公司 |
一级供应商 |
二级供应商 |
流水类型 |
计划核销时间 |
核销金额 |
状态 |
a000001 |
HM |
BA5 |
210930 |
23422 |
AP |
20210301 |
6 |
未核销 |
a000032 |
HM |
BA5 |
210930 |
76422 |
ADR_VER |
20210411 |
-10 |
未核销 |
a000052 |
MAOCHAO |
C50 |
213329 |
23425 |
AR |
20210513 |
100 |
已核销 |
a000063 |
TMGJZY |
T64 |
443123 |
75424 |
ARV_AR |
20210622 |
32 |
部分核销 |
2.2、现状问题
一开始,核销逻辑还算简单,每天都会核销,把到期的待核销流水按财务结算公司的维度聚合到一起生成核销单,聚合的过程中按一级供应商、二级供应商的维度汇总生成核销明细。
但是随着接入的产品越来越多,各个产品的个性化需求也越来越多。有的产品要按一级供应商维度生成核销单、有的供应商有固定付款日期,只能在每月的固定几天生成核销单、有的供应商有黑明单控制、有的供应商需按一级供应商维度做倒挂帐控制、有的供应商需按二级供应商维度做倒挂帐控制、有的要求预付、应收类型的待核销流水不能与别的待核销流水核销。
整个核销任务的复杂度慢慢膨胀了,而且组件owner也很难理清楚组件里面有多少能力。单纯的提高狙击手模块的复杂度会越来越难以测试、难以维护,因此我打算做大做强观察员模块的逻辑,为狙击手模块保驾护航。
2.3、解决思路
观察员标记
简单说来就是一个待核销流水受理进来,我的观察员模块会对这个待核销流水做个分析,并对这个待核销流水打标,标记一下这条待核销流水预计会什么时候被核销、预计会被什么样的任务核销。
待核销流水id |
租户 |
财务结算公司 |
一级供应商 |
二级供应商 |
流水类型 |
计划核销时间 |
核销金额 |
状态 |
预计唤起核销日期 |
预计核销的任务 |
实际唤起核销日期 |
实际核销的任务 |
未核销原因 |
未核销编码 |
a000001 |
HM |
BA5 |
210930 |
23422 |
AP |
20210301 |
6 |
未核销 |
20210308 |
20210308AP |
||||
a000032 |
HM |
BA5 |
210930 |
76422 |
ADR_VER |
20210411 |
-10 |
未核销 |
20210511 |
20210511ADR |
||||
a000052 |
MAOCHAO |
C50 |
213329 |
23425 |
AR |
20210513 |
100 |
未核销 |
blackList |
黑明单控制 |
||||
a000063 |
TMGJZY |
T64 |
443123 |
75424 |
ARV_AR |
20210622 |
32 |
未核销 |
20210630 |
20210520ARV |
这样一来,在核销之前我可以通过标记,在数据层面看看我的核销逻辑对不对,方便测试,也方便我在核销之前做一些数据稽核,验证我的逻辑。
比如:HM的ADR_VER类型的流水只能被ADR类型的核销任务核销,我可以写个sql做稽核,where merchant_code='HM' and ledger_type='ADR_VER' and plan_verify_task not like '%ADR%'
狙击手射击
实际核销时,狙击手模块把待核销流水拉出来真正做核销,核销完标记一下实际核销时间、实际任务核销。
待核销流水id |
租户 |
财务结算公司 |
一级供应商 |
二级供应商 |
流水类型 |
计划核销时间 |
核销金额 |
状态 |
预计唤起核销日期 |
预计核销的任务 |
实际唤起核销日期 |
实际核销的任务 |
未核销原因 |
未核销编码 |
a000001 |
HM |
BA5 |
210930 |
23422 |
AP |
20210301 |
6 |
已核销 |
20210308 |
20210308AP |
20210401 |
20210401AP |
freese |
供应商冻结 |
a000032 |
HM |
BA5 |
210930 |
76422 |
ADR_VER |
20210411 |
-10 |
已核销 |
20210511 |
20210511ADR |
20210511 |
20210511ADR |
||
a000052 |
MAOCHAO |
C50 |
213329 |
23425 |
AR |
20210513 |
100 |
已核销 |
20210511 |
20210511ADR |
blackList |
黑明单控制 |
||
a000063 |
TMGJZY |
T64 |
443123 |
75424 |
ARV_AR |
20210622 |
32 |
未核销 |
20210630 |
20210520ARV |
观察员确认结果
核销之后,我可以观察实际核销日期跟核销任务是否与我标记的一致,这样可以校验一下我的狙击手模块的逻辑是否正确,确实应该不一致的也可以把数据捞出来人工在看一下,做到心中有数。
捞出不一致情况如下:
待核销流水id |
租户 |
财务结算公司 |
一级供应商 |
二级供应商 |
流水类型 |
计划核销时间 |
核销金额 |
状态 |
预计唤起核销日期 |
预计核销的任务 |
实际唤起核销日期 |
实际核销的任务 |
未核销原因 |
未核销编码 |
a000001 |
HM |
BA5 |
210930 |
23422 |
AP |
20210301 |
6 |
已核销 |
20210308 |
20210308AP |
20210401 |
20210401AP |
freese |
供应商冻结 |
a000052 |
MAOCHAO |
C50 |
213329 |
23425 |
AR |
20210513 |
100 |
已核销 |
20210511 |
20210511ADR |
blackList |
黑明单控制 |
架构规划
最后的趋势是观察员模块的逻辑越来越丰富,狙击手可以适当的将一些逻辑放在观察员模块,降低自身的复杂性。同时提高组件整体的可靠性、可测试行、数据标签丰富,方便更多维度的稽核,可以光看数据就对整个组件做到心中有数。
三、总结
引入观察者模块,其实就是在核心模型上打上完整的标,代码里面有的逻辑概念,核心模型是有相应的标与之对应。这样别的相关同学能单纯的通过看数据、稽核数据,来了解你的核心逻辑,知道你代码逻辑写的对不对,而不是去一行行的撸代码。
标越丰富,稽核越精准,稽核的粒度越细腻,同时也能反哺保障代码更稳定,bug快速发现,可维护性更强。
打王者荣耀的时候都经历过这样的阶段
青铜级:
选个自己喜欢的英雄,完全靠个人能力,全地图游走。个人能力够强就打的够爽。
王者级:
大家技术都比较高,战场复杂,容错率比较低的时候,必须得跟辅助配合,辅助标记打谁就打谁。得定点标记,精准打击,不然容易一套输出打完,一个敌人没死。
所以系统也一样,越来越复杂之后,得有个观察者模块,提高系统的可视性,可稽核性。让狙击手模块能安心的精准打击,同时观察者模块越来越完善之后,可以分担一下狙击手模块的复杂性。