数据模型

数据模型用于定义应用的数据结构、 数据语义和数据规则, 即元数据, 是整个业务模型体系可视化设计的基础。

架构设计

1702353988284

数据模型在平台中主要由3种模型类型组成:

  • 概念模型: 对应数据模型的模型定义和模型规则定义的元数据;
  • 物理模型: 对应概念模型所映射的物理数据库表、 视图、 SQL 语句、 存储过程、服务、 JSON 等物理数据实体;
  • 代码模型: 对应存储数据模型元数据的 XML 模型文件( *.data.m) 和 Java ORM 持久化框架代码。 平台会根据 XML 文件的内容来生成对应的 Java 代码,包括 controller、service、mapper、model 等代码。

运行原理

数据模型运行和使用主要涉及以下几块内容:

1702353988284

模型设计

在进行数据库操作之前,需要先有数据模型。

数据模型可以采用两种方式进行设计:

  • 正向设计:先在平台中定义概念模型的表,再根据模型定义自动生成物理数据库的真实表。

1702294946769

  • 逆向设计:先有物理数据库的表,再反向生成概念模型的表,包括表和字段的中文注释也会同时反向生成。

1702294988024

数据组件

数据模型设计后, 在前端页面模型中会生成对应的数据组件(Data Component) , 通过数据引擎(DBRest) 进行前、后端数据交互。

数据组件和页面中的表单等组件之间是通过双向绑定来关联的。比如页面中放置一个输入框,输入框绑定一个数据组件的一个字段,在输入框输入内容后,对应的数据组件的字段就暂存了相应的数值,后续再通过 DBRest 的保存操作,就可以将这个数值保存到物理数据库的表字段里边。同时,如果修改了数据模型的数值,则数据组件也会在 UI 上实时显示该字段的内容。

80%业务场景中的增删改查、 关联查询、 子查询等 CRUD 操作, 通过组件和模型的属性配置即可实现, 无须代码编程 。 1702295041593

数据引擎(DBRest)

数据组件跟数据模型对接是通过数据引擎 DBRest 来处理的。

数据引擎是平台用来查询、插入、更新和删除数据的核心服务,可以认为是操作数据的转码器。页面上用户操作的行为,通过调用 DBRest 生成相应的 SQL 来执行。

以查询为例,DBRest 的 GET 请求类似这样的格式:https://域名/模块名/**dbrest**/数据模型标识?参数1=xxx&参数2=xxx 1702295159704

数据代理(DBProxy)

DBProxy 数据代理是在数据访问层的分布式数据库中间件,支持分布式事务、数据权限、数据缓存、SQL 日志等能力。数据引擎 DBrest 生成的 SQL 语句,经过数据代理再在物理数据库执行。

数据代理可以理解为是整个租户下所有应用的数据访问中间件,因此租户下需要有一个微服务来承载这个功能。由于用户权限是由门户微服务来提供的,数据代理要处理数据权限的事情,因此平台使用门户来提供数据代理这个能力。同时使用时需要保证门户是正常运行的,否则数据代理这块会访问异常造成一些问题的出现。

undefined

应用访问数据库是默认开启数据代理的。如果不需要使用数据代理(比如没有分布式事务、数据权限等使用需求),也可以手动进行关闭。

数据代理的使用,在应用访问日志可以查询到其代理时的日志。原来是访问应用自己的数据库,会转到门户进行访问。例子如下:

阶段 jdbc 例子
before jdbc:mysql://rds-mysql-instance4-svc.newdao-common:3306/20230616204149pnqrxu1k
after jdbc:mysql://entry.newdao-tenant-fxfdev:3307/20230616204149pnqrxu1k

以最常用的数据权限和分布式事务为例,说明数据代理的运作原理:

数据权限

以查询权限为例:

  • 如果用户没有该权限,则不执行 SQL,直接返回 403 异常。
  • 如果用户有该权限,同时数据权限配置了行权限( 带 where 条件),则 DBProxy 会修改原来的 SQL ,加上数据权限中额外配置的 where 条件,形成新的 SQL 再到数据库进行查询。这样实现了约束用户访问的权限效果。流程如下图所示:

1702439932549

分布式事务

平台在分布式事务方面,默认提供了两阶段事务提交模式, 通过事务管理器保证一个业务请求中多个微服务数据处理的事务完整性。设计人员只需要在请求的发起方, 开启分布式事务(使用注解), 每个微服务本身代码无需做任何改动, 即可实现多个微服务调用的事务一致性。

由于分布式事务是跨微服务执行,当某个应用发起事务时,将转到门户上统一执行事务处理。多个网络请求,是通过 request 中的 header 传递事务标识,表示这些请求都在同一个事务里边,这样事务管理器来对这一批请求实现 commit / rollback 操作。运行过程如下图所示:

1702436273409

数据库

最底层的数据库这块,平台的数据模型支持所有主流关系型数据库,包括信创的, 包括有 MySQL、 PostgreSQL、 Oracle、SQLServer、 DB2、 人大金仓、 达梦等。

应用的数据库分配主要有2种方式:

  • 系统分配的数据库

应用创建后默认会分配带时间戳的随机名称的实例,比如:20230420104951azmeh07v。

每个应用的每个开发者,都拥有独立的数据库实例,避免相互干扰。也就是说,开发阶段的同一个应用,开发者1打开应用会分配数据库实例1,开发者2会分配数据库实例2。如果大家都想使用同一个数据库实例方便调试,可以手动修改配置成同一个数据库实例,这里即可配置成系统分配的其中一个实例,也可以配置成外部的一个第三方实例。 1702296120108

  • 连接外部数据库

如果不想使用系统随机分配的数据库实例,用户可自行修改为外部的数据库连接。平台强烈建议生产环境配置成用户自己的数据库。 1702296271187

results matching ""

    No results matching ""