CN110851512B - 用于开源框架的数据配置方法及装置 - Google Patents

Abstract

本申请公开了一种用于开源框架的数据配置方法及装置。该方法包括：获取业务系统的配置信息，所述配置信息包括功能接口信息和数据存储信息，所述业务系统包括第一业务系统和第二业务系统；判断在所述第一业务系统的配置信息中是否可以匹配到所述第二业务系统的配置信息；根据判断结果确定是否要在所述第一业务系统中更新所述配置信息。本申请解决了相关技术中的微服务架构由于缺少对不同业务系统的数据进行有效管理而导致的系统运维成本较高的技术问题。通过本申请，达到了对不同业务系统的数据进行有效管理的目的，从而实现了降低业务系统运维成本的技术效果。

Description

用于开源框架的数据配置方法及装置

技术领域

本申请涉及微服务技术领域，具体而言，涉及一种用于开源框架的数据配置方法及装置。

背景技术

随着信息技术的飞速发展，目前大部分的信息技术公司都需要使用各种各样的系统完成公司内的各项任务以及统计保存公司的各种数据，例如办公自动化系统(OA系统)、运维系统、工单系统、需求管理系统、发布系统、邮箱系统等各种各样的系统。有些系统可能是公司自主研发，有些也可能使用外部开源框架。

对于公司内部自主研发的系统，可以使用统一用户中心实现各个子系统的用户注册、登录校验、登录状态判断等相关功能。但是对于外部开源框架搭建的系统，通常由于该类系统自己存在对应的用户注册、登录模块，用户在进行注册时，由于该类系统对于用户名、邮箱等相关信息的限制与公司内部的统一用户中心的限制不同，以及开源系统中用户存储的数据与统一用户中心存储的相关数据不一致，导致用户需要在内部系统和对应开源系统注册两次，同时为了对应相关用户名，需要在统一用户中心建立一份用户中心的用户账号与对应开源系统用户账号的对应关系表。

发明人发现，相关技术中的微服务系统至少存在如下问题：1)用户需要申请至少两个账号，同时还需要开源系统的账号与公司用户中心的账号进行绑定；2)需要两套账号系统，各自处理自己相关的登录注册等各种用户信息相关功能，同时需要保存两份账号信息以及关联的数据，运维难度和成本较高；3)在统计数据时，需要将开源系统的数据统计完成后，然后从公司用户中心的账号对应关系表找出对应关系再进行数据对齐合并，统计不方便。

针对相关技术中的微服务架构由于缺少对不同业务系统的数据进行有效管理而导致的系统运维成本较高的问题，目前尚未提出有效的解决方案。

发明内容

本申请的主要目的在于提供一种用于开源框架的数据配置方法及装置，以解决相关技术中的微服务架构由于缺少对不同业务系统的数据进行有效管理而导致的系统运维成本较高的问题。

为了实现上述目的，根据本申请的一个方面，提供了一种用于开源框架的数据配置方法。

根据本申请的用于开源框架的数据配置方法包括：获取业务系统的配置信息，所述配置信息包括功能接口信息和数据存储信息，所述业务系统包括统一用户中心和开源框架业务系统；判断在所述统一用户中心的配置信息中是否可以匹配到所述开源框架业务系统的配置信息；根据判断结果确定是否要在所述统一用户中心中更新所述配置信息。

进一步地，所述获取业务系统的配置信息之后包括：判断在所述统一用户中心的功能接口信息中是否可以匹配到所述开源框架业务系统的功能接口信息；如果不可以，则根据判断结果确定所述统一用户中心的功能接口信息中缺失的功能接口信息；将所述缺失的功能接口信息填充至所述统一用户中心的功能接口信息中。

进一步地，所述获取业务系统的配置信息之后包括：判断在所述统一用户中心的数据存储信息中是否可以匹配到所述开源框架业务系统的数据存储信息；如果不可以，则根据判断结果确定所述统一用户中心的数据存储信息中缺失的数据存储信息；将所述缺失的数据存储信息填充至所述统一用户中心的数据存储信息中。

