基于前端技术实现的工业产品应用体系构建的方法、系统与流程

1.本发明属于微前端技术领域，具体的说，是涉及一种基于前端技术实现的工业产品应用体系构建的方法、系统。


背景技术：

2.在工业软件交付场景中，乙方的软件产品往往不能直接交付甲方使用，而需要经过二次开发(二开)甚至三次开发(三开)，直到满足甲方需求。但是承担二开或三开的通常是项目交付团队，不是产品研发团队，为了实现产品源码的版本管理和安全要求，往往需要实现闭源传递，但是闭源传递会导致二开无法新增、删除、修改已经闭源的产品功能。工业软件往往是多个产品相互组合形成的一个能满足某些工业生产场景的产品集合，在前端领域则大多会体现在多个web入口、多个web项目，多个部署位置。
3.微前端技术是将一个前端项目拆分为一个主项目(主应用)和多个子项目(微应用)，在运行时合并为一个完整应用的技术，主要解决了子项目独立开发、运维的问题。现有技术中，在工业软件开发的应用场景，微前端技术主要存在以下不足：
4.(1)微应用的多重嵌套使用时，路由自动激活加载微应用不可靠(非常容易加载失败)；微应用的加载有两种方式，方式一：路由模式，微应用与路由信息绑定，通过监听路由变化自动触发微应用加载动作，从指定的微应用入口获取文件资源、执行挂载到指定的容器节点(挂载点)，创建js实例；同时触发不符合路由关系微应用的卸载，清空相应容器节点内容，销毁js实例，该方法可以给场景设定路由，由路由决定加载哪些微应用，但是在多重嵌套微应用时受限于挂载点的异步延时生成，不能及时找到挂载点导致加载/卸载异常；方式二：手动模式，手动触发微应用加载动作，从指定的微应用入口获取文件资源、执行挂载到指定的容器节点，创建js实例；同时手动触发不符和需求微应用的卸载，清空相应容器节点内容，销毁js实例，该方法只能通过代码固定在业务逻辑内，不能实现灵活重组，且在大规模应用时内嵌加载、卸载逻辑十分复杂。
5.(2)同时开发多个微应用时启动过程及配置复杂，需要启动多个服务及端口，同时注册微应用时端口也必须一致。
6.(3)多产品间的微应用组合展示时，不能一次性引入某个产品的所有微应用，且注册微应用的过程和被引入的微应用耦合，注册信息需要两边同时修改。


技术实现要素：

