用户管理方案具体实现
2024-11-29 10:03:27 0 举报
AI智能生成
用户管理方案具体实现
作者其他创作
大纲/内容
1. 需要实现的需求
1. 解决客户经常需要自定义用户管理模块但很难实现的问题
AdminPortal不能给最终用户登录
现有的权限体系无法满足客户需求
2. 解决目前的用户表结构不满足用户特定需求的问题
比如用户的角色需要分应用
3. 解决业务库与用户库联表查询的问题(非必须)
确认不提供用户信息视图
2. 竞品的实现方式
1. OutSystems
1. OutSystems在平台启动时,会默认发布一个 Users Module 的模块,可以在 OutSystems 的 AdminPortal 平台登录使用
2. 该 Users Module 用户无法修改,只能在应用中引入一个副本项目查看内部的实现与表结构
3. 该模块默认使用内建的数据库,Out Systems 的应用默认无法修改数据库,只能通过引入 插件 的形式引入其他数据库类型
4. Out Systems中,所有的应用共享相同的用户数据(同 Forguncy)
5. 如果用户不满足用户表结构,他只能创建一个扩展表来实现
这种方案有一个弊端,如果有A/B两个应用,A应用为用户创建了扩展表,如果在B应用中删除了一个用户,则A应用对应的扩展表的数据并不会被删除
2. CodeWave
1. CodeWave的用户是分散式管理的,应用A和应用B各自会使用各自的用户模块,其数据就存储在自身的业务数据库中
2. 默认打开的应用中没有用户模块,只有用户手动引入时才加入
3. 加入的用户模块包括前端页面、命令以及数据库,用户也可以随意扩展用户相关的数据库表结构(不能删除)
4. 用户可以将多个应用连接相同的数据库,从而实现用户数据的共享
3. 目前的方案
方案1:默认用户管理应用模式
关键点
1. 用户管理逻辑由 Server2 进程实现
2. 需要创建两套用户体系(应用用户和系统用户)
3. 用户分散管理
4. 需要数据同步器将用户数据同步到业务库中
实现方式
1. 设计器内置用户管理应用,项目启动时,会默认发布一个用户管理应用(类似 Out Systems)
2. 用户自定义的应用默认会基于上述用户应用作为用户管理模块
3. 如果用户对默认的用户管理应用不满意,可以自定义并覆盖此应用
4. 不提供用户信息视图,如果用户有联表需求,需要通过内部的一个同步器将用户管理应用的数据以及表结构同步到自己的业务库中
5. 如果用户有页面设计需求,可以在自己的业务应用中同步用户管理应用的页面,页面的操作以调用服务端命令实现
6. Admin Portal 需要额外提供一套系统用户,用以管理 AdminPortal 中的操作,系统用户无法登录业务系统(类似金蝶云苍穹)
7. Admin Portal 中还需要保留前端页面以管理应用、监控、License 等
1. 如果以 react 实现,则 AdminPortal 还需要编写前端页面
2. 如果以低代码实现,则 AdminPortal 也需要应用执行引擎
8. 用户管理应用可以发布多份(解决多租户问题),用户可以在业务应用中修改所使用的用户管理应用(不一定实现)
9. IT 用户是否可以学习 Out Systems,Administrator账户由葡萄城通行证用户登录,内部的其他用户由此用户创建
优点
1. 用户管理依然类中心化(如果不做多个用户管理服务),用户数 License 友好
2. 用户管理的需求可以很轻易实现,模块灵活性友好
3. 可以扩展出多租户的形态,模块扩展性友好
缺点和问题
1. 用户服务升级导致的各种迁移问题
1. 在用户已经自定义用户相关数据库结构的数据库迁移(迁移脚本容易实现)
2. 低代码页面的升级(需要用户手动导入升级)
2. 可能存在项目版本和用户管理版本不一致的问题
1. 比如项目版本已经2.0了,但是用户基于各种原因就是不升级用户管理应用
2. 此时就需要考虑2.0的应用去接入 1.0 用户管理模块的问题,可能容易产生严重的兼容性负担
3. 用户如果期望将用户管理页面内嵌入应用系统中,此模式并不能很好地解决此类问题,需要用户手动导入页面组件
4. 如果支持多个用户管理应用,那么用户数 license 如何解决
5. admin portal 中,除了用户管理外的其他功能还需要一套体系实现,整体功能割裂,并且需要两套用户体系
6. 发布覆盖问题
用户应用 的数据由谁覆盖?
如果由用户应用自己覆盖,那么每次发布需要同时发布两个应用?
如果由业务应用覆盖,那么怎么保证被多个应用共用的用户数据不会被覆盖错乱?
7. 设计时,怎么更新用户应用的内容
更新了之后未来永久生效
设计器升级,被更新的内建用户应用是否自动升级
8. 如果期望业务数据与用户数据关联需要用到同步器,存在时效性问题
9. 如果发布多个用户应用,它们能否连相同的外联库
缓存
用户数 license
10. 会出现两套用户体系以及两套应用体系,增加用户心智负担
架构图
方案2:内嵌用户管理模式(方案1优化)
关键点
1. 用户管理非中心化
2. 支持两种用户管理模式
3. 用户管理逻辑由 Server2 进程实现
4. 需要两套用户体系
实现方式
1. 对方案1的优化,主要是不再区分用户管理应用和业务应用,每个应用既可以充当业务应用,也可以充当用户管理应用(CodeWave模式)
2. 一个应用启动时,默认用户管理就存放在自己的业务库中,用户需要手动导入用户管理模块才能看到对应的前端页面
3. 除了默认的内建模式外,也支持方案1中的连接外部用户管理,连接方式与方案1完全相同,应用可以自行切换
优点
1. 此方案在内建模式下,很好地解决了方案1中用户想要在业务应用中内嵌用户管理时,需要额外导入用户页面的问题
2. 此方案在内建模式下,也能很好地解决业务库与用户库联表需要同步器的问题
3. 相较于方案1此方案更灵活,可扩展性更强
4. 在内建模式下,用户服务都内置了,用户的登录逻辑无需绕行其他服务,性能比方案1更好
5. 内建模式下,可以优化数据发布覆盖的问题
6. 两种模式有明显的边界,所以可以分版本实现,对开发排期友好
缺点和问题
1. 用户管理彻底分散化,导致了用户数 license 不友好
2. 同样存在升级迁移的问题,但是由于用户可以分散存储,可以稍微缓解此问题
3. 同样需要处理版本不一致所带来的兼容性问题
4. 同样需要两套用户体系,且 admin portal 可能存在重复性功能
架构图
方案3:Forguncy优化模式
关键点
1. 用户逻辑 AdminPortal 实现
2. 只需要一套用户体系
3. AdminPortal 服务化,不提供前端页面
4. 用户服务中心化
实现方式
1. 此方案是对当前活字格用户管理的优化,此方案中,AdminPortal完全服务化,仅提供Java Api,不提供任何UI操作
2. 所有的 UI 操作交由低代码设计时实现,业务应用运行时用户可选择地导入相关模块,所有的操作由服务端命令实现
3. 用户数据以同步器的形式同步数据以及表结构到业务库
4. 用户的扩展需求需要也扩展表的方式实现
优点
1. 用户管理中心化,用户数license友好
2. 无需两套用户体系,降低用户心智负担
3. AdminPortal服务化,无需前端项目
4. 不存在用户与应用的版本不一致问题(用户模块永远是最新的)
缺点和问题
1. 用户模块扩展性差,所有应用共用一套用户,多租户,分应用的用户很难实现
2. 所有应用的登录登出请求都要绕行 AdminPortal,性能差
3. 用户扩展字段需要做扩展表,存在多应用从表数据不一致的问题(即 OutSystems 第 5 项)
4. 低代码设计时需要实现完整的 AdminPortal 功能,不确定可行性
5. 由应用管理AdminPortal的权限是否合理,未来如果要实现应用权限可能成为挑战
6. 同样存在用户页面升级所带来的页面迁移问题(数据库迁移问题不存在)
架构图
0 条评论
下一页