多场景业务建模系统

                                             多场景业务建模系统

背景

在介绍整套方案之前，一定先要介绍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的同学点个