CN112115209A - 一种数据扩展的实现方法 - Google Patents

Abstract

本发明公开了一种数据扩展的实现方法，包括通过元数据驱动方案，动态配置元数据；所述元数据驱动方案，即通过对业务对象的数据结构元数据化描述，高度抽象实际数据的结构，借鉴MOF规范定义的概念进行设计；所述动态配置元数据，指的是对元数数据模型的配置，包括增删改一个元数据模型，并且生成最新版本号，则所有数据存储和接口服务都以最新配置在运行时自动调整，基本无需关注后端代码逻辑的修改，但可能需要对前端展示进行调整，但不包含对前端展示的元数据配置自动化适应实现。本发明通过元数据驱动方案，动态配置元数据，提高交付效率，增强业务扩展性。

Description

一种数据扩展的实现方法

技术领域

本发明涉及项目应用领域，特别涉及一种数据扩展的实现方法。

背景技术

随着业务的发展，应用的功能在不断变化，这种变化经常导致程序发生修改或能力的增加，比如某个业务对象增加了新的属性，或在原有功能之上增加了新的业务模块，或在原有功能之上增加了新的终端应用，这些无论是小范围的对象属性调整还是大面积的业务模块调整，都对开发流程带来了一定挑战，除了开发成本的消耗以及延迟响应带来的市场变动，还有随着代码改动带来未知的联动影响风险，所以面向类似有一定规律的、逻辑交互较为清晰的、对现有功能进行扩展的程序代码变动，需要从设计上让类似的功能实现能够在可控制、可配置的可视化环境下进行，从而降低影响及风险，提高产出效率。

发明内容

本发明的主要目的在于克服现有技术的缺点与不足，提供一种数据扩展的实现方法，该方法通过元数据驱动方案，动态配置元数据，提高交付效率，增强业务扩展性。

本发明的目的通过以下的技术方案实现：

一种数据扩展的实现方法，包括通过元数据驱动方案，动态配置元数据；

所述元数据为业务信息的概念与连接，表示数据的数据；

在逻辑层面，所述元数据驱动方案，即通过对业务对象的数据结构元数据化描述，高度抽象实际数据的结构，借鉴MOF规范定义的概念进行设计，不仅支持从数据资产进行元数据化管理，而且也能从对象、接口进行管理，从模型实例、模型、元模型、元元模型四层理论充分解耦不同业务对象的结构，使其在一套元数据框架下能够读写并且在运行时进行业务整合，从而提供业务服务；

所述动态配置元数据，指的是对元数数据模型的配置，包括增删改一个元数据模型，并且生成最新版本号，则所有数据存储和接口服务都以最新配置在运行时自动调整，基本无需关注后端代码逻辑的修改，但可能需要对前端展示进行调整(如果涉及)，但不包含对前端展示的元数据配置自动化适应实现。

元数据驱动方案中，所述数据资产包括表、字段。

元数据驱动方案中，所述对象包括类模型、属性。

元数据驱动方案中，所述接口输入接口、输出接口。

在实际应用层面，所述元数据在实际设计方案中，分为元数据模型(简称元模型)及元数据实例两大部分结构；所述元数据模型又分为对象(表、接口)元数据、属性(字段、参数)元数据；元数据实例则是元数据模型描述下实际事物数据的存储。

所述数据扩展包括应用对象属性扩展、业务结构扩展、虚拟应用扩展。

所述应用对象属性扩展，是指：对已有的应用业务对象，满足其属性扩展需要，所述属性扩展需要包括增加部分属性描述；则增加的部分，无论在存储形式上还是接口形式上，则都通过元数据的方式存取，并且建立与原对象之前的关联。

所述业务结构扩展，是指：对于应用本身不存在的业务对象，则完全依赖元数据驱动设计方案来实现业务的落地，包括在客户业务当中，随着业务发展，目前需要记录来访客户的跟进记录明细以便来精准分析客户，那么客户跟进记录则可以通过元数据驱动设计来实现数据的存取，并且建立起该对象与其他已存在的对象的关系后自动生成API接口，而基本无需再实现其他代码部分，或者如有其他复杂逻辑时，也能节省很大一部分编码时间。

