业务系统中最核心的状态设计,异常 case. (系统设计)
技术设计金字塔(人人都是好的软件开发设计师) 包含了状态设计文章
系统设计几方面
1. 具象: 几个角色 -- 用例
2. 具象: 边界模块
3. 具象: 实体模块
4. 抽象: 详细设计后,抽出公用的部分.
5.
Status状态字段的设置和更改
状态设计和业务是紧密挂钩的. 这个中台基本上兼容不了.
系统设计中最核心的是异常设计.
如何?
有哪些异常
1. 通信失败 (本质是不同事务导致的,)
2. 实体失败 (状态校验)
方法论:
1. 确定一个实体生命周的实体交互图. (可以是实体交互图,也可以是时序图) 先抛弃状态检查等.
2. 确定每个流程中的异常问题.
3. 区分. 明确状态 和 中间状态[不明确状态,例如超时状态][ 开锁中, 支付中 ,超时状态] 本质上其实并不需要. 可以查看支付失败的原因,开锁失败的原因.
4. 并发问题. 乘客结束订单,司机抢单成功. 加分布式锁.
5. 保护权衡(分布式事务,抽象总结): 1. 保护资产. ( 先减款,再退钱 ) 2. 保护资产: 等开锁消息回来再结束计费 3. 保护乘客:
举例说明.
评审: 说服别人要明确举出工作中的缺点, 不要直说原则. 业务域就放业务域. 例如业务域不明确,增加一项,或者改变某个逻辑,大家都要改. cos 组合服务太重,
状态设计的需求来源:(主流是来自于自己的主流程 开发都需要 流程引擎思维 https://blog.csdn.net/fei33423/article/details/93892139, 另外补充是不同的角色,同一个角色不同的人 ,例如会议室预订抢占状态,电影票购买抢占状态.)
1. 业务流程.
参考流程引擎的各种流程 . 垫付的流程更复杂, 1.支付 2.垫付 不仅独立而且共存. 但都会触发 分润. [ 各个主体的认知梳理. 乘客,司机 (单流程 key value),客服,财务统计. 各个统计需求真的关注的到底是什么? 原状态流程不变,那么司机要重新对原 status 字段的判断要改. 司机也要改. ]
2. 后台查询诉求
1. 可能全局系统(n 个子系统)的状态, 全流程. 方便 crm 同学查询. 2.将内部系统的 n 个状态聚合成一个状态. ( 已分润也算已支付.)
3. 统计诉求
对状态进行聚合统计. 新增状态要同步. 状态字典 加上 监控 ,对新增的状态进行监控.
代码级别就只能 review 了? 状态转换表. 不同业务场景下.
新增的 type,status 如何保证业务系统健全.
人人都要有https://blog.csdn.net/fei33423/article/details/93892139
状态设计是误区.一定要是状态机设计. 相同状态但流程不同. 状态机是实体和流程的统一.
一定要前置状态校验和其他条件校验.
异常考虑: 另外要关注自动流转的状态,要警惕丢失掉对应的流转流程. (例子,代保养中 大单结束)
几种状态设计.
顺序流程:
1. 单系统 一个字段表征 N 个状态( 含 手动,含自动)
2. 分布式系统. 每个系统各一个字段.对应着生命周期扩展表.
顺序流程:
多个主体操作.
例子. 1. 发单, 乘客取消, 多个司机抢单. 2.tcp 状态机 关闭流程. ack 的和 action 可能组合,
复杂流程:
N 个流程,独立. 有一个成功即走下去.
N 个流程,x 个都成功才能走下去.
N 个流程 x 个成功就能走下去, 但是不妨碍剩下的action 执行.
action 变成了实体, 不再是依附于状态节点. 或者是一个字段来表征也可以.
1. 每个实体都需要有状态
2. 当两个实体不是同时存在的时候,即使1:1也无法用下游实体代替上游实体的状态;
例如 订单行 ad 1:1 先有订单行 后有ad ;
如果只是把 订单行的状态设置在ad上; 那么你无法获取订单行是初始状态的情况( 订单行 left join ad 后 ad.status=null 或者 ad.status=Init 两种情况,这种很难考虑到)
3. 上游的状态是根据上游状态计算出来的,
一个计算技巧就是,当所有下有状态是Audited, 那么上游的Ad是什么状态,利用这个, 再根据 if else的逐位分析法,逐步判断;;
wiz上有详细.
1. status一定要有状态机更改
2. status状态的意义是屏蔽掉复杂业务.
比如说分润状态流转.有些是有三条流水,有些是有四条流水.