进一步地，所述根据判断结果确定是否要在所述统一用户中心中更新所述配置信息之后包括：接收用户端发送的服务调用请求，所述服务调用请求是指所述用户端用于调用所述开源框架业务系统的服务的请求；将所述服务调用请求转发至所述统一用户中心；根据更新后的所述配置信息将所述统一用户中心的服务调用结果返回至用户端。

进一步地，所述根据判断结果确定是否要在所述统一用户中心中更新配置信息之后包括：通过所述开源框架业务系统获取用户端发送的服务调用请求；确定所述开源框架业务系统的系统ID信息；基于所述开源框架业务系统的系统ID信息，通过反向代理将所述服务调用请求转发至所述统一用户中心。

为了实现上述目的，根据本申请的另一方面，提供了一种用于开源框架的数据配置。

根据本申请的用于开源框架的数据配置包括：第一获取模块，用于获取业务系统的配置信息，所述配置信息包括功能接口信息和数据存储信息，所述业务系统包括统一用户中心和开源框架业务系统；第一判断模块，用于判断在所述统一用户中心的配置信息中是否可以匹配到所述开源框架业务系统的配置信息；第一确定模块，用于根据判断结果确定是否要在所述统一用户中心中更新所述配置信息。

进一步地，所述装置还包括：第二判断模块，用于判断在所述统一用户中心的功能接口信息中是否可以匹配到所述开源框架业务系统的功能接口信息；第二确定模块，用于如果不可以，则根据判断结果确定所述统一用户中心的功能接口信息中缺失的功能接口信息；第一填充模块，用于将所述缺失的功能接口信息填充至所述统一用户中心的功能接口信息中。

进一步地，还包括：第三判断模块，用于判断在所述统一用户中心的数据存储信息中是否可以匹配到所述开源框架业务系统的数据存储信息；第三确定模块，用于如果不可以，则根据判断结果确定所述统一用户中心的数据存储信息中缺失的数据存储信息；第二填充模块，用于将所述缺失的数据存储信息填充至所述统一用户中心的数据存储信息中。

进一步地，所述装置还包括：接收模块，用于接收用户端发送的服务调用请求，所述服务调用请求是指所述用户端用于调用所述开源框架业务系统的服务的请求；第一转发模块，用于将所述服务调用请求转发至所述统一用户中心；返回模块，根据更新后的所述配置信息将所述统一用户中心的服务调用结果返回至用户端。

进一步地，所述装置还包括：第二获取模块，用于通过所述开源框架业务系统获取用户端发送的服务调用请求；第四确定模块，用于确定所述开源框架业务系统的系统ID信息；第二转发模块，用于基于所述开源框架业务系统的系统ID信息，通过反向代理将所述服务调用请求转发至所述统一用户中心。

在本申请实施例中，采用获取业务系统的配置信息，判断在所述统一用户中心的配置信息中是否可以匹配到所述开源框架业务系统的配置信息的方式，通过根据判断结果确定是否要在统一用户中心中更新配置信息，达到了对不同业务系统的数据进行有效管理的目的，从而实现了降低业务系统运维成本的技术效果，进而解决了相关技术中的微服务架构由于缺少对不同业务系统的数据进行有效管理而导致的系统运维成本较高的技术问题。

附图说明

构成本申请的一部分的附图用来提供对本申请的进一步理解，使得本申请的其它特征、目的和优点变得更明显。本申请的示意性实施例附图及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请第一实施例的用于开源框架的数据配置方法的流程示意图；

图2是根据本申请第二实施例的用于开源框架的数据配置方法的流程示意图；

图3是根据本申请第三实施例的用于开源框架的数据配置方法的流程示意图；

图4是根据本申请第四实施例的用于开源框架的数据配置方法的流程示意图；

图5是根据本申请第五实施例的用于开源框架的数据配置方法的流程示意图；

图6是根据本申请第一实施例的用于开源框架的数据配置装置的组成结构示意图；

图7是根据本申请第二实施例的用于开源框架的数据配置装置的组成结构示意图；

图8是根据本申请第三实施例的用于开源框架的数据配置装置的组成结构示意图；

图9是根据本申请第四实施例的用于开源框架的数据配置装置的组成结构示意图；以及