所述与其他已存在的对象包括已存在的其他元数据对象实例。

所述虚拟应用扩展，是指：与所述业务结构扩展类似，通过元数据驱动设计，将一个应用或一个端建立在元数据模型之上，只不过复杂度有所增加，因为该应用内具有多个业务结构扩展，并且需要准确记录每个业务扩展之间的关系，然后生成API接口，以供其他服务调用或前端调用展示。

所述数据扩展的实现方法，还提供可视化入口，可视化入口包括：

(1)元数据本身的API管理，包括对象元数据、属性元数据本身的API管理；

(2)业务元数据API，业务一旦创建，运行时便会生成具体业务的AP，而不是通过传参的方式以及元数据接口来操作业务；

(3)集成API，元数据结合已有标准业务数据，统一打造集成平台，实现集成标准接口；

(4)辅助API，包括索引、唯一约束、全文检索、跨表查询。

所述元数据驱动方案，通过MPR(元数据处理运行时服务)来实现查询的优化和全文检索的性能问题，并且MPR也会提供业务整合能力，降低服务使用方对元数据模块的感知，保证开发体验；通过MPR的MetaAPl来提供通用解稠的完整的接口能力，为业务扩展提供标准化支持。

所述MPR内部数据处理流程为：将设置的业务对象激活并初始化的地方，依次处理顺序为：生成业务API(仅首次)→创建业务上下文Context→绑定数据修改Handler→绑定辅助索引Handler→绑定辅助唯一约束；当业务运行时，则会根据注册的Handler调用handle执行；Handler执行的时候，会根据Filter依次执行，Filter为链式结构，在绑定Handler时注入；不同的Handler处理完后，会根据设置判断是否发出一个Event，该Event根据Handler类型不同而不同，Event对应的监听者为Action。

所述MPR包括以下功能：MetaAPl(元数据接口服务)、业务整合、查询优化、全文检索；

所述MetaAPl是元数据服务的重要组成部分，负责所有与元数据服务通信的接口管理；所述元数据服务不是一个SDK客户端组件，是需要独立部署的；同时，元数据服务没有对调用者提供SDK包，而是通过Http Rest的方式对外提供服务；MetaAPI分为“模型操作API”和“数据实例API”两部分：“模型操作API”用于元数据模型自身的数据结构维护和对应接口实现；而“数据实例API”主要用于元数据实例的维护；

所述业务整合，属于MetaAPI的功能之一，是“数据实例API”的一部分，若使用了元数据的方式来存取客户，则MetaAPI的“数据实例API”中的业务整合组件就会自动生成客户API，并使其输入输出转换为客户对象的属性描述，而不是元数据格式的描述；

所述全文检索是使用第三方中间件ElasticSearch来实现。

所述查询优化，包括以下三种情形：

(1)更新元数据模型

1-1、判断当前模型的Context是否已创建：若是，则转到步骤1-2；若否，则读取模型信息，创建Context，并转到步骤1-2；

1-2、读取Context，判断是否创建索引：若是，则创建元数据索引；若否，则转到元数据模型；

1-3、判断是否参与全文检索，如是，则执行全文检索；

(2)新增或更新元数据实例

2-1、判断当前模型的Context是否已创建：若是，则转到步骤2-2；若否，则读取模型信息，创建Context，并转到步骤2-2；

2-2、读取Context，判断是否更新索引：若是，则更新元数据索引；若否，则根据模型规则创建全局Data_ID，然后判断模型是否单独存储、模型是否分库分表，最后转入元数据实例并日志同步；

2-3、判断是否参与全文检索，如是，则执行全文检索；

(3)查询元数据实例