7.本发明的目的在于提供一种满足工业软件开发和交付场景下对web前端产品的需求的基于前端技术实现的工业产品应用体系构建的方法，以解决现有技术所存在的技术问题。
8.为了实现上述目的，本发明采取的技术方案如下：
9.一种基于前端技术实现的工业产品应用体系构建的方法，包括：
10.(1)产品业务拆分：将产品按照基础业务、核心业务、扩展业务进行拆分解耦，形成
一个主应用和不同的业务微应用；
11.(2)主应用的配置器按照配置信息加载不同的业务微应用；
12.(3)产品组装：(31)本地化组装，将需要组装的产品的配置信息合并为一个apps.json，同时，将不同的产品的业务代码块合并到一个目录下；(32)在线组组装，若干已经独立部署的产品相互按不同颗粒度相互在线组装；
13.(4)产品源码闭源传递：按业务微应用逐一打包构建，并通过脚本自定将结构存放在统一目录中，形成产品包；根据产品包拟定产品二开示例工程，然后，传递产品包和二开示例工程；
14.(5)页面拓展：(51)原生页面扩展：在二开示例工程的apps目录下按微应用示例新建微应用工程，在二开示例工程的apps.json内，仿造示例微应用的配置，添加对应的微应用信息，触发激活规则，实现原生页面扩展；(52)现有页面的二次扩展和修改：在开发页面时预埋点，在二开示例工程的apps目录下按微应用示例新建微应用工程，并配置特定描述的apps.json内容，触发激活规则，实现现有页面的二次扩展和修改。
15.作为优选的，所述的配置信息包含主应用信息和所有业务微应用的名称、依赖父级名称、激活规则、容器信息、入口地址、菜单信息，以文件形式单独存在。
16.作为优选的，所述(2)中业务微应用的加载方法，具体如下：根据业务微应用的配置信息，动态创建挂载点，监听挂载点创建完成后，再执行业务微应用的挂载动作；
17.挂载动作：基于路由激活规则，根据配置信息判断业务微应用的挂载点是否存在，若挂载点存在，则直接将微应用加载到容器内，若不存在则将挂载点信息加入监听序列，监听页面元素结构变化，当指定挂载点被渲染后，成功触发监听回调，将对应业务微应用加载到容器内。
18.作为优选的，所述(32)包括：
19.(321)全量产品的在线组装，首先，一个产品的apps.json内配置另一个产品的apps.json文件地址；然后，该所述的一个产品的配置器在线获取所述的另一个产品的所有微应用的入口文件；最后，加载解析所述的入口文件，获取运行依赖资源，并加载到所述的一个产品的主应用中；
20.(322)部分产品的在线组装，首先，一个产品的apps.json内配置另一个产品某个微应用的apps.json文件地址；然后，该所述的一个产品的配置器在线获取所述的另一个产品的所述某个微应用的入口文件；最后，加载解析所述的入口文件，获取运行依赖资源，并加载到所述的一个产品的主应用中；
21.(323)动态替换微应用，当产品中的某个业务数据需要动态加载不同设备终端的业务微应用时，业务数据提供设备终端地址，配置器通过地址获取设备终端的apps.json，并执行组装加载，实现按业务动态替换微应用。
22.作为优选的，所述(4)中的二开示例工程包括二开示例和打包构建方法；其中，所述的打包构建方法如下：(41)环境准备，将闭源的产品包部署到开发服务器上，得到产品访问地址；(42)在二开示例工程的apps.json中配置所述的产品访问地址；(43)配置器通过产品访问地址加载产品的所有业务微应用；(44)得到在线的仿真集成开发环境。
23.作为优选的，还包括基于所述的仿真集成开发环境实现多产品协同开发。
24.作为优选的，还包括同时开发多个业务微应用时，所有业务微应用都启动到一个
服务端口，然后使用业务微应用配置的name属性作为唯一路径，并将加载业务微应用的入口指向服务端口+name。
25.作为优选的，还包括当主产品和被协同产品间的微应用组合展示时，主产品的配置信息配置被协同产品的配置信息和过滤条件，主产品的配置信息和被协同产品的配置信息相互解耦，主产品的加载器根据配置将被协同产品的配置信息全量加载，并根据过滤条件按需合并到主产品的运行配置中，形成主产品的运行时配置。
26.作为优选的，所述(1)中基础业务是指产品的基础业务，核心业务是指产品的主要业务和特有的业务，扩展业务是指提升产品增值空间的业务。
27.为了实现上述目的，本发明还提供了一种基于前端技术实现的工业产品应用体系构建的系统，包括：
28.产品业务拆分模块：将产品按照基础业务、核心业务、扩展业务进行拆分解耦，形成一个主应用和不同的业务微应用；
29.业务微应用加载模块：主应用的配置器按照配置信息加载不同的业务微应用；
30.产品组装模块：本地化组装，将需要组装的产品的配置信息合并为一个apps.json，同时，将不同的产品的业务代码块合并到一个目录下；在线组组装，若干已经独立部署的产品相互按不同颗粒度相互在线组装；
31.产品源码闭源传递模块：按业务微应用逐一打包构建，并通过脚本自定将结构存放在统一目录中，形成产品包；根据产品包拟定产品二开示例工程，然后，传递产品包和二开示例工程；
32.页面拓展模块：原生页面扩展：在二开示例工程的apps目录下按微应用示例新建微应用工程，在二开示例工程的apps.json内，仿造示例微应用的配置，添加对应的微应用信息，触发激活规则，实现原生页面扩展；现有页面的二次扩展和修改：在开发页面时预埋点，在二开示例工程的apps目录下按微应用示例新建微应用工程，并配置特定描述的apps.json内容，触发激活规则，实现现有页面的二次扩展和修改。
33.与现有技术相比，本发明具备以下有益效果：
34.(1)本发明将产品按照基础、核心、扩展业务拆分解耦，形成不同的微应用，主应用的配置器按照配置信息加载不同的业务微应用，实现了每个前端产品的业务拆分，使得产品间可灵活组合。
35.(2)本发明采用产品源码闭源传递模，实现产品源码的版本管理和安全要求。
36.(3)本发明提供了闭源传递模式下的二开示例工程，得到一个在线的仿真集成开发环境，可以在开发环境中使用产品所有的业务功能，而且不需要源码。
37.(4)本发明提供了原生页面扩展和现有页面的二次扩展和修改(非源码侵入的扩展)，有效地解决了闭源传递模式下，导致二开无法新增、删除、修改已经闭源的产品功能的不足。
38.(5)本发明同时开发多个微应用时，简化启动过程，只启动一个端口，简化省略复杂的端口配置。
39.(6)本发明微应用信息配置化，微应用加载时，路由决定场景，层级决定嵌套深度，根据配置信息先动态创建挂载点，监听挂载点创建完成后，再执行微应用挂载动作，消除挂载点延时生成导致的异常，确保卸载时也能顺利执行，有效地解决了复杂场景下的多重嵌
套，而且全部是依靠路由规则执行性，不需要人为的代码干预加载。
40.(7)本发明提供了多产品间的微应用组合展示时方法，产品配置信息相互解耦，一个产品的配置修改发布不影响另一个产品的配置。
附图说明
41.图1为微前端技术原理图。
42.图2为本发明-实施例1所公开的产品业务拆分示意图。
43.图3为本发明-实施例1所公开的在线组组装的示意图。
44.图4为本发明-实施例1所公开的打包构建的示意图。
45.图5为本发明-实施例1所公开的多产品协同开发的示意图。
46.图6为同时开发多个微应用优化前的示意图。
47.图7为本发明-实施例1所公开的同时开发多个微应用优化后的示意图。
48.图8为本发明-实施例2所公开的系统的原理框图。
具体实施方式
49.为了使得本领域技术人员对本发明有更清晰的认知和了解，以下结合实施例对本发明进行进一步的详细说明。应当知晓的，下述所描述的具体实施例只是用于解释本发明，方便理解，本发明所提供的技术方案并不局限于下述实施例所提供的技术方案，实施例所提供的技术方案也不应当限制本发明的保护范围。
50.需要说明的是，以下实施例中所提供的图示仅以示意方式说明本发明的基本构想，故图式中仅显示与本发明中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。
51.实施例1
52.如图1～7所示，本实施例提供了一种基于前端技术实现的工业产品应用体系构建的方法，该方法旨在于赋予产品灵活定制最终形态的能力，解决了web软件产品化需求。
53.具体的说，方法主要包括以下内容：
54.一、产品业务拆分
55.将产品按照基础业务、核心业务、扩展业务进行拆分解耦，形成一个主应用和不同的业务微应用；在产品设计时划分业务性质，基础业务：产品是指工业产品应用(包括主应用和业务微应用)，产品的基础业务，是所有业务的基石，比如登录、用户、权限，也便于其他产品复用基础业务；核心业务：该产品的主要业务和特有的业务，比如oa系统的审批流；扩展业务：是提升产品增值空间的业务，可以不购买；当用户没有购买某些业务时，可以在配置信息内删除这些业务，并删除对应的微应用资源包，从根源上实现按需购买。
56.二、主应用的配置器按照配置信息加载不同的业务微应用；其中，配置信息包含主应用信息和所有业务微应用的名称、依赖父级名称、激活规则、容器信息、入口地址、菜单信息，以文件形式单独存在；通过修改apps.json可以改变浏览器加载的业务内容，呈现出不同的产品形态；删除某些微应用部署文件，结合配置信息可以达到从源代码层面进行业务屏蔽，即甲方没有购买a业务，就不会拥有a业务的代码块(打包后的结果)。
57.本实施例中，采用如下微应用加载方法，以解决大规模使用多重嵌套微应用时，优化路由自动激活加载微应用机制，实现稳定可靠的加载/卸载，灵活重组，其具体如下：根据业务微应用的配置信息，动态创建挂载点，监听挂载点创建完成后，再执行业务微应用的挂载动作，消除挂载点延时生成导致的异常，确保卸载时也能顺利执行，其执行逻辑路是由决定场景，层级决定嵌套深度，如a/b/c，即嵌套关系是微应用a包含微应用b包含微应用c，挂载动作如下：基于路由激活规则，根据配置信息判断业务微应用的挂载点是否存在，若挂载点存在，则直接将微应用加载到容器内，若不存在则将挂载点信息加入监听序列，监听页面元素结构变化，当指定挂载点被渲染后，成功触发监听回调，将对应业务微应用加载到容器内；例如：a微应用的路由激活规则是app/a，b微应用的路由激活规则是app/a/b，c微应用的路由激活规则是app/c，当路由是app/a时，根据配置信息判断a微应用的挂载点是否存在，若挂载点存在着直接将微应用加载到该容器内，若不存在则将挂载点信息加入监听序列，监听页面元素结构变化，当指定挂载点被渲染后，成功触发监听回调，将对应微应用加载达到容器内，当路由是app/a/b或者app/a/b/c时，重复执行上述步骤，最终得到一个由多重嵌套微应用组成的完成页面。
58.三、通过第一和第二点实现了每个前端产品的业务拆分，使产品间灵活组合成为可能，本实施例中提供了如下产品组装形式，且统一入口：
59.其一，本地化组装，将需要组装的产品的配置信息合并为一个apps.json，同时，将不同的产品的业务代码块合并到一个目录下；
60.其二，在线组组装，若干已经独立部署的产品相互按不同颗粒度相互在线组装；本实施例中，在线组组装主要包括三种形式，分别如下：
61.方式一，全量产品的在线组装，即一个产品完整的加载另一个产品，被加载的产品仍然独立运维：下述以a产品和b产品为例说明，a产品apps.json内配置b产品的apps.json文件地址，a产品的配置器在线获取b产品的所有微应用信息，间接获取到b产品的所有微应用入口文件(index.html)，加载解析入口文件，进一步获取运行依赖资源，并加载到a产品的主应用中，由此实现了b产品微应用在a产品上运行展示；
62.方式二，部分产品的在线组装，即组装某个产品的某个微应用，过程和方式一相同，不同的是，a产品apps.json内配置b产品的某个微应用信息；然后，a产品的配置器在线获取所述的b产品的所述某个微应用信息，以此间接获取到b产品的某个微应用入口文件；最后，加载解析所述的入口文件，获取运行依赖资源，并加载到所述的一个产品的主应用中；
63.方式三，动态替换微应用，其应用于根据不同的业务需求组装不同的业务应用，当产品a中的某个业务数据需要动态加载不同设备终端的业务微应用时，业务数据提供设备终端地址，配置器通过地址获取设备终端的apps.json，并执行组装加载，实现按业务动态替换微应用。
64.四、由于工业场景需要多次传递开发(产品研发-项目定制开发)，要想保证产品源码安全最有效的手段是产品源码闭源传递，限制源码暴露范围，则需要采用产品源码闭源传递，其具体方法如下：
65.按业务微应用逐一打包构建，并通过脚本自定将结构存放在统一目录中，形成产品包；根据产品包拟定产品二开示例工程，然后，传递产品包和二开示例工程，二开团队进
行二次开发；二开示例工程包括二开示例和打包构建方法；其中，所述的打包构建方法如下：首先，环境准备，将闭源的产品包部署到开发服务器上，得到产品访问地址；其次，在二开示例工程的apps.json中配置所述的产品访问地址；再其次，配置器通过产品访问地址加载产品的所有业务微应用；最后，得到在线的仿真集成开发环境。二开团队可以在开发环境中使用产品所有的业务功能，而且不需要源码。
66.基于上述的产品组装和二开示例工程，由此可实现了多产品协同开发的场景。
67.五、有了二开环境，则还需要解决闭源传递模式下二次开发的灵活性问题，即解决闭源传递模式下二开无法新增、删除、修改的问题，为解决上述问题，本实施例提供了如下页面拓展方式：
68.一种是原生页面扩展，在二开示例工程的apps目录下按微应用示例新建微应用工程，安装通用开发方式写业务代码，在apps.json内，仿造示例微应用的配置，添加对应的微应用信息，如名称、依赖父级名称、激活规则、容器信息、入口地址、菜单信息，刷新浏览器，点击相应菜单，触发激活规则就可看到新增加的业务页面；
69.另一种是现有页面的二次扩展和修改，要实现对现有页面的二次扩展需要在开发页面时预埋点，预埋点可以分两类，一是特设预埋点，一是普通预埋点，所有预埋点都标记都是一样的，如特定的唯一id，或者开发过程中就会产生的关于元素的css类名、属性等，可被css选择器选中的标记，特设预埋点是可以被全局状态变量控制是否执行自身默认逻辑和内容展示的，普通预埋点不做控制，大多是在默认内容后追加扩展的内容；在示例工程的apps目录下按微应用示例新建微应用工程，并配置特定描述的apps.json内容,例如：name以
“‑
extend”结尾，则表示是对父级应用(a)的扩展，默认对a的扩展是在埋点#containera1的内容后面追加，配置器会在全局状态变量中标记“#containera1”需要被替换，那么埋点#containera1的默认内容将会阻断执行，当激活规则被触发，页面加载渲染时，配置器会根据“a-extend”的入口配置“entry”加载改微应用到埋点内展示，由此实现了对产品现有闭源页面的扩展和修改。
70.六、同时开发多个业务微应用时，所有业务微应用都启动到一个服务端口，然后使用业务微应用配置的name属性作为唯一路径，并将加载业务微应用的入口指向服务端口+name。主应用和微应用都作为独立应用存在，开发时，将它们视为同一个应用的多页面，启动本地开发服务，假设服务端口是8080，参考vue项目的多页面工程开发说明，将主应用挂载在8080/(根目录)下，通过http://localhost:8080/可以进入主应用环境，将微应用按配置的名称(name)挂载在8080/[name]的目录下，通过点击菜单或者手动输入http://localhost:8080/[name]进入业务微应用页面。
[0071]
七、多产品间的微应用组合展示
[0072]
多产品组合时，每个产品都是由大量微应用组合形成的，其包括如下形态：形态一：a产品单独集成b产品的某个微应用，形态二：a产品集成b产品的大部分微应用，形态三：a产品单独集成b产品的所有微应用，其设计原理是：主产品的应用配置信息和被协同产品的应用配置信息解耦，注册信息改变时，只需要修改被协同的微应用配置信息。下述以主产品(a产品)和被协同产品(b产品)为例描述：
[0073]
主产品(a产品)和被协同产品(b产品)独立部署，基于前述设置，主产品(a产品)和被协同产品(b产品)均有自己的配置信息，且a产品的配置信息内配置了b产品的配置信息
文件地址和过滤条件，在运行时，a产品的加载器根据配置将b产品的配置信息全量加载(a产品根据本身的配置信息远程加载b产品的配置文件)，并根据过滤条件(过滤b产品配置)按需合并到a产品的运行配置中，形成a产品的运行时配置，当b产品修改某些业务微应用信息时，大部分场景下a产品不需修改自身配置信息，实现产品独立运维。
[0074]
实施例2
[0075]
如图8所示，本实施例提供了一种基于前端技术实现的工业产品应用体系构建的系统，该系统主要包括：
[0076]
产品业务拆分模块：将产品按照基础业务、核心业务、扩展业务进行拆分解耦，形成一个主应用和不同的业务微应用；
[0077]
业务微应用加载模块：主应用的配置器按照配置信息加载不同的业务微应用；
[0078]
产品组装模块：本地化组装，将需要组装的产品的配置信息合并为一个apps.json，同时，将不同的产品的业务代码块合并到一个目录下；在线组组装，若干已经独立部署的产品相互按不同颗粒度相互在线组装；
[0079]
产品源码闭源传递模块：按业务微应用逐一打包构建，并通过脚本自定将结构存放在统一目录中，形成产品包；根据产品包拟定产品二开示例工程，然后，传递产品包和二开示例工程；
[0080]
页面拓展模块：原生页面扩展：在二开示例工程的apps目录下按微应用示例新建微应用工程，在二开示例工程的apps.json内，仿造示例微应用的配置，添加对应的微应用信息，触发激活规则，实现原生页面扩展；现有页面的二次扩展和修改：在开发页面时预埋点，在二开示例工程的apps目录下按微应用示例新建微应用工程，并配置特定描述的apps.json内容，触发激活规则，实现现有页面的二次扩展和修改。
[0081]
需要说明的是，上述各模块的结构和/或原理与实施例1所述的基于前端技术实现的工业产品应用体系构建的方法一一对应，故在此不再赘述。
[0082]
需要说明的是，应理解以上系统的各个模块的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块通过处理元件调用软件的形式实现，部分模块通过硬件的形式实现。例如，某模块可以为单独设立的处理元件，也可以集成在装置的某一个芯片中实现，此外，也可以以程序代码的形式存储于装置的存储器中，由上述装置的某一个处理元件调用并执行某模块的功能，其它模块的实现与之类似。此外这些模块全部或部分可以集成在一起，也可以独立实现。这里所述的处理元件可以是一种集成电路，具有信号的处理能力。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。
[0083]
例如，以上这些模块可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个特定集成电路，或，一个或多个微处理器，或，一个或者多个现场可编程门阵列等。再如，当以上某个模块通过处理元件调度程序代码的形式实现时，该处理元件可以是通用处理器，例如中央处理器或其它可以调用程序代码的处理器。再如，这些模块可以集成在一起，以片上系统的形式实现。
[0084]
上述实施例仅例示性说明本发明的原理及其功效，而非用于限制本发明。任何熟
悉此技术的人士皆可在不违背本发明的精神及范畴下，对上述实施例进行修饰或改变。因此，举凡所属技术领域中具有通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本发明的权利要求所涵盖。