西南证券：基于微前端架构的综合业务管理系统

获奖单位：西南证券
获奖项目：基于微前端架构的综合业务管理系统
来源：2023鑫智奖第四届中小金融机构数智化转型优秀案例评选

在“2023鑫智奖第四届中小金融机构数智化转型优秀案例评选”活动中，共93家金融机构提交了208个相关案例，西南证券“基于微前端架构的综合业务管理系统”项目得到评审专家的一致好评，获得了“专家好评TOP10优秀案例奖”。

一、项目背景及目标

随着业务地快速发展，系统复杂度日渐攀升。后台系统通过微服务的架构设计在稳定性、并发量、可扩展性方面实现了飞跃式的提升。而传统Web前端项目一般采用单体架构，随着时间的推移，项目往往也会越来越庞大、臃肿，从而面临以下困境：

1.项目功能逐渐增多，代码规模日渐庞大，维护成本陡增；

2.扩展变得愈发困难，牵一发动全身，系统变更风险增大；

3.项目必须采用同一种技术框架开发，无法支持不同技术栈的团队协同作业，同时也不支持技术框架的渐进式升级，若面临技术框架的淘汰更替，只能整体迁移，改造风险大；

4.项目集中在一个代码仓库中管理，负责不同业务模块开发的团队提交的代码极易出现冲突，导致开发效率降低，团队协作难度增加；

5.应用体积越来越大，构建时间成比例上升，应用访问速度愈发缓慢，交互响应变迟钝，用户体验糟糕。

为解决以上问题，团队深入调研了微前端技术方案。微前端架构模式通过将庞大的Web单体应用拆分为多个小型前端应用，实现不同业务功能在项目结构、部署环境上的解耦，并通过微前端框架提供的集成机制，又将拆分的微应用聚合为一体，各个微应用可以独立运行、独立开发、独立部署。在微前端的架构中，每个业务模块都是一个独立的子应用，但它们之间又可以相互通信。子应用完全可以采取不同的框架进行开发，这样可以实现更加灵活、高效、可维护的前端应用。

微前端技术方案可以改善Web前端应用的用户体验、提高开发人员的开发效率、支持项目快速迭代、及时响应业务需求、更好地支撑证券公司在数字化转型过程中的快速发展，助力公司更好地适应移动互联网时代的发展趋势。

二、创新点

1.分布式应用

微前端技术将一个庞大的前端应用拆分成多个独立灵活的小型应用，不同的业务分属不同的子应用，每个应用都可以独立开发、独立运行、独立部署。基于微前端的架构，多个项目既可以融合为一，又可以减少项目之间的耦合，极大地提升了项目扩展性。相较于将所有功能集成为一体的项目，微前端架构更轻量、更灵活、更易于维护。

2.跨团队协作

子应用独立开发、独立运行、独立部署，为跨团队或跨部门协作开发带来了便利性。不同的子应用可以由不同的团队独立开发，代码仓库互相隔离、互不影响，降低了团队协作的沟通成本、减少代码冲突，提升并行开发效率。

3.生成式应用框架

利用项目脚手架框架，一键生成应用框架、导入公共依赖，统一应用兼容性、性能优化处理方案。开发人员只专注业务功能开发，提高开发效率，保证项目质量。

4.开发运维流程化

利用持续集成工具，微前端的主应用和子应用都可以一键完成拉取分支代码、打包编译、发布测试、部署生产等环节，规范了开发流程，保障了系统的稳定性。

三、项目技术方案

1.技术架构

综合业务管理系统采用微前端的基本框架，设计为三层次的系统架构，同时各个层次的组件可以根据实际需要灵活配置和部署。整体架构如图1所示：

1）基础框架层：主要为上层应用提供运行框架、公共服务和UI组件，这些组件经过抽象、封装后，提供了高度的复用性，降低了应用开发的成本。

2）业务应用层：该层分为微前端的主应用和子应用，主应用（Master Application）是整个项目的基座，负责应用的生命周期、路由分发、子应用注册和调度管理。子应用（Micro Application）为具体的业务承载应用，作为主应用的一个子模块独立运行。

3）发布运维层：实现项目的构建和环境发布。其中脚手架工具覆盖了从应用创建、代码规范检查、编译调试、打包优化、适配发布环境、兼容性处理、响应式布局等技术环节，是保障所有应用具备一致、良好质量的重要工具。持续集成方案为系统提供了自动化地构建发布流程，实现应用从开发到上线的全流程管理。

