多场景的业务建模系统1.docx

PAGE 1 多场景的业务建模系统 背景 在介绍整套方案之前，一定先要介绍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的同学点个??。 下面说下我们是如何设计业务建模的可视化配置，我们的公共组件，可以在这里添加： 组件的属性配置--这里就Vue的prop配置 :)： 这张图展示我们抽取的业务公共模块，每个模块里面的配置项都是精心设计的： Web应用层 这层主要是基于Nodejs给我们业务建模内部系统提供接口处理，对组件、模块、场景、调度引擎的CRUD操作，一部分配置是存储到数据库，大部分是生成配置文件，提交Aconf模块里面，供FMS解析生成页面。 数据存储层 因为Mongo在公司都自运维的，为了减少风险，我们选择了MySQL，基于sequelize连数据库，因为是内部系统，所以整体表设计都是FE完成，PHP帮