search

WeBankPartners / wecube-platform

WeCube Platform
Apache License 2.0
365 stars 85 forks source link

【框架2.0】插件注册功能 - 菜单注入 - 后端 #388

Closed HoweChen closed 5 years ago

HoweChen commented 5 years ago

此为 #287 的后端实现 issue，以方便项目追踪管理。

根据之前的 #12 的 解决方案 中的API代理网关工作原理时序图： API代理网关工作原理时序图

菜单注入的功能流程

1.插件包注册时，在xml注册文件中配置标签里面的内容，示例：

    <!-- 2.菜单注入 - 描述运行本插件包需要注入的菜单 -->
    <menus>
        <!-- 具体规范: -->
        <!-- 1. 在原提供的菜单地址前面加上“/api-proxy/{package-name}”, {package-name} 指的是插件包第二行描述的package 
            name -->
        <!-- 2. parentMenuCode输入的是WeCube-Platform的一级菜单，目前取值范围有 "JOBS"、"DESIGNING"、"IMPLEMENTATION"、"MONITORING"、"ADJUSTMENT"、"INTELLIGENCE_OPS"、"COLLABORATION"、"ADMIN" -->
        <!-- 示例如下: 插件提供的菜单地址有两个，分别是 “/service-catalog”、“/task-management”, 应配置如下 -->
        <menu name="Servive Catalog Management" parentMenuCode="JOBS"
            description="服务目录管理">/api-proxy/service-management/service-catalog
        </menu>
        <menu name="Task Management" parentMenuCode="JOBS"
            description="任务管理">/api-proxy/service-management/task-management
        </menu>
    </menus>

2.插件注册时，WeCube-Platform将注册文件解析后返回到前端预览：

image

3.待插件成功注册后，WeCube-Platform会将该数据写入数据库的表plugin_menus:

image

4.当成功运行插件实例后：

4.1 WeCube-Platform将所有菜单列表返回给Portal 4.2 用户点击插件菜单“服务目录管理”时，Portal将会向Platform请求/api-proxy/service-management/service-catalog； 4.3 Platform解析/api-proxy/service-management/service-catalog后，会向服务管理插件请求/service-catalog，得到插件的静态资源返回给Portal。

因为 @gavin2lee 说会将api-proxy那部分修改，所以后期编码过程会有小调整，但是大致流程应该不变， @nevinxie @gavin2lee 麻烦看看这个是否可行？

Originally posted by @haixinhuang in https://github.com/WeBankPartners/wecube-platform/issues/287#issuecomment-533806984

HoweChen commented 5 years ago

@haixinhuang 命名尽量清晰，menu的name和description是什么关系？尽量叫id和display_name等能够清晰表达的名称。另外，display name在注册的时候能否修改？如果不能，多语言支持可能有些问题。 另外，第二个问题，URL中的package-name不需要在xml中重复多次（每个menu item都需要重复），应该有规范进行拼接（请参考设计原则 - DRY - Donot Repeat Yourself）。

其他的我没有问题，另外前端静态资源在运行态是放在哪里？这个可能需要API-gateway做个解释。有可能静态资源统一放置，取决于前后端是否彻底分离 @irvinezhao

其他的我没有问题，另外前端静态资源在运行态是放在哪里？这个可能需要API-gateway做个解释。有可能静态资源统一放置，取决于前后端是否彻底分离 @irvinezhao

这里所说的前端静态资源应该是插件的前端静态资源吧，protal和platform的前后端分离，也要求插件的前后端做分离吗？如果是，这只是指运行态的前后端分离吗？

@haixinhuang 命名尽量清晰，menu的name和description是什么关系？尽量叫id和display_name等能够清晰表达的名称。另外，display name在注册的时候能否修改？如果不能，多语言支持可能有些问题。 另外，第二个问题，URL中的package-name不需要在xml中重复多次（每个menu item都需要重复），应该有规范进行拼接（请参考设计原则 - DRY - Donot Repeat Yourself）。

根据你的意见，xml更新如下：

    <!-- 2.菜单注入 - 描述运行本插件包需要注入的菜单 -->
    <menus>
        <!-- parentMenuCode输入的是WeCube-Platform的一级菜单，目前取值范围有 "JOBS"、"DESIGNING"、"IMPLEMENTATION"、"MONITORING"、"ADJUSTMENT"、"INTELLIGENCE_OPS"、"COLLABORATION"、"ADMIN" -->
        <!-- 示例如下: 插件提供的菜单地址有两个，分别是 “/service-catalog”、“/task-management”, 应配置如下 -->
        <menu displayEnglishName="Servive Catalog Management" displayLocalName="服务目录管理" parentMenuCode="JOBS" description="Use to describe this menu include which functions"  >/service-catalog
        </menu>
        <menu displayEnglishName="Task Management" displayLocalName="任务管理" parentMenuCode="JOBS"
             description="Use to describe this menu include which functions">/task-management
        </menu>
    </menus>

说明如下： 1.删除 “在原提供的菜单地址前面加上/api-proxy/{package-name}”，由于/api-proxy/{package-name}是platform补充添加的，插件注入菜单无需知道。（另外，在插件列表注册 #292 需要要求插件后端提供API的url有约定的“/api-proxy/{package-name}”） 2.displayEnglishName和displayLocalName用作多语言支持，插件开发者只需要支持英语和本地语言就足够了。 3.我认为menu ID应该由platform生成并保证唯一性，所以初步方案是由platform根据插件包名+版本+displayEnglishName生成。

@haixinhuang 同意第一点 English+Local Name不是一个好的方案，暂时只保留displayName，等国际化的实际需求进一步明确之后再讨论。 description还有意义吗？如果系统不使用，建议删除。

1.English+Local Name这个方案是之前我听到监控插件的做法，如果有其他考虑，那就按你说的，暂时只保留displayName。 2.现在一个菜单下的页面可以提供多个服务，例如“服务目录管理”菜单，在这个菜单的页面中，你可以请求新建一个服务目录、也可以新建一个服务通道，保留description的目的是为了描述整个菜单提供的所有服务，“服务目录管理”的description可以写“本菜单包含服务目录新建、服务通道新建功能”。 另外，菜单名字一般较短，description可以作为补充描述。 所以我觉得description有意义的，不同意删除。

From meeting-minutes-2019-10-09: 当前需求只提供最多两层菜单； 提供菜单排序能力； 显示菜单序号，状态（运行、注册、停止、销毁）

HoweChen commented 5 years ago

相关接口信息在 #375 的 第五个，现已完成。