图 1. 基于微前端架构的综合业务管理系统的三层架构体系

2.技术实施方案

综合业务管理系统从微前端改造、前端脚手架赋能、持续集成接入三个方面设计了整体的技术实施方案。主要采用社区中成熟的开源框架，持续改进信息技术架构。

2.1 微前端改造

微前端的实现方式有多种，其中比较常见的方式是通过 iframe、Web Components 或者 JavaScript 模块加载器来实现子应用的隔离和独立运行。通过这些方式，不同的子应用之间可以互相独立、互相通信，从而实现一个完整的前端应用程序。为了更好实现对技术架构的自主掌控、提高开发效率，在微前端框架的选取上，主要遵从三个原则：

1）成熟度。一线大厂支持的开源框架、技术都在实践中经历过较长时间地打磨，不管从框架成熟度、迭代频率、应用稳定性、技术支持上都有比较好的表现。近几年国内的厂商逐渐开始拥抱开源，其开源产品更加适合国内的互联网生态。

2）社区活跃度。社区活跃度越高，解决问题的速度越快，框架也逐渐完善。当出现问题时，能够快速在社区找到相应的答案。

3）技术需求。目前不少开源框架的应用场景类似，具体的选型，需要根据业务场景的需求做筛选。一般会从浏览器兼容性、开发复杂程度、框架体积、接入成本几方面做考虑。

目前主流的微前端框架有single-spa、MicroApp和qiankun。single-spa是通过监听url change事件，在路由变化时匹配到渲染的子应用并进行渲染，这个思路也是目前实现微前端的主流方式。同时single-spa要求子应用修改渲染逻辑并暴露出三个方法：bootstrap、mount、unmount，分别对应初始化、渲染和卸载，这也导致子应用需要对入口文件进行修改。

MicroApp并没有沿袭single-spa的思路，而是借鉴了 WebComponents的思想，通过CustomElement结合自定义的 ShadowDom，将微前端封装成一个类WebComponents组件，从而实现微前端的组件化渲染，但micro-app依赖于CustomElements和Proxy两个较新的API，IE等老的浏览器无法运行micro-app。

qiankun是蚂蚁金服开源的一款框架，旨在帮助开发者能更简单地构建一个生产可用的微前端架构系统。其基于single-spa进行了二次开发，实现了开箱即用。子项目只需要做很少的改动，就能接入框架，且兼容IE等老的浏览器。

最终qiankun被确定作为综合业务管理系统的微前端架构方案，主要原因有以下几点：

1）综合业务管理系统中承载的业务功能有依赖于IE浏览器的情况，而qiankun对IE的支持更好。

2）qiankun社区的活跃度相较其它几款框架更高，更容易找到解决问题的方案。

3）qiankun框架已在蚂蚁内部服务了超过2000+线上应用，在易用性及完备性上，具有优势。

综合业务管理系统的微前端架构是基于开源qiankun框架搭建的，系统整体架构如图2所示：

图 2.微前端架构的流程

综合业务管理系统的架构主要特点包括：

完备的生命周期管理：微前端架构具有完备的子应用生命周期管理方案，可以自动加载、启动、挂载、卸载和卸载子应用。

灵活的应用路由分发：微前端架构具有灵活的路由分发方案，可以自定义路由匹配规则，通过主应用的路由来匹配子应用的路由，在加载子应用时直接进入子应用的某页面。

独立的应用状态管理：微前端架构具有独立的状态管理方案，每个子应用都可以独立管理自己的状态，主应用可以通过 props 方式传递数据给子应用，也可以通过事件总线的方式进行通信。

系统运行流程包括：

1）创建主应用：主应用负责整个应用的框架搭建、路由分发和子应用的注册和协调管理。可以使用任何前端框架进行开发，例如 React、Vue、Angular 等。

2）创建子应用：子应用是独立开发的前端应用程序，可以独立运行，也可以作为主应用的一个子模块运行。每个子应用都可以使用任何前端框架进行开发，例如 React、Vue、Angular 等。

3）注册子应用：主应用需要在启动时注册所有的子应用。注册时需要指定子应用的名称、访问地址、加载方式和路由配置等信息。