3-1、判断当前模型的Context是否已创建：若是，则转到步骤3-2；若否，则读取模型信息，创建Context，并转到步骤3-2；

3-2、读取Context，查询元数据缓存；同时进行索引分析，并转到步骤3-3；

3-3、进行分库分表键检查，判断是否参与全文检索，如是，则执行全文检索。

本发明与现有技术相比，具有如下优点和有益效果：

1、本发明通用的业务数据会抽象存储于标准业务对象之中,当出现业态或某业务上个性化需求时,则基于标准业务数据以元数据的方式创建扩展信息,并会在公共元数据中记录下映射关系。元数据创建和编辑时,指定必填字段,其中包含租户和业态,甚至组织架构信息,以此来区分业务和数据权限。当个性化元数据从前台应用入口写入数据时,则会在数据表中存储,并且校验必填字段信息。

本发明的元数据的组成，是动态自定义的，但元数据的存储本身有其相应的要求，比如扩展一个员工的年龄属性，我们要求的是必须是整数，并且介于0～120之间；扩展一个员工的部门属性，我们要求必须是已存在的组织，并且能够查询到其上下级关系；等等。对元数据(如员工属性)的限制即为元模型(如员工模型)的限制。除此之外，还有一些基础的默认的限制，比如需要知道每个元数据的添加人、添加时间、元数据所属组织或业务线等，一般来说，这些都属于基本要求，因为元数据本身也有审计和权限管理。

2、本发明通过MPR即元数据处理运行时服务,来实现查询的优化和全文检索的性能问题,并且MPR也会提供业务整合能力,降低服务使用方对元数据模块的感知,保证开发体验。通过MPR提供的MetaAPl提供通用解稠的完整的接口能力,为业务扩展提供标准化支持。

3、当扩展的业务数据不断产生,达到单台数据服务器的上限时，本发明则需要考虑针对扩展的业务数据进行分库分表处理,并且要考虑扩展数据拆分键与标准业务数据拆分键的切换粘合,避免拆分键的变化导致全表扫描,性能低下。元数据会为所有扩展的业务数据创建全局ID,并且能够在ID中插入业务含义,即实现全局唯一性又携带业务信息,避免无用的查询。

附图说明

图1是本发明所述一种数据扩展的实现方法对应的底层架构图。

图2是MPR整体逻辑图。

图3是查询优化的流程图。

具体实施方式

下面结合实施例及附图对本发明作进一步详细的描述，但本发明的实施方式不限于此。

一种数据扩展的实现方法，包括通过元数据驱动方案，动态配置元数据；

元数据可以简单理解为：业务信息的概念与连接，表示数据的数据。元数据驱动方案，即通过对业务对象的数据结构元数据化描述，高度抽象实际数据的结构，借鉴MOF规范定义的概念进行设计，不仅支持从数据资产(表、字段)进行元数据化管理、也能从对象(类模型、属性)、接口(输入输出)等范畴进行管理，从模型实例、模型、元模型、元元模型4层理论充分解耦不同业务对象的结构，使其在一套元数据框架下能够读写并且在运行时进行业务整合，从而提供业务服务。

元数据在实际设计方案中，分为元数据模型(简称元模型)及元数据实例两大部分结构。而元数据模型又分为对象(表、接口)元数据、属性(字段、参数)元数据；元数据实例则是元数据模型描述下实际事物数据的存储。动态配置元数据，指的是对元数数据模型的配置，比如增删改一个元数据模型，并且生成最新版本号，则所有数据存储和接口服务都以最新配置在运行时自动调整，基本无需关注后端代码逻辑的修改，但可能需要对前端展示进行调整(如果涉及)，目前不包含对前端展示的元数据配置自动化适应实现。

使用元数据设计模式，可以根据M0层的用户实际对象,层层递归，形成N层元数据构对象模型，但是从实际需要和理解难度上来说，一般来说，4层足够满足设计需要。同样，4层也不是必须的层次抽象限制，也可以做到2层或3层。比如一般情况下，在使用关系型数据库强表示业务逻辑时，实际上相当于是2层。