图10是根据本申请第五实施例的用于开源框架的数据配置装置的组成结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

根据本发明实施例，提供了一种用于开源框架的数据配置方法，如图1所示，该方法包括如下的步骤S101至步骤S103：

步骤S101，获取业务系统的配置信息，所述配置信息包括功能接口信息和数据存储信息，所述业务系统包括统一用户中心和开源框架业务系统。

相关技术中的业务系统类型主要有公司内部系统和外部开源框架系统等，对于存在于公司内部系统的员工账号与开源框架系统的员工账号，由于不同业务系统相关命名规则不一致，限制类型不一致，无法统一使用一套账号进行注册，导致各个业务系统注册账号不尽相同，进而使得公司对多个业务系统的管理难度和运维难度加大。因此为了解决上述问题，本申请实施例提供了一种用于开源框架的数据配置方法，通过将开源框架系统中必须的用户功能模块迁移至公司统一用户中心的相关模块中，保证用户使用的开源系统的必须功能皆可以通过公司用户中心提供的功能来实现。

具体实施时，首先需要获取开源框架业务系统和公司内部业务系统的功能接口信息和数据存储信息，所述功能接口信息是指开源框架中存在的用户必须使用的接口信息以及公司内部业务系统内存在的所有功能接口信息，数据存储信息包括两个业务系统存储的数据表结构、数据类型及存储字段等信息。

公司内部业务系统主要是指公司统一用户中心，中心提供了公司内部用户登录、鉴权等各种用户操作的服务，同时保存了与其他业务系统用户账号对应的映射表，支持用户手动设置相关系统的账号，并由公司统一用户中心确认提交的数据是否存在。

步骤S102，判断在所述统一用户中心的配置信息中是否可以匹配到所述开源框架业务系统的配置信息。

具体实施时，在得到开源框架系统和公司内部系统的上述配置信息之后，将开源框架系统内用户必须使用的接口信息及对应的数据存储信息与公司内部系统的配置信息进行比较，判断在公司内部系统的配置信息中是否可以匹配到开源框架系统中用户在使用时必须的配置信息。

步骤S103，根据判断结果确定是否要在所述统一用户中心中更新所述配置信息。

具体实施时，如果在公司内部系统的配置信息中可以匹配到开源框架系统中用户在使用时必须的配置信息，则可以直接通过开源框架接收到的用户请求直接调用公司内部系统对应的接口，如果无法匹配到，则需要在公司内部业务系统中开发和配置相关的功能接口和数据存储信息，以保证开源框架系统中所有用户必须使用的配置信息在公司内部系统中均可以匹配到，用户仅需在公司内部系统中注册一次账号即可以实现对开源框架系统中相关功能的使用，使公司对多个业务系统的管理更加高效、便捷，降低了公司业务系统的运维成本。

作为本申请实施例的一种优选实施方式，如图2所示，所述获取业务系统的配置信息之后包括如下的步骤S201至步骤S203：

步骤S201，判断在所述统一用户中心的功能接口信息中是否可以匹配到所述开源框架业务系统的功能接口信息。

具体实施时，上述配置信息包括业务系统的功能接口信息，首先需要对比开源框架系统中涉及到用户相关的接口以及公司内部系统对应的接口。

步骤S202，如果不可以，则根据判断结果确定所述统一用户中心的功能接口信息中缺失的功能接口信息。

具体实施时，对于在开源框架系统中存在且用户必须的接口，如果在公司内部系统中存在对应接口，则直接复用对应的功能接口，在开源框架系统调用该功能接口时，自动带上开源框架系统的唯一系统ID标识。如果公司内部系统中不存在对应的功能接口，则将该接口记录为缺失的接口。

步骤S203，将所述缺失的功能接口信息填充至所述统一用户中心的功能接口信息中。

具体实施时，根据上述判断确定出相应的功能缺失接口信息后，需要将该信息进行归纳统计，之后对于缺失或者需要修改的接口进行统一设计开发以满足于对应开源框架系统功能接口接入的要求。

作为本申请实施例的一种优选实施方式，如图3所示，所述获取业务系统的配置信息之后包括如下的步骤S301至步骤S303：

