前端基础架构 - 设计部分

Mothpro
476 阅读7分钟

持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第24天，点击查看活动详情

前言

我所负责前端框架目前为止一共经历了三个阶段：

  • qiankun微服务框架

该框架只是做了部分的技术预研，在我的理解里，该方案是一套非常成熟的前端微服务一站式解决方案，至于为什么弃用，经过了解是原来的前端技术团队hold不住该框架技术，不利于团队学习和人员招聘，有学习风险。而且前期的前端技术团队对产品的需求了解有一定的误差，认为该方案无法解决产品团队的问题，所以弃用了也是一大很重要的原因。

  • 非spa应用的多页面微服务技术

为了解决产品多样性并能够做到各个工作站中的菜单可以热插拔灵活配置的需求，我们舍弃了qiankun微服务方案，采用了多页面热插拔的技术，舍弃了原来的spa（单页面应用 Single Page Application）方案。

  • 在多页面微服务技术的基础上外加了一层云智“外壳”

所谓的云智“外壳”，其实是在工作站的最外层，框架组提供一套命名为【framework】的容器层

framework 是一个用传统spa技术实现的一个套壳容器应用，主要原理是用 vue-router + iframe 技术实现了一层虚拟路由的托管，即打开标签页其实是在网页上新开了一个iframe容器，而新开的页面通过iframe容器展现给客户。

在云智"外壳"的作用下，可以无关技术栈的接入各种前端技术开发的web应用，兼容主流的h5，ag，react，vue……并且对于浏览器兼容也有很好的适配性。

在该框架体系中，所有被iframe容器打开的web应用都将被视为第三方应用。所以理论上来说，只要第三方合作厂商在遵循我们的UI规范和交互设计规范的前提下，是可以无缝接入我们的framework容器的。并且在用户端是没感知的“一体化”流程。

为了更好的了解framework这一容器外壳设计，需要先了解UUM的业务：

UUM（统一用户管理与权限设置）

image.png 用户掌握系统一个账号,  根据不同的权限可以进入不同的工作站, 工作站中根据角色和权限对应不同的功能;

  • 用户首次使用超级管理员（ROOT）账号登录

  • 通过【工作站注册】中配置工作站

image.png

  • 通过【工作站配置】为工作站添加菜单（应用），并设置该菜单的首选项设置（机构|院区|科室|子科室）

image.png

  • 通过【工作站角色管理】为工作站添加角色

  • 添加用户，并添加工作组，为工作组设置用户成员和管理员

    • 工作组中的管理员用于做分级授权

image.png

  • 在角色配置中设置角色

基础元素

用户: 医院工作者对应唯一用户;

管理员：工作组管理员，用于做分级授权（PS：仅用于分级授权设置）

工作站: 根据用户的工作站和角色，划分出来的业务域，展示给用户直观看到的并且相互独立且隔离的网站

应用: 即工作站下的菜单对应功能，通过工作站配置菜单栏进入

服务：对日常工作业务逻辑的关联性做的服务划分;即多个应用的集合，每个应用都是一个页面级别的容器

image.png

工作站、应用、服务之间的关系

  • 工作站是对外展示给用户的（医务人员），例如住院医生站，门诊医生站，医技工作站
  • 用户进入工作站以后，可以看到左侧或者是顶部有一排菜单栏，菜单栏上每一个菜单对应的都是一个应用

image.png

  • 工作站的应用是灵活配置出来的，可以实现每家医院个性化和定制的需求，根据医院的实际业务流程情况做增加或者是删减

    • 举例：

A医院所用系统有住院医生站，其中菜单栏下面有【挂号】，【患者列表】，【诊断录入】三个菜单

B医院和A医用所用系统同样是我们的系统，但是B医院的住院医生站，其中菜单栏下只有【患者列表】这一个菜单

  • 应用则在我们前端项目管理中，对应一个服务域，比如上面讲到的【挂号】，【患者列表】，【诊断录入】这上个就归属于【opm】（门诊医生站）系统

【opm】在前端项目管理中为门诊医生站，这是一个虚拟的工作站概念，或者更明确来说，我们应该叫门诊医生服务，

而【挂号（registered）】，【患者列表（patientList）】,【诊断录入（diagnosisEntry）】都属于【opm（门诊医生服务）】中的应用。

展示给B医院的住院医生站中的【患者列表】菜单，即来自于【opm】服务中的，同时B医院也可以再门诊医生站中，配置【患者列表】菜单，该菜单对应的应用同样来自于【opm】服务。

  • 了解工作站、应用、服务之间的关系以后，我们可以有效的拼出应用的启动链接，举例：

我们需要在医生工作站配置【患者列表】菜单

首先用ROOT用户前往UUM的工作站注册中，注册医生工作站

在工作站配置中为工作站配置菜单

菜单路径来自于应用名和服务名，比如【患者列表】应用名叫patientList，【门诊医生服务】服务名叫opm，菜单路径即：/opm/patientList

前端技术架构

基于业务特性,前端采用微前端架构将应用之间拆分，非单页面，采用多页面的形式，充分解藕，支持可插拔配置;

架构特性

  • 技术栈无关

主框架不限制接入应用的技术栈，可以随意选择vue,react,angular等框架接入其中

  • 独立开发、独立部署

微应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新

  • 增量升级

在面对各种复杂场景时，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前端是一种非常好的实施渐进式重构的手段和策略 按业务拆分为

  • 独立运行时

每个微应用之间状态隔离，运行时状态不共享，将巨石应用拆解成若干可以自治的松耦合微应用

image.png

  • 支持自定义配置面板和主题颜色文字大小切换

不仅限于功能菜单，对于应用面板内容也能让客户实现其个性化需求

PS：A医生在右侧portal页展示的系统菜单（占6个插件位），左侧分别展示危重病人、新入病人、手术计划、各部电话、日历、病历仪表盘6个插件，【共12个插件位】，医生可以根据自己的需要选择放置自己想要的插件，整体系统的字体、颜色，都可以根据自己的喜好来切换和选择 主服务容器:即业务入口,为服务模块提供容器,子服务以submodule的形式挂载在容器上面，主要做编译和发布管理

image.png

avatar
文章
阅读
粉丝