例如，4层元数据构对象模型设计如下：

1、M3层,元元模型层。该层表示元模型中各组成元素之间的描述，以及其关系。

如File.class自身有哪些属性、什么类型以及关系。

如用户表结构中字段本身的属性、类型以及关系。

2、M2层,元模型层。它表示的是模型自身的属性信息，是对M1层的模型的描述。

如File或Folder对应的类、文件的属性以及这些元素之间的关系，类型等，就像File.class。

如描述用户模型或用户表有哪些字段、什么类型、约束等。

3、M1层,模型层。包含各类模型,是对M0层的抽象，它们的结构是元模型层结构的实例。

例子1:如File类、Folder类。

例子2:如用户模型或用户表结构。

4、M0层,对象和数据。体现现实世界中的事物对象模型构造的实例。

例子1：如文件“详细设计说明书.doc”、文件夹“我的文档"等。

例子2：如张三的用户信息。

如图1，元数据驱动设计满足应用对象属性扩展、业务结构扩展、虚拟应用扩展这三种情形，具体如下：

(1)应用对象属性扩展：对已有的应用业务对象，可以满足其属性扩展需要，比如增加部分属性描述，则增加的部分，无论在存储形式上还是接口形式上，则都通过元数据的方式存取，并且建立与原对象之前的关联。

以扩展用户信息为例，比如某系统用户当前的信息为：

用户：[用户ID、用户姓名、用户昵称、出生年月、用户邮箱、登录名、登录密码、用户类型]，随着业务的扩展以及市场或行业的变化，现需要支持用户使用手机号进行登录，并且需要对用户进行认证。按照以前的方式，一般步骤简述如下：

步骤一：和产品人员沟通清楚业务需求，确定需要记录用户的手机号、证件类型、证件号、地址信息、是否认证信息

步骤二：在数据库中，找到用户表，增加手机号、证件类型、证件号、地址信息、是否认证字段

步骤三：在代码中对应的用户对象中，也增加手机号、证件类型、证件号、地址信息、是否认证属性

步骤四：修改sql语句，在对应的查询及新增或更新语句中，增加手机号、证件类型、证件号、地址信息、是否认证字段

步骤五：修改代码中使用到用户对象的地方，补充新增字段的查询与赋值(新增、更新)逻辑。

步骤六：修改代码实现手机号登录、用户认证功能

步骤六：单元测试

步骤七：前端修改对应的接口为最新接口

步骤八：回归功能测试

如使用本专利中的方案，则步骤如下：

步骤一：和产品人员沟通清楚业务需求，确定需要记录用户的手机号、证件类型、证件号、地址信息、是否认证信息

步骤二：通过界面或操作数据库创建用户扩展表，记录扩展表的信息及扩展表的字段属性信息

步骤三：通过界面生成新的用户接口

步骤四：修改代码实现手机号登录、用户认证

步骤五：前端修改对应的接口为最新接口

步骤六：回归功能测试

通过对比，可以发现，使用本方案节省了原有步骤中的三、四、五步骤，而这三个步骤却是工作量最大、风险最大的步骤。

(2)业务结构扩展：对于应用本身不存在的业务对象，则完全可以依赖元数据驱动设计方案来实现业务的落地，比如客户业务当中，随着业务发展，目前需要记录来访客户的跟进记录明细以便来精准分析客户，那么客户跟进记录则可以通过元数据驱动设计来实现数据的存取，并且建立起该对象与其他已存在的对象(包括已存在的其他元数据对象实例)的关系后自动生成API接口，而基本无需再实现其他代码部分，或者如有其他复杂逻辑时，也能节省很大一部分编码时间。

以扩展用户类型为例，比如某系统用户当前的信息为：