步骤S301，判断在所述统一用户中心的数据存储信息中是否可以匹配到所述开源框架业务系统的数据存储信息。

具体实施时，上述配置信息包括业务系统的数据存储信息，所述数据存储信息包括业务系统存储的数据表结构、数据类型及存储字段等信息，首先需要对比开源框架系统中涉及到用户相关的数据存储信息以及公司内部系统对应的数据存储信息，判断是否可以在公司内部系统中匹配到开源框架系统中用户必须使用的数据存储信息。

步骤S302，如果不可以，则根据判断结果确定所述统一用户中心的数据存储信息中缺失的数据存储信息。

具体实施时，如果有些数据字段存在于开源框架系统中而公司内部系统未保存该字段，则需要记录该字段为缺失的数据字段。有些字段存在于公司内部系统中且为用户必填字段，而在开源系统中未存在该字段，则可以通过对开源框架系统填入空值或者统一的值来进行字段填充。

步骤S303，将所述缺失的数据存储信息填充至所述统一用户中心的数据存储信息中。

具体实施时，根据上述判断确定出相应的缺失的数据存储信息后，需要将该信息进行归纳统计，之后对于缺失或者需要修改的数据存储信息进行统一设计开发以满足于对应开源框架系统数据存储的要求。

作为本申请实施例的一种优选实施方式，如图4所示，所述根据判断结果确定是否要在所述统一用户中心中更新所述配置信息之后包括如下的步骤S401至步骤S403：

步骤S401，接收用户端发送的服务调用请求，所述服务调用请求是指所述用户端用于调用所述开源框架业务系统的服务的请求。

具体实施时，在配置好公司内部系统与开源框架系统相对应的功能接口信息和数据存储信息之后，获取用户发送的调用开源框架系统相关服务的请求。

步骤S402，将所述服务调用请求转发至所述统一用户中心。

具体实施时，在开源框架系统接收到用户的调用请求后，无需对用户的调用请求进行回应，而是将该请求转发至公司内部系统，由公司内部系统对用户的调用请求进行回应，即保证在公司内部系统中，所有开源框架系统中用户发送的服务调用请求都会被转发至公司内部系统中，且返回与开源框架系统对应接口一致的数据结果。

步骤S403，根据更新后的所述配置信息将所述统一用户中心的服务调用结果返回至用户端。

具体实施时，公司内部系统中配置了开源框架系统中用户必须使用的所有功能接口信息和数据存储信息，通过识别用户的调用请求调用公司内部系统中相应的功能接口并返回至用户端，同时将相应的数据信息按照对应开源框架系统的格式进行存储。

作为本申请实施例的一种优选实施方式，如图5所示，所述根据判断结果确定是否要在所述统一用户中心中更新配置信息之后包括如下的步骤S501至步骤S503：

步骤S501，通过所述开源框架业务系统获取用户端发送的服务调用请求。

具体实施时，通过开源框架系统获取用户发送的调用开源框架系统相关服务的请求。

步骤S502，确定所述开源框架业务系统的系统ID信息。

具体实施时，在转发用户端发送的服务调用请求时，需要带上当前开源框架系统唯一的系统ID，以便于公司内部系统进行对应系统信息的判断，在某些情况下，还需要进行参数加密以及对应数据的计算等。因此首先需要获取当前开源框架系统的系统ID信息。

步骤S503，基于所述开源框架业务系统的系统ID信息，通过反向代理将所述服务调用请求转发至所述统一用户中心。

具体实施时，在开源系统的接入层加入反向代理(类似于apache或者nginx等软件)，当接收到开源框架系统用户的调用请求并确定了该开源框架系统的ID信息之后，由对应的反向代理通过http 301转发，将旧的请求链接通过反向代理返回在公司内部系统对应接口的新链接，之后自动访问新链接，保证用户无感替换。

从以上的描述中，可以看出，本发明实现了如下技术效果：采用获取业务系统的配置信息，判断在所述统一用户中心的配置信息中是否可以匹配到所述开源框架业务系统的配置信息的方式，通过根据判断结果确定是否要在统一用户中心中更新配置信息，达到了对不同业务系统的数据进行有效管理的目的，从而实现了降低业务系统运维成本的技术效果。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