4）启动子应用：主应用在启动时会自动加载和启动所有的子应用，每个子应用会根据配置的访问地址自动加载。

5）协调子应用：主应用需要协调管理所有的子应用，包括子应用的加载、启动、挂载、卸载和卸载等操作。主应用可以通过 props 方式传递数据给子应用，也可以通过事件总线的方式进行通信。

6）卸载子应用：当子应用不再需要时，主应用可以卸载子应用并释放资源，以提高系统的性能和稳定性。

2.2 项目脚手架赋能

前端应用由于使用者环境的多样性、复杂性，长期以来面临着网络质量、兼容性问题的考验。为了保证项目质量、提升客户体验，开发者往往会对应用做大量的兼容性、性能优化方面的处理。当将一个大型应用拆分为多个独立微应用后，如何统一应用这些处理方案；以及微应用的基础项目框架、微应用间的通信机制等公共能力、异常行为监控埋点等如何一致地应用于众多独立应用成为了一个必须要解决的架构问题。在不同项目间复制代码的形式会随着微应用的增多，越来越难以保证一致性。为此系统设计了项目脚手架+公共库的方案来自动注入以上能力。设计方案如图3所示：

图 3. 项目脚手架+公共库方案

在设计方案中，前端开发团队将应用所需的通用处理流程、公共服务能力进行了细腻度的划分，并以插件的形式提供按需使用的能力，应用通过脚手架引擎来调度插件的安装和执行。

由于插件可提供配置式的方式来控制执行过程，且新建项目时往往会需要安装多个插件，给创建过程增加了复杂度。为此增设了配置集机制，在代码仓库中预置了常用的几种配置，将相关的插件及配置按照一定的顺序做了编排。

通过以上的设计，整个框架实现了以下能力：

1）一行命令创建微应用项目框架、集成公共依赖、注入构建命令。

2）一行命令构建应用发布包，应用普适性的兼容性、性能优化处理方案。

3）一行命令统一调整公共服务的变更。只需更新插件即可统一应用最新的方案。

2.3 持续集成/持续部署

持续集成(Continuous Integration，CI)过程的目标是提交的代码能持续构建为二进制文件或构建产物。而持续部署 CD（Continuous Deployment）是将代码与基础设施相结合的过程。

在传统的研发流程中，一般是手动进行项目的编译打包、代码检查、生产部署。通过工具自动化后，则可大幅提高项目的构建、发布效率。本项目采用了比较成熟的、主流的CI/CD框架Jenkins来搭建Web前端的CI/CD自动化流程，开发者通常只需要点击一下鼠标，就可将软件部署到开发、测试或生产环境。引入自动化流程后，应用的研发过程的改进为如图4所示的步骤：

图 4. 持续集成流程

1）依据用户反馈、业务需求、生产问题形成的待开发需求。

2）由产品经理、开发人员、测试人员共同进行需求分析，形成需求文档。

3）开发人员进行协作开发，当推送代码到代码仓库时，配合项目脚手架的代码检测插件，自动执行静态代码分析检查。完成后提交开发分支到提测分支的合并请求。技术管理人员完成代码逻辑审查后，执行合并提测的操作。

4）代码仓库通过webhook通知Jenkins测试分支有更新，Jenkins会从代码库下拉最新代码，并根据配置的参数来区分不同的构建环境（测试、仿真、生产环境），不同的构建环境加载相应的配置文件和打包命令。Jenkins会使用打包命令构建出发布包，发布到对应环境的服务器上。

5）测试方会对提测代码进行安全漏洞扫描、功能测试和不同机型（浏览器）下的兼容性测试。

6）测试完成后，通过Jenkins进行生产部署。

四、项目过程管理

1.需求分析和技术调研阶段

此阶段时间段为2021年12月至2022年2月，其间主要完成了需求收集、问题分析，并针对问题和需求，进行了相应的技术框架调研。

2.设计阶段

此阶段时间段为2022年3月至2022年4月，其间主要完成了微前端框架改造设计、公共库和UI组件抽离设计、打包编译和部署流程设计。

3.开发阶段

此阶段时间段为2022年5月至2022年11月，其间主要完成了微前端框架改造的开发、测试和部署的工作。以及前端脚手架和持续集成工具链的搭建。

4.主应用上线阶段