用户：[用户ID、用户姓名、用户昵称、出生年月、用户邮箱、登录名、登录密码、用户类型]，用户类型为[商城C端用户]，随着业务的扩展以及市场或行业的变化，现需要支持新的用户类型为[商家用户]，商家用户与C端用户有很大区别，对于商家用户，业务上需要记录的属性为：[用户ID、商家名称、商家地址、商家类型、商家星级、商家账户、管理员账号、账号密码、用户类型]。按照以前的方式，一般步骤简述如下：

步骤一：和产品人员沟通清楚业务需求，确定需要增加一种新的用户类型，该类型表示B端用户，其信息为：用户ID、商家名称、商家地址、商家类型、商家星级、商家账户、管理员账号、账号密码、用户类型

步骤二：在数据库中，新建一个商家表，字段为：用户ID、商家名称、商家地址、商家类型、商家星级、商家账户、管理员账号、账号密码。

步骤三：在代码中增加的商家用户对象，对象属性为：用户ID、商家名称、商家地址、商家类型、商家星级、商家账户、管理员账号、账号密码。

步骤四：增加对商家用户信息增删改查的sql语句。

步骤五：增加对商家用户信息维护的代码逻辑。

步骤六：修改代码实现商家注册与登录。

步骤六：单元测试

步骤七：前端对接商家用户接口

步骤八：功能测试

如使用本专利中的方案，则步骤如下：

步骤一：和产品人员沟通清楚业务需求，确定需要增加一种新的用户类型，该类型表示B端用户，其信息为：用户ID、商家名称、商家地址、商家类型、商家星级、商家账户、管理员账号、账号密码、用户类型。

步骤二：通过界面或操作数据库创建用户商家扩展表，记录扩展表的信息及扩展表的字段属性信息

步骤三：通过界面生成新的商家用户接口

步骤四：修改代码实现商家登录。

步骤五：前端对接商家用户注册与接口。

步骤六：功能测试。

通过对比，可以发现，使用本方案节省了原有步骤中的三、四、五步骤，而这三个步骤却是工作量最大、风险最大的步骤。

(3)虚拟应用扩展：与“业务结构扩展”类似，通过元数据驱动设计，可以将一个应用(或一个端)建立在元数据模型之上，只不过复杂度有所增加，因为该应用内具有多个“业务结构扩展”，并且需要准确记录每个业务扩展之间的关系，然后生成API接口，以供其他服务调用或前端调用展示。

以扩展用户端为例，比如某系统用户当前的信息为：

用户：[用户ID、用户姓名、用户昵称、出生年月、用户邮箱、登录名、登录密码、用户类型]，用户类型为[商城C端用户]，随着业务的扩展以及市场或行业的变化，现需要支持新的用户类型为[商家用户]，并且商家具有其特定的操作页面和功能集合，所以需要单独实现一个商家端以供系统上的商家使用。这种场景下，则是多个业务结构扩展的集合，按照以前的方式，一般步骤简述如下：

步骤一：和产品人员沟通清楚业务需求，确定需要增加一种新的应用端，为商家管理其商品和账单等使用。

步骤二：在数据库中，新建一个商家表、商家账单表、商家商品表。

步骤三：在代码中增加的商家用户对象、商家账单对象、商家商品对象。

步骤四：增加对商家用户信息、商家账单信息、商家商品信息增删改查的sql语句。

步骤五：增加对商家用户信息、商家账单信息、商家商品信息维护的代码逻辑。

步骤六：修改代码实现商家登录、商家账单管理、商家商品管理。

步骤六：单元测试

步骤七：前端对接商家接口，实现商家端

步骤八：功能测试

如使用本专利中的方案，则步骤如下：

步骤一：和产品人员沟通清楚业务需求，确定需要增加一种新的应用端，为商家管理其商品和账单等使用。

步骤二：通过界面或操作数据库创建用户商家扩展表、商家账单扩展表、商家商品扩展，记录扩展表的信息及扩展表的字段属性信息

步骤三：通过界面生成新的商家用户、商家账单、商家商品接口

步骤四：修改代码实现商家登录、商家账单管理、商家商品管理。

