saas 技术架构 saas平台技术搭建思路

一、To B 的难点

解决方案需要实现的目标：

• 灵活定制：前后端都提供灵活的二开机制，前端提供搭积木的自由组装的能力；后端提供灵活的功能扩展能力
• 快速交付：尽快产出原型（方便复用）、尽快交付产品（积木式、配置化地组合业务，基于基线能力快速地扩展和定制能力）
• 提高生产率：提供功能完整的应用开发平台
• WORA：Write Once，Run Anywhere，前端一套代码能够在 PC、Mobile、小程序运行
• Hotpatch：小程序化成为 hotpatch 的主流选择
• 运行时态可配置：提供线上前后端的配置平台，实时生效
• 学习成本低：可视化开发平台；完备的文档、Demo、视频；

存在很多差异和问题：

• ISV、SI 和客户自己的实现难以保证效果；
• 标准产品与定制开发要筑起栅栏，实施二开不能泄露核心代码；
• 开发完成的前后端组件，需要结构化沉淀成为可复用的二方库；
• 前后端组件往往无法直接复用，特别是业务级别组件；
• 产品化的程度、产品说明文档的完善和易用；
• 开发一个产品的方法论、流程和平台；

解决难点要考虑的方面：

• 首先说前端，前端架构由传统的 Page+Route，改为 Component+Route，Page 变为纯粹的容器，这样带来的巨大好处是，UI 组件与 Page 解耦，使得 UI 组件成为类似于微服务一样的独立实体，这样，UI 组件就可以脱离 Page 实现任意的组合，这就是“积木式”，同时，UI 组件，可以提供 Setter 扩展方式来增强组件功能、展示、甚至绑定不同的后端 API，实现二开；
• 再来说后端，将基础能力和业务定制能力分层，两者提供不同的注解（@Domain 代表领域基本业务，@Business 代表领域定制业务），行业定制基于基础能力所暴露的 SPI 进行定制开发，在不修改基础能力代码的前提下，实现功能的定制，基础能力和业务定制能力都支持通过 SPI 来定义服务的扩展点；数据层面，通过定义数据视图，对不同元数据进行聚类、组合，以实现运算的目的，同时能够以不同的形式对后端数据进行展现。

二、应用开发平台的架构设计

 

总体架构：

研发过程管理平台的架构设计方案

前端业务组件拼装的架构设计方案

后端开放性架构设计方案

三、应用开发平台设计思路

3.1 前端的开放性设计

前端的开放性设计涉及到 4 个维度：业务组件、沉淀与复用、业务流、组件的扩展。

• 组件业务化及跨平台化：业务组件，如前面所述，是能够触发或完成一个业务动作、与后端能力连接的业务组件，⽽⾮交互 / 基础组件。
• 沉淀与复用：迭代或新应用开发时，根据业务需求，可以到业务组件仓库中寻找。当业务组件开发完成，通过在 CICD 平台配置脚本，同时沉淀业务组件的 NPM 包。
• 业务流：页面组是⼀种⽅式，将⼏个高度相关的页面做成⼀个页面组，彼此通过相对 url 串联
• 组件的扩展：组件自定义出口（行为和参数），将出口行为和出口目标分离。建立一种串联机制，可以动态地定义业务组件之间的关系。

3.2后端的开放性设计

•   架构和流程：

•    SPI：后端服务的提供者来定义，通过定义 SPI 对外暴露各类可定制点，利用 java 的多态性，针对不同的业务场景定制不同的 Impl。
•    元数据：元数据提供 @Entity 注解来申明定义，参数存储上支持字段扩展，采用属性值表设计。并直接生成 SPI 及对应 SPI 的实现代码。
•    视图：后端平台侧提供视图建模功能，可以自由搜索元数据，选择需要的字段，组合成新的视图。开发人员需要给出元数据字段到视图字段的 mapping 关系，以及指定视图的 id 作为唯一标识，并进行发布。

3.3前后端的衔接设计

• 基本流程：数据对象 DO->SPI->API->展现视图 VO->组件 ->UI，前端业务组件直接与后端 SPI 及数据对象进行映射。
• 前端拼装： 提供编辑器，支持绝对布局和相对布局，可以由 VO 直接生成业务组件，拖动形式拼装成组件，并绑定后端 API。
• 后端能力：在 Business 和 Domain 都支持通过 SPI 来定义服务的扩展点，ISV 和 SI 可以在不修改原有逻辑的基础上，通过替换 SPI 来实现功能的替换、升级和扩展。
• 数据层面：通过将前端组件与后端 SPI 及数据对象进行映射，通过定义数据视图，能够根据业务诉求，对不同元数据进行聚类、组合。