首页 » 漏洞 » 多场景业务建模系统

多场景业务建模系统

 

背景

在介绍整套方案之前,一定先要介绍ED目前是从事的是互联网金融开发,因为我们的整套方案设计,确实跟行业属性有密切的关系,这套方案大概已经积累了1年多了,在日常开发过程中我们的业务有如下特点:

  • 首先每个月几乎都有新场景的开发工作

  • 新场景中有60%的需求是一样的,也有40%是不太一样的

  • 我们的产品大致分为申请、激活、放款、还款4大流程,每个流程都是给不同的后端提供数据

核心问题如下:一切皆是差异化

  • 交互视觉的差异化:每个场景在设计上总是一些不太相同的地方

  • 产品流程 的差异化 :PM有时候会在某些页面上添加一些额外的展示位

  • 风险控制 的差异化 :这里多阐述下,金融放贷的核心就是风控,做过金融开发的同学肯定知道,每个场景需要收集用户哪些信息,都是由风控来决定的,对于FE最后表现出来的就是视觉和交互上的差异,对于PHP就是每个场景收集字段的差异,这也是我们整套设计方案重点之一

  • 第三方机构 的差异化 :每个机构输出的信息不一致,由于技术体系不在FE的范畴,本文不介绍

我们的目的:提升开发效率的同时提升我们金融产品管理能力

整体架构设计

去年做了半年的组件化方案,今年其实一直在做平台一体化的工作,先抛出咱整体的架构,后面会每个模块详细阐述下,我们的业务主要分成B端和C端,B端是可视化的生成差异化配置,这个配置文件最终会放在Aconf模块里面,C端基于Aconf配置文件,组件化或者模块化生成页面,整体的思路大概是这样子

多场景业务建模系统 这个背景颜色的目前都是FE的工作(实在不知道这个颜色怎么描述)

多场景业务建模系统

C端

web前端层

任何新成立的项目组,FE需要做的第一件事情应该都是组件化 ,下面这个图应该会比较清晰的介绍我们工作

多场景业务建模系统

web应用层

去年因为业务初期,整体项目压力非常大,而且对于金融这种高风险业务,线上是不能有任何损失的,所以当时我们的后端一直是php

今年我们为什么迁移node

  • 首要的 前提就是公司目前在node框架、线上运维、机房容灾等这块支持非常好

  • FE能更熟悉业务,更好的优化业务:其实很多B端相关的配置工作其实都是FE自己的,但是却需要php在后端支持下,这块不管事对php还是fe都非常的不好

  • 节省整体的人力:对于一个新场景的开发,原来需要1FE+1PHP,现在只需要1FE+0.5PHP

  • 减少FE和PHP的沟通成本:原来因为相互耦合更重,自然沟通成本更高,现在有了公共服务,相当于依赖更加松散了,沟通成本自然会下降

下面说下,我们创新的几个核心关键点

多场景业务建模系统

我们将一个新场景的工作分成了公共业务和场景业务,公共业务统一都由FMS来处理,对于个性化的业务都由不同的scene来处理

FMS

FMS模块里面包含了所有的公共业务,其中有几个关键点:

  • 多版本控制:这样可以保证公共业务的上线修改,不需要所有场景都统一回归

  • 基于配置生成页面,一切差异化都体现在配置里面(讲B端的时候会展示配置的可视化页面)

    • 组件化:对于表单填写类的页面,我们都是组件化配置生成页面,这样可以更加灵活

    • 模块化:对于业务需求比较标准的页面,我们就以模块化配置生成页面,这样更加方便可视化配置,比如富文本编辑类似的配置,这个最好还是模块化生成

AXE

Axe是我们积累下来的公共方法:包括了passport处理、工具方法、action基类、rpc请求封装、统一的错误码定义、mock数据等

SCENE

SCENE代表了我们所有的场景,场景也是基于axe公共模块和php的公共微服务 开发

web服务层

因为这里主要是php的工作,就大概说下,这层是一个公共的微服务,根据我们的业务需求做了梳理划分,这里面比较取巧的是,我们将场景的服务放到了公共服务里,后续也就没有了场景php的概念,不用每次开发新场景的时候,都需要场景php去拉一个新的模块,这样可以更加集中所有php的力量做技术优化

B端

web前端层

这套方案 我们能这么搞,一切的核心都源于:我们有一套基于json-schema配置快速生成页面的系统(公司内部系统Amis),比任何组件化方案都快要快都要好,随时改随时生效,先给FEX的同学点个:+1:

多场景业务建模系统

下面说下我们是如何设计业务建模的可视化配置, 我们的公共组件,可以在这里添加

多场景业务建模系统

组件的属性配置--这里就是vue的prop配置:)

多场景业务建模系统

这张图展示我们抽取的业务公共模块,每个模块里面的配置项都是精心设计的

多场景业务建模系统

web应用层

这层主要是基于nodejs给我们业务建模内部系统提供接口处理,对组件、模块、场景、调度引擎的CRUD操作,一部分配置是存储到数据库,大部分是生成配置文件,提交Aconf模块里面,供FMS解析生成页面

数据存储层

因为mongo在公司都自运维的,为了减少风险,我们选择了mysql,基于sequelize连数据库,因为是内部系统,所以整体表设计都是FE完成,php帮忙review

今天主要介绍了我们的整体架构和部分开发流程,对于很多技术细节可能都没覆盖到,想了解更多的同学,可以微信发消息联系我~~

原文链接:多场景业务建模系统,转载请注明来源!

0