步骤五：前端对接商家接口，实现商家端。

步骤六：功能测试。

通过对比，可以发现，使用本方案节省了原有步骤中的三、四、五步骤，而这三个步骤却是工作量最大、风险最大的步骤。

所述数据扩展的实现方法，还提供可视化入口，可视化入口包括：

1)元数据本身的API管理,如对象元数据、属性元数据。

2)业务元数据API,业务一旦创建,运行时便会生成具体业务的AP,而不是通过传参的方式通过元数据接口来操作业务。

3)集成API,元数据结合已有标准业务数据,统一打造集成平台,实现集成标准接口。

4)辅助API,如索引、唯一约束、全文检索、跨表查询等。

所述数据扩展的实现方法，还提供业务整合器，通过该整合器，实现应用或服务开发者对元数据弱感知甚至无感知支持业务使用的完整性和流畅性。

所述元数据驱动方案，还包括运行时引擎：将设置的业务对象激活并初始化的地方，依次处理顺序为：生成业务API(仅首次)→创建业务上下文Context→绑定数据修改Handler→绑定辅助索引Handler→绑定辅助唯一约束。

当业务运行时，则会根据注册的Handler调用handle执行。Handler执行的时候，会根据Filter依次执行，Filter为链式结构，在绑定Handler时注入。不同的Handler处理完后，会根据设置判断是否发出一个Event，该Event根据Handler类型不同而不同，Event对应的监听者为Action。

1)Handler:元数据引擎充斥着Handler，用来进行一些数据的处理。Handler分为同步和异步两种，同步用来处理一些必须等待返回的逻辑，异步用于非必须返回的大数据处理、回调等。

2)Filter:Handler的内部对象，用来在Handler处理数据时，进行相关过滤操作。分为PreFilter,PostFilter两类，分别在handle前后调用。

3)Event:事件对象，上面描述为Handler发出，但打算作为全局机制，也用于引擎中其他需要事件的地方。

4)Action:事件处理者，该处理者分为InternalAction、RestAction，分别用于平台内部以及外部集成系统。

图2展示了MPR内部的当前组成以及各组件之间的关系。下面就MPR的4大重点功能进行细化描述：

一、MetaAPl(元数据接口服务)：

在本实施例中的元数据驱动设计，元数据服务它不是一个SDK客户端组件，是需要独立部署的。同时，元数据服务没有对调用者提供SDK包，而是通过Http Rest的方式对外提供服务，而MetaAPI作为元数据服务的重要组成部分，负责所有与元数据服务通信的接口管理。从上面的图可以得知，MetaAPI分为“模型操作API”和“数据实例API”两部分；“模型操作API”主要用于元数据模型自身的数据结构维护和对应接口实现；而“数据实例API”主要用于元数据实例的维护。比如：元模型“客户”，“模型操作API”则负责“客户”模型结构的维护，如增加一个客户属性，或更新已有一个客户属性的的信息；而“数据实例API”则负责对客户数据的增删查改操作，如新增一个客户信息，或更新已有客户信息。

二、业务整合：业务整合在当前也属于MetaAPI的功能之一，是“数据实例API”的一部分，再如“客户模型”，一旦使用了元数据的方式来存取客户，则MetaAPI的“数据实例API”中的业务整合组件就会自动生成客户API，并使其输入输出转换为客户对象的属性描述，而不是元数据格式的描述。

对象属性描述方式如下：

请求url:v1/customer/{id}

Customer:{

“name”:“张三”,

“age”:22,

“address”:“中国广东省广州市”,

…}

对象元数据描述方式如下：

objData:[

{“attr_id”:1,“attr_name”:“name”,“attr_value”:“张三”,…}

{“attr_id”:2,“attr_name”:“age”,“attr_value”:“22”,…}

{“attr_id”:3,“attr_name”:“address”,

“attr_value”:“中国广东省广州市”,…

}，

…]

