孙玄:大中台模式下如何构建复杂业务核心状态机组件

孙玄:大中台模式下如何构建复杂业务核心状态机组件

  • 1、有限状态机
  • 2、Spring StateMachine
    • 2.1 依赖 pom
    • 2.2 创建状态机
    • 2.3 注解监听器
    • 2.4 运行状态机
  • 3、交易中台
    • 3.1 个性化 FSM 抽象
    • 3.2 中台赋能业务
  • 4、总结

孙玄:毕业于浙江大学,现任转转公司首席架构师,技术委员会主席,大中后台技术负责人(交易平台、基础服务、智能客服、基础架构、智能运维、数据库、安全、IT 等方向);前58集团技术委员会主席,高级系统架构师;前百度资深研发工程师;


【架构之美】微信公众号作者;擅长系统架构设计,大数据,运维、机器学习等技术领域;代表公司多次在业界顶级技术大会 CIO 峰会、Artificial、Intelligence、Conference、A2M、QCon、ArchSummit、SACC、SDCC、CCTC、DTCC、Top100、Strata +、Hadoop World、WOT、GITC、GIAC、TID等发表演讲,并为《程序员》杂志撰稿 2 篇。

大中台战略下,中台将公司业务的公共能力下沉,并采用更加合理、可复用的架构和技术来实现这些基础能力。在电商行业内,将面临货物的采购、商品上架、交易发生、订单状态变化、客服介入等大量状态维护。每个状态之间具有很强的逻辑关联关系,比如:退款操作在发货前和发货后将是完全不同的流程,如图 1 订单退款流程

孙玄:大中台模式下如何构建复杂业务核心状态机组件_第1张图片
由此可见,对于复杂状态的管理是一个业务依赖,需求多变的场景。在公司初创期,可以采用硬编码方式,对于每一个操作进行状态判断,每一步操作定制一套逻辑链路。随着业务的增加,定制化链路显然不优雅,大量流程代码无法维护,此时中台通用解决思路就尤为重要,有限状态机(Finite State Machine,缩写:FSM)开始在中台落地。

1、有限状态机

有限状态机(以下简称 FSM)又称有限状态自动机,简称状态机。维基百科定义是表示有限个状态以及在这些状态之间的转移和动作等行为的数学模型。

这个模型和业务中台遇到的问题十分吻合。图 1 是状态转移图,可以用来表示状态机,此外可以使用状态转移表来表示。如图 2 所示:

孙玄:大中台模式下如何构建复杂业务核心状态机组件_第2张图片
可以看出,FSM 是通过抽象为动作和状态,管理有限个状态转移的模型。动作是在给定时刻要进行的活动的描述,我们总结动作类型有如下:

进入动作:在进入状态时进行

退出动作:在退出状态时进行

输入动作:依赖于当前状态和输入条件进行

转移动作:在进行特定转移时进行

在 FSM 框架下,将流水线的状态流转流程进行了抽象和结构化,将复杂的状态转移图,分割成相邻状态的最小单元。这样相当于搭建了乐高积木,在这套机制上可以组合成复杂的状态转移图。

2、Spring StateMachine

Spring Statemachine 框架主要是帮助开发者简化状态机的开发过程,让状态机结构更加层次化,我们来看下 Spring SM 怎么实现。首先最小的乐高模型如图 3 所示 :

孙玄:大中台模式下如何构建复杂业务核心状态机组件_第3张图片
假如有状态 STATE1、STATE2 和事件 EVENT1、EVENT2。事件驱动状态流转。下面来分析下 Spring SM 的主要代码。

2.1 依赖 pom


    
        org.springframework.statemachine
        spring-statemachine-core
        2.1.3.RELEASE
    

2.2 创建状态机

通过注解来注册状态机的三要素:source、target、event

孙玄:大中台模式下如何构建复杂业务核心状态机组件_第4张图片

2.3 注解监听器

通过监听器感知事件发生,并相应的处理相关逻辑。

孙玄:大中台模式下如何构建复杂业务核心状态机组件_第5张图片

2.4 运行状态机

孙玄:大中台模式下如何构建复杂业务核心状态机组件_第6张图片

3、交易中台

在交易场景,定义了自己的状态机框架,抽象了符合交易场景的状态角色:

初始状态、目标状态:状态关系

角色:不同角色有不同的操作权限,比如卖家、买家、系统、客服

操作:对应事件

handler:事件操作相应的action实现

因此一个事件我们可以定义为:在角色 A,在初始状态 S1 下,执行 OP1 操作,将使用 handler 来处理,执行成功将状态设置为目标状态 S2。

3.1 个性化 FSM 抽象

鉴于交易的个性化需要,扩展了状态表的条件,同时使用 handler 和 Java 反射,来对逻辑代码进一步结构化。到这一步后,我们可以将数据模板存储到数据库中。如图 4:

图4 交易中台FSM状态表
通过改造,核心代码 FSM 执行引擎只有不到 100 行。通过注册业务 handler,可以灵活的扩充业务能力。同时数据状态的维护是通过状态表,而不依赖手动编写代码,这对于代码质量的保证、工程回归测试都节省了大量的时间。也为中台实现配置化做好了铺垫。

3.2 中台赋能业务

中台沉淀了基础能力,如何实现?中台如何赋能业务的,业务是否满意呢?

看下面一个例子,基于交易,C2C、自营是两个具有极大区别的业务,他们有完全不同的两套业务流程。C2C 平台需要对买卖两端进行担保,而自营更多的是给予买家保证权益。简化版流程,如图 5:

孙玄:大中台模式下如何构建复杂业务核心状态机组件_第7张图片
通过中台 FSM 能力,我们只要能将状态图绘制出来,那么相应的状态流转表配置也已经产生。handler 只需要关注当前操作的业务逻辑,极大的解耦了状态和业务。

可以毫不夸张的说,一个新业务过来,中台能在 2 天时间内单人完成状态机配置开发上线。这就是中台的效率

4、总结

FSM 解决复杂业务状态流转的问题,并以交易业务进行举例。但是 FSM 的应用场景远多于交易。比如客服工单,商品状态等。但不是所有的流程都需要使用FSM,需要做好业务流程的折中,就像中台战略更适用于10-100 阶段的公司一样。

同时 FSM 只是一个框架,还需要搭建一整套基于它的外围业务逻辑。在状态流转过程中,业务逻辑才是我们的肌肉。框架就像骨骼约束着我们,从而让技术成长更加健康,这也许就是中台的魅力。

参考: https://projects.spring.io/spring-statemachine/.

关注【架构之美】,与孙玄老师探讨更多深层次架构知识

孙玄:大中台模式下如何构建复杂业务核心状态机组件_第8张图片

你可能感兴趣的:(大中台,孙玄,架构师,Java,状态机,百万年薪架构)