根据本发明实施例，还提供了一种用于实施上述用于开源框架的数据配置方法的装置，如图6所示，该装置包括：第一获取模块1、第一判断模块2和第一确定模块3。

本申请实施例的第一获取模块1，用于获取业务系统的配置信息，所述配置信息包括功能接口信息和数据存储信息，所述业务系统包括统一用户中心和开源框架业务系统。

具体实施时，首先需要通过第一获取模块获取开源框架业务系统和公司内部业务系统的功能接口信息和数据存储信息，所述功能接口信息是指开源框架中存在的用户必须使用的接口信息以及公司内部业务系统内存在的所有功能接口信息，数据存储信息包括两个业务系统存储的数据表结构、数据类型及存储字段等信息。

本申请实施例的第一判断模块2，用于判断在所述统一用户中心的配置信息中是否可以匹配到所述开源框架业务系统的配置信息。

具体实施时，在得到开源框架系统和公司内部系统的上述配置信息之后，通过第一判断模块将开源框架系统内用户必须使用的接口信息及对应的数据存储信息与公司内部系统的配置信息进行比较，判断在公司内部系统的配置信息中是否可以匹配到开源框架系统中用户在使用时必须的配置信息。

本申请实施例的第一确定模块3，用于根据判断结果确定是否要在所述统一用户中心中更新所述配置信息。

具体实施时，如果在公司内部系统的配置信息中可以匹配到开源框架系统中用户在使用时必须的配置信息，则可以直接通过开源框架接收到的用户请求直接调用公司内部系统对应的接口，如果无法匹配到，则需要在公司内部业务系统中开发和配置相关的功能接口和数据存储信息，以保证开源框架系统中所有用户必须使用的配置信息在公司内部系统中均可以匹配到，用户仅需在公司内部系统中注册一次账号即可以实现对开源框架系统中相关功能的使用，使公司对多个业务系统的管理更加高效、便捷，降低了公司业务系统的运维成本。

作为本申请实施例的一种优选实施方式，如图7所示，所述装置还包括：第二判断模块4、第二确定模块5和第一填充模块6。

本申请实施例的第二判断模块4，用于判断在所述统一用户中心的功能接口信息中是否可以匹配到所述开源框架业务系统的功能接口信息。

具体实施时，上述配置信息包括业务系统的功能接口信息，首先需要通过第二判断模块对比开源框架系统中涉及到用户相关的接口以及公司内部系统对应的接口。

本申请实施例的第二确定模块5，用于如果不可以，则根据判断结果确定所述统一用户中心的功能接口信息中缺失的功能接口信息。

具体实施时，对于在开源框架系统中存在且用户必须的接口，如果在公司内部系统中存在对应接口，则直接复用对应的功能接口，在开源框架系统调用该功能接口时，自动带上开源框架系统的唯一系统ID标识。如果公司内部系统中不存在对应的功能接口，则通过第二确定模块将该接口记录为缺失的接口。

本申请实施例的第一填充模块6，用于将所述缺失的功能接口信息填充至所述统一用户中心的功能接口信息中。

具体实施时，根据上述判断确定出相应的功能缺失接口信息后，需要将该信息进行归纳统计，之后通过第一填充模块对于缺失或者需要修改的接口进行统一设计开发以满足于对应开源框架系统功能接口接入的要求。

作为本申请实施例的一种优选实施方式，如图8所示，所述装置还包括：第三判断模块7、第三确定模块8和第二填充模块9。

本申请实施例的第三判断模块7，用于判断在所述统一用户中心的数据存储信息中是否可以匹配到所述开源框架业务系统的数据存储信息。

具体实施时，上述配置信息包括业务系统的数据存储信息，所述数据存储信息包括业务系统存储的数据表结构、数据类型及存储字段等信息，首先需要通过第三判断模块对比开源框架系统中涉及到用户相关的数据存储信息以及公司内部系统对应的数据存储信息，判断是否可以在公司内部系统中匹配到开源框架系统中用户必须使用的数据存储信息。

本申请实施例的第三确定模块8，用于如果不可以，则根据判断结果确定所述统一用户中心的数据存储信息中缺失的数据存储信息。