三、查询优化：如图3，包括以下三种情形：

(1)更新元数据模型

1-1、判断当前模型的Context是否已创建：若是，则转到步骤1-2；若否，则读取模型信息，创建Context，并转到步骤1-2；

1-2、读取Context，判断是否创建索引：若是，则创建元数据索引；若否，则转到元数据模型；

1-3、判断是否参与全文检索，如是，则执行全文检索；

(2)新增或更新元数据实例

2-1、判断当前模型的Context是否已创建：若是，则转到步骤2-2；若否，则读取模型信息，创建Context，并转到步骤2-2；

2-2、读取Context，判断是否更新索引：若是，则更新元数据索引；若否，则根据模型规则创建全局Data_ID，然后判断模型是否单独存储、模型是否分库分表，最后转入元数据实例并日志同步；

2-3、判断是否参与全文检索，如是，则执行全文检索；

(3)查询元数据实例

3-1、判断当前模型的Context是否已创建：若是，则转到步骤3-2；若否，则读取模型信息，创建Context，并转到步骤3-2；

3-2、读取Context，查询元数据缓存；同时进行索引分析，并转到步骤3-3；

3-3、进行分库分表键检查，判断是否参与全文检索，如是，则执行全文检索。

四、全文检索：使用第三方中间件ElasticSearch进行全文检索的实现。

上述实施例为本发明较佳的实施方式，但本发明的实施方式并不受上述实施例的限制，其他的任何未背离本发明的精神实质与原理下所作的改变、修饰、替代、组合、简化，均应为等效的置换方式，都包含在本发明的保护范围之内。

Claims (10)

1.一种数据扩展的实现方法，其特征在于，包括通过元数据驱动方案，动态配置元数据；

所述元数据为业务信息的概念与连接，表示数据的数据；

在逻辑层面，所述元数据驱动方案，即通过对业务对象的数据结构元数据化描述，高度抽象实际数据的结构，借鉴MOF规范定义的概念进行设计，不仅支持从数据资产进行元数据化管理，而且也能从对象、接口进行管理，从模型实例、模型、元模型、元元模型四层理论充分解耦不同业务对象的结构，使其在一套元数据框架下能够读写并且在运行时进行业务整合，从而提供业务服务；

所述动态配置元数据，指的是对元数数据模型的配置，包括增删改一个元数据模型，并且生成最新版本号，则所有数据存储和接口服务都以最新配置在运行时自动调整，基本无需关注后端代码逻辑的修改，但可能需要对前端展示进行调整，但不包含对前端展示的元数据配置自动化适应实现。

2.根据权利要求1所述数据扩展的实现方法，其特征在于，所述数据扩展包括应用对象属性扩展、业务结构扩展、虚拟应用扩展。

3.根据权利要求2所述数据扩展的实现方法，其特征在于，所述应用对象属性扩展，是指：对已有的应用业务对象，满足其属性扩展需要，所述属性扩展需要包括增加部分属性描述；则增加的部分，无论在存储形式上还是接口形式上，则都通过元数据的方式存取，并且建立与原对象之前的关联。

4.根据权利要求2所述数据扩展的实现方法，其特征在于，所述业务结构扩展，是指：对于应用本身不存在的业务对象，则完全依赖元数据驱动设计方案来实现业务的落地，包括在客户业务当中，随着业务发展，目前需要记录来访客户的跟进记录明细以便来精准分析客户，那么客户跟进记录则可以通过元数据驱动设计来实现数据的存取，并且建立起该对象与其他已存在的对象的关系后自动生成API接口，而基本无需再实现其他代码部分，或者如有其他复杂逻辑时，也能节省很大一部分编码时间。

5.根据权利要求2所述数据扩展的实现方法，其特征在于，所述虚拟应用扩展，是指：与所述业务结构扩展类似，通过元数据驱动设计，将一个应用或一个端建立在元数据模型之上，只不过复杂度有所增加，因为该应用内具有多个业务结构扩展，并且需要准确记录每个业务扩展之间的关系，然后生成API接口，以供其他服务调用或前端调用展示。