此阶段时间段为2022年12月至2022年12月，其间主要完成了综合业务管理系统的主应用（基座应用）的上线，并持续监控主应用的运行情况，为后续的子应用上线打下基础。

5.子应用分阶段上线

此阶段时间段为2023年1月至2023年4月，其间首先完成了综合业务管理系统的子应用——用户与角色管理系统的上线，在其运行稳定的情况下，依次上线了子应用资管业务系统、子应用理财运营业务系统、子应用转融通与大宗交易意向业务系统、子应用两融期权开户审核系统的上线，并持续监控各个系统的运行情况。

6.运行阶段

此阶段时间段为2023年4月至今，其间业务系统稳定运行，各项线上业务有序开展，项目如期完成。后续计划在2023年7月上线子应用网上营业厅业务系统、2023年10月上线子应用开户审核业务系统。

五、运营情况

基于微前端的综合业务管理系统（包括资管业务、理财运营业务、转融通与大宗交易意向业务、两融期权开户审核系统）于2023年4月上线。从系统上线以来运行情况来看，各项线上业务有序开展，系统运行稳定，已达到原来的设计目标。同时极大的提高了需求响应速度，持续进行快速的版本迭代，进一步优化了业务流程，提升了用户体验。

1.系统各组件运行情况

综合业务管理提供的资管业务系统，支撑了现金管理产品-双喜增利的顺利发行和持续运作，有效支撑了公司现金管理业务的开展。

综合业务管理提供的理财运营业务，包括了业绩报酬展示配置、分支机构产品锁定配置、金融商城运营位和运营产品配置等业务，有效支撑了财富管理业务的开展。

综合业务管理提供的转融通与大宗交易意向业务系统，包括了转融通与大宗交易权限的开通、转融通与大宗交易意向行情查看、转融通与大宗交易竞价询价委托、转融通与大宗交易委托查询、机构评级反馈等业务，有效支撑了转融通与大宗交易意向业务的开展，提高了转融通与大宗交易的撮合成交效率。

六、项目成效

1.提高开发效率

基于微前端架构的应用，每个业务模块都可以以子应用的形式独立开发、独立运行、独立部署，极大地降低了前端开发的复杂度和耦合性。能够提高开发效率和应用质量，缩短业务功能上线时间，公司能够越快地通过线上推出新业务或改善用户服务质量，随着客户满意度地提高，创造的业务价值和经济价值也随之增加。此外，开发效率的提升，直接提升了开发人员的人均产出，在同等的人力成本和时间成本下，为公司贡献了更多的产出物，创造了更多的价值。

2.降低事故

大型单体应用解耦为独立业务子应用后，单个业务应用的系统变更影响仅仅局限于自身应用的范围，不会影响到整体系统的其它业务模块。该特性大大提高了系统的稳定性，降低生产事故的发生概率，当某个子应用出现事故时，用户还是可以正常使用其它业务功能。降低了事故带来的损失。

七、经验总结

在技术选型阶段，采取积极调研、拥抱开源的策略。通过结合公司数字化转型规划、业务实际需求和现有架构情况进行综合分析，确定了微前端的技术架构方案。围绕着“前端项目高可扩展性”和“前端项目高效率”和“前端项目高稳定性”三个主要目标，调研各种技术方案的可行性。主要考虑采用微前端社区中成熟的开源框架，这样一方面可以降低对于外部供应商的依赖，更好实现对技术架构的自主掌控；另一方面，国内一线互联网大厂的开源产品技术成熟度更高、迭代升级更快、应用稳定性更好，出现问题也可以及时从开源社区寻找到答案。另外，还需要根据业务场景的需求做筛选，一般会从浏览器兼容性、开发复杂程度、框架体积、接入成本几方面做考虑。

在推广应用阶段，采取了子应用阶段上线的策略。首先上线了综合业务管理系统的主应用（基座应用）的上线，为后续的子应用上线打下基础。然后分阶段的上线了各个子应用，并持续监控各个子应用的运行情况。微前端的架构可以让各个子应用独立开发，独立上线，解决了以前需要同时把所有业务都开发完才能一起上线的问题，极大地提高了开发和上线的效率。

通过基于微前端架构的综合业务管理系统的实施，对建立健全公司自主研发体系架构，适应业务快速变化趋势以及保障系统安全稳定运行起到关键作用。