具体实施时，如果有些数据字段存在于开源框架系统中而公司内部系统未保存该字段，则需要记录该字段为缺失的数据字段。有些字段存在于公司内部系统中且为用户必填字段，而在开源系统中未存在该字段，则可以通过对开源框架系统填入空值或者统一的值来进行字段填充。

本申请实施例的第二填充模块9，用于将所述缺失的数据存储信息填充至所述统一用户中心的数据存储信息中。

具体实施时，根据上述判断确定出相应的缺失的数据存储信息后，需要通过第二填充模块将该信息进行归纳统计，之后对于缺失或者需要修改的数据存储信息进行统一设计开发以满足于对应开源框架系统数据存储的要求。

作为本申请实施例的一种优选实施方式，如图9所示，所述装置还包括：接收模块10、第一转发模块11和返回模块12。

本申请实施例的接收模块10，用于接收用户端发送的服务调用请求，所述服务调用请求是指所述用户端用于调用所述开源框架业务系统的服务的请求。

具体实施时，在配置好公司内部系统与开源框架系统相对应的功能接口信息和数据存储信息之后，通过接收模块获取用户发送的调用开源框架系统相关服务的请求。

本申请实施例的第一转发模块11，用于将所述服务调用请求转发至所述统一用户中心。

具体实施时，在开源框架系统接收到用户的调用请求后，无需对用户的调用请求进行回应，而是通过第一转发模块将该请求转发至公司内部系统，由公司内部系统对用户的调用请求进行回应，即保证在公司内部系统中，所有开源框架系统中用户发送的服务调用请求都会被转发至公司内部系统中，且返回与开源框架系统对应接口一致的数据结果。

本申请实施例的返回模块12，根据更新后的所述配置信息将所述统一用户中心的服务调用结果返回至用户端。

具体实施时，公司内部系统中配置了开源框架系统中用户必须使用的所有功能接口信息和数据存储信息，通过返回模块识别用户的调用请求调用公司内部系统中相应的功能接口并返回至用户端，同时将相应的数据信息按照对应开源框架系统的格式进行存储。

作为本申请实施例的一种优选实施方式，如图10所示，所述装置还包括：第二获取模块13、第四确定模块14和第二转发模块15。

本申请实施例的第二获取模块13，用于通过所述开源框架业务系统获取用户端发送的服务调用请求。

具体实施时，第二获取模块通过开源框架系统获取用户发送的调用开源框架系统相关服务的请求。

本申请实施例的第四确定模块14，用于确定所述开源框架业务系统的系统ID信息。

具体实施时，在转发用户端发送的服务调用请求时，需要带上当前开源框架系统唯一的系统ID，以便于公司内部系统进行对应系统信息的判断，在某些情况下，还需要进行参数加密以及对应数据的计算等。因此首先需要通过第四确定模块获取当前开源框架系统的系统ID信息。

本申请实施例的第二转发模块15，用于基于所述开源框架业务系统的系统ID信息，通过反向代理将所述服务调用请求转发至所述统一用户中心。

具体实施时，在开源系统的接入层加入反向代理(类似于apache或者nginx等软件)，当接收到开源框架系统用户的调用请求并确定了该开源框架系统的ID信息之后，由对应的反向代理通过http 301转发，将旧的请求链接通过反向代理返回在公司内部系统对应接口的新链接，之后自动访问新链接，保证用户无感替换。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种用于开源框架的数据配置方法，其特征在于，包括：

获取业务系统的配置信息，所述配置信息包括功能接口信息和数据存储信息，所述业务系统包括统一用户中心和开源框架业务系统；

判断在所述统一用户中心的配置信息中是否可以匹配到所述开源框架业务系统的配置信息；

根据判断结果确定是否要在所述统一用户中心中更新所述配置信息；

确定统一用户中心接口信息中缺失的功能接口信息，将缺失或需要修改的接口进行统一设计开发；

和/或确定第一业务系统的数据存储信息中缺失的数据存储信息，对缺失或需要修改的数据存储信息进行统一设计开发。

2.根据权利要求1所述的用于开源框架的数据配置方法，其特征在于，所述获取业务系统的配置信息之后包括：

