跳到主要内容

基础部件开发

用户及权限 - Security​

  • 仅包含 User、Account、Role 和 Permission 对象，且只包含核心属性， 其余的属性通过差量机制补充
    • User 为应用服务的使用者模型（不使用应用则没有 User 数据），与具体业务无关， 在实际的业务场景中，可以将 User 与 员工、客户 等业务模型进行一对一的绑定
  • 帐号 Account 仅用于登录认证，认证通过后，所有的数据都直接关联 User 模型
  • 一个 User 可以有多个 Account，不同的 Account 有不同的权限， 用于不同的处理场景，如，自动化工具帐号、与他人共享的协办帐号等。 默认始终有一个 主帐号（Primary Account），其余的为 子帐号（Sub Account）。 所有帐号均可以被禁用
    • 协办帐号的使用者需同样拥有系统帐号，需先登录系统后，再切换到协办帐号
    • 工具帐号的密钥随机生成且不可修改，同时设置有效期
    • 不同的登录方式设置在主帐号上，或者，自动创建对应的子帐号？
      • 前者不易扩展，需要修改代码才能支持；后者更灵活，并且可以启/禁，方便管理
    • 若主帐号被禁用，则子帐号也全部禁用
  • 系统权限通过角色、分组等授权给 User，再由 User 自己按需授权给不同的 Account， 主帐号始终拥有 User 的全部权限
  • 操作日志、审计信息等需同时记录操作人的身份 Account 以及唯一对应的 User， 格式采用类似 {user: 'xxx', account: 'xxx'} 的 json 形式
  • Account 的唯一性限定在 User 内
  • 支持 临时帐号（Temporary Account），用于限定在一段时间内可进行某些操作的人员使用场景， 由主帐号通过系统自动生成临时认证链接，再发给特定人员登录并进行相关操作
  • Account 可以分为 内部帐号 和 外部帐号，内部帐号为系统内创建和维护的帐号， 外部帐号为外部系统创建和维护的帐号，并通过单点认证等方式接入系统
  • 定义 DSL UserBinder，包含 User user 属性，人员等 DSL 扩展自该 DSL
    • 在有组织机构时，User 的详细信息来自于组织机构中的人员信息
  • 定义 DSL PermissionsBinder，包含 List<Permission> permissions 属性， 组织/角色等 DSL 扩展自该 DSL
  • 定义获取 User 权限的 DSL，以支持扩展权限的获取来源和方式

组织机构 - Organization​

  • 数据数量级为 万
  • 组织模型：部门（Department）、团队（Team）、职位（JobTitle）、 第三方（ThirdParty）、区域（Region）
    • 定义基础 DSL OrgUnit（组织单元），其他类型均扩展自该 DSL
  • 人员模型：员工（Employee）、客户（Customer）、外包（Outsourcing）
    • 定义基础 DSL OrgStaff（组织人员），其他类型均扩展自该 DSL
    • 各类均可绑定唯一的 User
    • 若 Customer 等非内部人员有系统使用需求， 则需提供不同的服务（且有独立的入口）做单独的控制， 只是人员信息来自于该组织机构
  • 通过差量机制建立人员与 User、组织与 Permission 的关系， 实现从组织机构的角度维护用户权限：扩展自 UserBinder、PermissionsBinder
    • 提供 User 权限获取的实现
  • 支持 Excel 导入导出
  • 可从 LDAP 导入数据或者直接使用 LDAP 数据，并以 DSL 维护双向转换关系
  • 分级管理，不同层级的人员可访问和操作的模块、数据均不同
    • 不同层级的人员有不同的应用入口（子域名或子路径方式）、应用界面
    • 上级可以查看和操作本级及其子级的数据

自监控​

  • 拦截 Class Method，并记录调用链、调用参数、调用耗时、调用返回值等性能信息
  • 服务运行状态监控
  • 用户操作记录
  • 流量监控
    • 以图形化方式展示从发起端（客户端 ip、客户端类型）到数据层的全链路的数据流动情况
    • 提供按位置（客户端位置、服务部署位置等）、应用等多种观察视角

流程引擎​

  • 流程流转能力
  • 各类业务流程由具体的流程业务部件支持

消息提醒​

  • 微信
  • 邮件
  • 短信

部件部署​

  • 可将指定的功能部件部署到指定的主机群上运行，并进行监控和调度

日志​

  • 接口内打印 结构化 日志内容，以消除后续的解析过程， 若是需要过滤和再加工，则可通过配置界面对日志内容的结构进行映射转换即可
  • 日志本地文件
  • 日志远端服务
  • 预期之外、正常流程之外、被禁止/不被允许的等行为也需要记录日志，以便于排查
    • 能给予提醒的，还需要给用户相应的提示信息

数据权限及审计​

  • 对行、列数据的增、删、改、查的操作控制
  • 以专门的数据库存放对数据的变更和审计信息， 业务主库仅存放最新的数据，降低业务侧的复杂度
    • 审计数据库可采用 MySQL 或 ES
    • 审计数据库仅存放差异数据，在需要全部信息时，按照变更历史进行合并即可
    • 审计数据库的第一条数据必然为全量数据
    • 业务数据库的数据不需要软删除标记，但保留版本号、创建和更新信息

数据库数据管理​

  • 可以以表格形式查询和直接修改数据库中的表数据， 用于临时性的数据修正和数据检查

分布式文件存储​

  • 支持任意大小文件的读写
  • 以接口方式向各个内部服务提供配置文件、数据文件的存取支持
    • 服务优先将配置和数据存放到数据库中， 一是便于读写，二是可保持内容的结构化， 其他图片类、文档类文件才通过文件存储服务存取

基础组件​

  • 缓存
  • 消息队列
  • 文件存储
  • 定时任务
  • ORM 审计记录
  • ORM 变更历史：包含审计信息，以明确谁在何时修改了哪些数据

多租户​

  • 自动为所有数据模型加上租户标识属性
  • 增删改查数据均限定在当前租户的数据上
  • 在请求处理前，根据当前用户获取其所属租户的标识
  • 自动任务需记录租户标识，并根据该标识处理对应租户的数据
  • 租户管理
  • 租户流量分流控制
  • 服务升级涉及表结构变更时，需提供快速且便捷的变更机制
  • 通过差量机制在模型中增加租户标识属性和字段，并在查询中附加租户过滤， 同时拦截请求以注入当前用户所属租户的租户标识
最后由 flytreeleft 于 更新