OC 开放平台（为整合子系统而生的微前端方案）
cssmagic opened this issue · 0 comments
cssmagic commented
| 项目周期 | 2021.03～2021.05 |
| 所在公司 | OC |
| 角色 | 项目负责人 / 架构师 |
概述
为解决以下问题：
- 公司内部各个技术平台（子系统）散落在各处 / 查找和使用不便 / 使用体验不统一；
- 子系统开发基础功能时重复劳动 / 开发标准不统一 / 成本高；
- 开发者围绕应用维度的工作流程没有打通等问题；
决定：
- 基于研发中台 v2 打造 “开放平台”，把子系统以标准化的方式接入平台。
- 把研发中台的基础数据和基础能力能过 OpenAPI 开放出来，提升各个子系统的功能和体验。
- 把各个子系统围绕应用维度的功能集合进平台，打通应用维度的工作流程。
职责
- 向 CTO 提议发起此项目，担任项目负责人。
- 作为架构师，主导设计平台核心机制、流程、界面、后端接口 OpenAPI、前端 SDK；指导工程效率组和前端架构组完成研发。
业绩
- 此项目探索出了符合公司现状的内部系统整合方案，上线后接入公司内部管理系统和研发平台共 20 余项。此方案以较低的接入成本和良好的使用体验赢得了各系统研发人员和用户的一致好评，CTO 评价：“可满足公司未来 5 年的技术基建需求”。
- 此项目成功申报软件著作权一项。
亮点
技术亮点：
- 基于 iframe 的微前端方案，解决了传统印象中 iframe 方案的一些问题：
- 框架间通信不便的问题
- 子应用需要重复登录的问题
- 父应用刷新丢失子应用路由状态的问题
- 子应用之间的跳转与数据传递问题
- 父应用向子应用传递 URL 参数的问题
- 父应用无法感知子应用运行状态的问题
- 把接入改造工作尽可能转嫁到 SDK 上，减少子系统的接入成本。
产品亮点：
- 不仅是微前端方案，也是子系统的管理平台和应用市场。
- 子系统可以以 Widget（插件）的方式把应用维度的功能暴露出来，打通应用维度的工作流程。
相关视频
相关材料节选
方案设计
-
内部基建项目的开发模式演进：
-
开放应用运行原理：
-
Widget 运行原理：
-
注册机制：
界面截图
-
研发中台的 “开放平台” 菜单（初始状态）：
-
开放平台的应用市场：
-
注册开放应用：
-
研发中台的 “开放平台” 菜单（注册成功状态）：
-
开放应用详情：
相关链接
- 公司项目：
© 经验分享 · 日拱一卒 | Star = 收藏 | Watch = 订阅