判断在所述统一用户中心的功能接口信息中是否可以匹配到所述开源框架业务系统的功能接口信息；

如果不可以，则根据判断结果确定所述统一用户中心的功能接口信息中缺失的功能接口信息；

将所述缺失的功能接口信息填充至所述统一用户中心的功能接口信息中。

3.根据权利要求1所述的用于开源框架的数据配置方法，其特征在于，所述获取业务系统的配置信息之后包括：

判断在所述统一用户中心的数据存储信息中是否可以匹配到所述开源框架业务系统的数据存储信息；

如果不可以，则根据判断结果确定所述统一用户中心的数据存储信息中缺失的数据存储信息；

将所述缺失的数据存储信息填充至所述统一用户中心的数据存储信息中。

4.根据权利要求1所述的用于开源框架的数据配置方法，其特征在于，所述根据判断结果确定是否要在所述统一用户中心中更新所述配置信息之后包括：

接收用户端发送的服务调用请求，所述服务调用请求是指所述用户端用于调用所述开源框架业务系统的服务的请求；

将所述服务调用请求转发至所述统一用户中心；

根据更新后的所述配置信息将所述统一用户中心的服务调用结果返回至用户端。

5.根据权利要求1所述的用于开源框架的数据配置方法，其特征在于，所述根据判断结果确定是否要在所述统一用户中心中更新配置信息之后包括：

通过所述开源框架业务系统获取用户端发送的服务调用请求；

确定所述开源框架业务系统的系统ID信息；

基于所述开源框架业务系统的系统ID信息，通过反向代理将所述服务调用请求转发至所述统一用户中心。

6.一种用于开源框架的数据配置装置，其特征在于，包括：

第一获取模块，用于获取业务系统的配置信息，所述配置信息包括功能接口信息和数据存储信息，所述业务系统包括统一用户中心和开源框架业务系统；

第一判断模块，用于判断在所述统一用户中心的配置信息中是否可以匹配到所述开源框架业务系统的配置信息；

第一确定模块，用于根据判断结果确定是否要在所述统一用户中心中更新所述配置信息；确定统一用户中心接口信息中缺失的功能接口信息，将缺失或需要修改的接口进行统一设计开发；和/或确定第一业务系统的数据存储信息中缺失的数据存储信息，对缺失或需要修改的数据存储信息进行统一设计开发。

7.根据权利要求6所述的用于开源框架的数据配置装置，其特征在于，还包括：

第二判断模块，用于判断在所述统一用户中心的功能接口信息中是否可以匹配到所述开源框架业务系统的功能接口信息；

第二确定模块，用于如果不可以，则根据判断结果确定所述统一用户中心的功能接口信息中缺失的功能接口信息；

第一填充模块，用于将所述缺失的功能接口信息填充至所述统一用户中心的功能接口信息中。

8.根据权利要求6所述的用于开源框架的数据配置装置，其特征在于，还包括：

第三判断模块，用于判断在所述统一用户中心的数据存储信息中是否可以匹配到所述开源框架业务系统的数据存储信息；

第三确定模块，用于如果不可以，则根据判断结果确定所述统一用户中心的数据存储信息中缺失的数据存储信息；

第二填充模块，用于将所述缺失的数据存储信息填充至所述统一用户中心的数据存储信息中。

9.根据权利要求6所述的用于开源框架的数据配置装置，其特征在于，还包括：

接收模块，用于接收用户端发送的服务调用请求，所述服务调用请求是指所述用户端用于调用所述开源框架业务系统的服务的请求；

第一转发模块，用于将所述服务调用请求转发至所述统一用户中心；

返回模块，根据更新后的所述配置信息将所述统一用户中心的服务调用结果返回至用户端。

10.根据权利要求6所述的用于开源框架的数据配置装置，其特征在于，还包括：

第二获取模块，用于通过所述开源框架业务系统获取用户端发送的服务调用请求；

第四确定模块，用于确定所述开源框架业务系统的系统ID信息；

第二转发模块，用于基于所述开源框架业务系统的系统ID信息，通过反向代理将所述服务调用请求转发至所述统一用户中心。

Images