权限系统:主要提供可配置的权限管理供第三方使用。
- 应用 需要抽象自己的资源(比如某个url)和权限(比如读写权限)
- 权限管理平台提供 rpc & http 服务,包括:用户(组),资源(组),权限(组),赋权等的CURD,高可用和图形化可配置管理是该项目必然要求。
[外链图片转存失败(img-EWoLf7L9-1563607097004)(http://assets.processon.com/chart_image/5b652325e4b0f8477da2b332.png)]
上图简单的描述了权限系统结构与应用的对接
需求分析
设计需求
-
公司人员是多变的;对于某些数据的权限,每个企业员工也是不同且会变化的。如果第三方可配置,各个应用直接接入是最友好的
-
公司的开发流程
本地->测试->线上
,测试发版是个比较慢的问题,如果出现权限问题,需要有个地方直接处理,而不是急忙的再改个代码发版啥的;开发也是功能业务优先,权限不应该成为一个开发重点,权限应该是个服务重点(我指的是普通程序猿应该花精力做好功能、业务,多思考代码优化和服务优化的事情;上面的大佬负责好权限的把控,程序猿负责实现就好了) -
对于某些数据报表的应用,大佬可能在看的过程中发现诸如某个人对于该表的权限应该有或应该没有,需要及时处理;还有需要做一些权限盘点的查看等
-
让公司很多相似的应用都设计和编写权限部分的需求不太友好
从项目服务特点来讲
- 前端简单,配置友好
方便用户配置应用
,用户(组)
,权限(组)
,资源(组)
,赋权
等,使用用户基本需要包括各类人员,不局限于开发者。
- 后端必须高并发,高可用
对接的服务比较多,并且QPS
会比较大;其次权限一旦挂掉,将是严重的损失,可能所有依赖的应用也因此挂掉
项目开发与问题
- Java8
- SpringBoot
- MyBatis, CP30, MySQL
- Redis
- 限流
除了提供HTTP
外,Java应用采用了RPC
的dubbo
(https://github.com/apache/incubator-dubbo)