6.根据权利要求1所述数据扩展的实现方法，其特征在于，还提供可视化入口，可视化入口包括：

(1)元数据本身的API管理，包括对象元数据、属性元数据本身的API管理；

(2)业务元数据API，业务一旦创建，运行时便会生成具体业务的API，而不是通过传参的方式以及元数据接口来操作业务；

(3)集成API，元数据结合已有标准业务数据，统一打造集成平台，实现集成标准接口；

(4)辅助API，包括索引、唯一约束、全文检索、跨表查询。

7.根据权利要求1所述数据扩展的实现方法，其特征在于，所述元数据驱动方案，通过MPR来实现查询的优化和全文检索的性能问题，并且MPR也会提供业务整合能力，降低服务使用方对元数据模块的感知，保证开发体验；通过MPR的MetaAPl来提供通用解稠的完整的接口能力，为业务扩展提供标准化支持。

8.根据权利要求7所述数据扩展的实现方法，其特征在于，所述MPR内部数据处理流程为：将设置的业务对象激活并初始化的地方，依次处理顺序为：生成业务API→创建业务上下文Context→绑定数据修改Handler→绑定辅助索引Handler→绑定辅助唯一约束；当业务运行时，则会根据注册的Handler调用handle执行；Handler执行的时候，会根据Filter依次执行，Filter为链式结构，在绑定Handler时注入；不同的Handler处理完后，会根据设置判断是否发出一个Event，该Event根据Handler类型不同而不同，Event对应的监听者为Action。

9.根据权利要求7所述数据扩展的实现方法，其特征在于，所述MPR包括以下功能：MetaAPl、业务整合、查询优化、全文检索；

所述MetaAPl是元数据服务的重要组成部分，负责所有与元数据服务通信的接口管理；所述元数据服务不是一个SDK客户端组件，是需要独立部署的；同时，元数据服务没有对调用者提供SDK包，而是通过Http Rest的方式对外提供服务；MetaAPI分为“模型操作API”和“数据实例API”两部分：“模型操作API”用于元数据模型自身的数据结构维护和对应接口实现；而“数据实例API”主要用于元数据实例的维护；

所述业务整合，属于MetaAPI的功能之一，是“数据实例API”的一部分，若使用了元数据的方式来存取客户，则MetaAPI的“数据实例API”中的业务整合组件就会自动生成客户API，并使其输入输出转换为客户对象的属性描述，而不是元数据格式的描述；

所述全文检索是使用第三方中间件ElasticSearch来实现。

10.根据权利要求9所述数据扩展的实现方法，其特征在于，所述查询优化，包括以下三种情形：

(1)更新元数据模型

1-1、判断当前模型的Context是否已创建：若是，则转到步骤1-2；若否，则读取模型信息，创建Context，并转到步骤1-2；

1-2、读取Context，判断是否创建索引：若是，则创建元数据索引；若否，则转到元数据模型；

1-3、判断是否参与全文检索，如是，则执行全文检索；

(2)新增或更新元数据实例

2-1、判断当前模型的Context是否已创建：若是，则转到步骤2-2；若否，则读取模型信息，创建Context，并转到步骤2-2；

2-2、读取Context，判断是否更新索引：若是，则更新元数据索引；若否，则根据模型规则创建全局Data_ID，然后判断模型是否单独存储、模型是否分库分表，最后转入元数据实例并日志同步；

2-3、判断是否参与全文检索，如是，则执行全文检索；

(3)查询元数据实例

3-1、判断当前模型的Context是否已创建：若是，则转到步骤3-2；若否，则读取模型信息，创建Context，并转到步骤3-2；

3-2、读取Context，查询元数据缓存；同时进行索引分析，并转到步骤3-3；

3-3、进行分库分表键检查，判断是否参与全文检索，如是，则执行全文检索。

Images