CN114610732A - 兜底数据处理方法及装置 - Google Patents

Abstract

本发明提供一种兜底数据处理方法及装置，该方法包括：按照预设的轮序周期，读取配置模块中的应用配置文件；对应用配置文件进行解析，获取各个接口配置信息；对于每个接口配置信息，生成接口配置信息所属的核心接口的业务参数约定规则文件，并将业务参数约定规则文件进行保存；对于每个核心接口，使用核心接口的业务参数约定规则文件和接口配置信息，生成核心接口的兜底数据；基于各个兜底数据，更新应用配置文件所属的应用的兜底服务的兜底数据库。通过更新兜底数据库中的数据，从而避免向用户提供一成不变的兜底数据，可以为用户提供更合适、更满足需求的兜底数据，提高用户的使用体验。

Description

兜底数据处理方法及装置

技术领域

本发明涉及数据容灾兜底数据处理技术领域，特别涉及一种兜底数据处理方法及装置。

背景技术

随着信息化技术的飞速发展，信息系统在各行各业的关键业务中扮演着越来越重要的角色，信息系统业务中断会导致巨大经济损失、影响品牌形象并可能导致重要数据丢失。因此，保证业务连续性是信息系统建设的关键。而近年来，由于大范围自然灾害时常发生，为保障业务连续性，可靠的数据容灾兜底数据处理越来越得到业界的重视和认可。

现有的兜底数据有多种处理方法，常见的为运营人员根据业务参数配置固定的返回数据，当业务不可用时直接将运营配置的固定数据作为响应内容。然而，由于运营配置的兜底数据是提前预置的，通常不进行更新，使得向用户提供的兜底数据是一成不变的，这给用户带来了不好的体验。

发明内容

有鉴于此，本发明实施例提供一种兜底数据处理方法及装置，本发明可以定时更新兜底数据库中的数据，从而避免用户获取到的兜底数据是一成不变的情况，为用户提供更合适、更新的兜底数据，为用户提供更好的体验。

为实现上述目的，本发明实施例提供如下技术方案：

本发明第一方面公开一种兜底数据处理方法，包括：

按照预设的轮序周期，读取配置模块中的应用配置文件；

对所述应用配置文件进行解析，获取各个接口配置信息；

对于每个所述接口配置信息，生成所述接口配置信息所属的核心接口的业务参数约定规则文件，并将所述业务参数约定规则文件进行保存；

对于每个所述核心接口，使用所述核心接口的业务参数约定规则文件和接口配置信息，生成所述核心接口的兜底数据；

基于各个所述兜底数据，更新所述应用配置文件所属的应用的兜底服务的兜底数据库。

本发明第二方面公开一种兜底数据处理装置，包括：

配置模块和数据更新模块；

所述配置模块，用于获取应用的配置数据，基于所述配置数据生成所述应用的配置文件；

所述数据更新模块，用于按照预设的轮序周期，读取所述配置模块中的应用配置文件；对所述应用配置文件进行解析，获取各个接口配置信息；对于每个所述接口配置信息，生成所述接口配置信息所属的核心接口的业务参数约定规则文件，并将所述业务参数约定规则文件进行保存；对于每个所述核心接口，使用所述核心接口的业务参数约定规则文件和接口配置信息，生成所述核心接口的兜底数据；基于各个所述兜底数据，更新所述应用配置文件所属的数据。

与现有技术相比，本发明具有以下优点：

本发明提供一种兜底数据处理方法及装置，该方法包括：按照预设的轮序周期，读取配置模块中的应用配置文件；对应用配置文件进行解析，获取各个接口配置信息；对于每个接口配置信息，生成接口配置信息所属的核心接口的业务参数约定规则文件，并将业务参数约定规则文件进行保存；对于每个核心接口，使用核心接口的业务参数约定规则文件和接口配置信息，生成核心接口的兜底数据；基于各个兜底数据，更新应用配置文件所属的应用的兜底服务的兜底数据库。通过更新兜底数据库中的数据，从而避免向用户提供一成不变的兜底数据，可以为用户提供更合适、更满足需求的兜底数据，提高用户的使用体验。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本发明实施例提供的一种兜底数据处理方法的方法流程图；

图2为本发明实施例提供的生成接口配置信息的业务参数约定规则文件的方法流程图；

图3为本发明实施例提供的使用业务参数约定规则文件和接口配置信息，生成核心接口的兜底数据的方法流程图；

图4为本发明实施例提供的一种向用户提供兜底数据的方法流程图；

图5为本发明实施例提供的一种兜底数据处理装置的结构示意图；

图6为本发明实施例提供的兜底数据处理的架构图；

图7为本发明实施例提供的一种兜底数据处理方法的时序图；

图8为本发明实施例提供的一种兜底数据生成流程图；

图9为本发明实施例提供的一种读取兜底数据的流程图；

图10为本发明实施例提供的一种电子设别的结构示意图。

具体实施方式

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

在本申请中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

由背景技术可知，现有技术中的兜底数据通常都是预先设置的，通常不进行更新，导致用户获取到的兜底数据不是最新的数据，这给用户带来了不佳的体验。

为了解决上述的问题，本发明实施例提供一种兜底数据处理方法及装置，可以更新兜底数据，进而为用户提供最新的兜底数据，提高用户的体验。

本发明可用于众多通用或专用的计算装置环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器装置、包括以上任何装置或设备的分布式计算环境等等。本发明的执行主体可以为处理器或服务器。

参照图1，为本发明实施例提供的一种兜底数据处理方法的方法流程图，具体说明如下所述：

S101：按照预设的轮序周期，读取配置模块中的应用配置文件。

本发明实施例提供的方法中，按照预设的轮询周期，周期性的读取配置模块中的应用配置文件，换言之，定时读取配置模块中应用配置文件。

应用配置文件为使用业务人员在配置模块中输入应用的各个核心接口的配置数据后生成的文件，应用的核心接口的个数为至少一个，进一步的，业务人员可以随时在配置模块输入应用的各个核心接口的配置数据。优选的，应用的核心接口是业务人员选择的。应用有多个接口，业务人员选定的接口作为核心接口。

优选的，可以一次性获取多个应用的应用配置文件，获取的每个应用配置文件均可以执行S102～S105步骤。

S102：对应用配置文件进行解析，获取各个接口配置信息。

优选的，应用配置文件为json格式的文件，接口配置信息中包含数据源接口信息、参数配置、核心接口信息等内容。

S103：对于每个接口配置信息，生成接口配置信息所属的核心接口的业务参数约定规则文件，并将业务参数约定规则文件进行保存。

不同的接口配置信息对应不同的核心接口，业务参数约定规则还可以称为schema文件。

参照图2，为本发明实施例提供的生成接口配置信息的业务参数约定规则文件的方法流程图，具体如下所述：

S201：确定接口配置信息中的参数约定规则字段。

对于接口配置信息进行解析，确定接口配置信息中的参数约定规则字段，示例性的，参数约定规则字段还可以称为fallback_schema字段。

S202：确定接口配置信息所属的核心接口在应用中的各个第一参数。

进一步的，应用可以理解为客户端，可以确定接口配置信息所属的核心接口在应用中的各个第一参数，需要说明的是，第一参数是业务方设置的参数；以账号应用为例，密码登录接口为核心接口，在账号应用中，密码登录接口的各个第一参数可以包含用户名、密码和验证码，优选的，第一参数可以理解为核心接口的核心参数。

S203：基于预设的参数转换字段对各个第一参数进行处理，得到接口配置信息所属的核心接口的业务参数约定规则文件。

进一步的，解析预设的参数转换字段，将每个第一参数进行转换，得到每个第一参数的转换参数名，并将各个第一参数和每个第一参数的转换参数名按照预设的排序方式进行排列，生成业务参数约定规定文件。

S204：获取接口配置信息中的域名信息和路径信息。

需要说明的是域名信息可以使用host表示，路径信息可以使用path表示。

S205：使用域名信息和所述路径信息，生成文件保存目录。

在生成文件保存目录后，判断存储空间中是否存在与该文件保存目录一致的目录，如果不存在，则需要在存储空间中创建该文件保存目录，如果存在，则不需要在存储空间中创建该文件保存目录。

S206：基于文件保存目录将业务参数约定规则文件进行保存。

将业务参数业务规则文件在存储空间中保存至与该文件保存目录对应的存储内存中。

本发明实施例提供的方法中，为使用核心接口生成业务参数约定规则文件，业务参数约定规则文件为描述文件，在保存业务参数约定规则时，以目录的形式进行保存，并且使用的目录与核心接口的host和path有关，确保了业务参数约定规则文件保存的有序性，便于后续查找业务参数约定规则文件。

S104：对于每个核心接口，使用核心接口的业务参数约定规则文件和接口配置信息，生成核心接口的兜底数据。

参照图3，为本发明实施例提供的使用业务参数约定规则文件和接口配置信息，生成核心接口的兜底数据的方法流程图，具体说明如下所述：

S301：从接口配置信息中获取核心接口的数据源接口和参数组，参数组中包含多个第二参数。

数据源接口用于获取核心接口在正常工作时需要向用户反馈的数据，该接口提供的数据是兜底数据作为返回的数据依据。

参数组中的各个第二参数为业务人员为核心接口选择的各个参数。

S302：调用数据源接口，获取多个与参数组对应的参数值集合，参数值集合中包含多个参数值，各个参数值与各个第二参数一一对应。

需要说明的是，参数值为第二参数的具体数值。

S303：使用业务参数约定规则文件，对各个参数值集合进行处理，生成核心接口的兜底数据。

进一步的，在使用业务参数约定规则文件对各个参数值集合进行处理，时，对于参数组中的每个第二参数，在业务参数约定规则中确定与该第二参数对应的第一参数以及该第一参数的转换参数名；

对于每个参数值集合中的每个参数值，将该参数值与其所属的第二参数所对应的第一参数的转换参数名进行绑定，从而得到核心接口的兜底数据。

本发明实施例提供的方法中，在生成核心数据的兜底数据时，通过调用数据源接口，可以获取与核心接口对应的最新的各个参数值，进而生成最新的兜底数据。

S105：基于各个兜底数据，更新应用配置文件所属的应用的兜底服务的兜底数据库。

本发明实施例提供的方法中，将各个兜底数据更新至应用配置文件所属的应用的兜底服务的兜底数据库中，从而完成了对兜底数据的更新。进一步的，由于本发明是可以周期性进行的，因此，兜底数据库是周期性进行更新的，更新的时间周期可以根据实际需要进行设置，更新兜底数据库中的数据可以自动化进行，无需工作人员过多参数，减少了更新兜底数据库所需的成本，提高更新效率，为用户使用兜底数据提供好的使用体验。

本发明实施例提供的方法中，按照预设的轮序周期，读取配置模块中的应用配置文件；对应用配置文件进行解析，获取各个接口配置信息；对于每个接口配置信息，生成接口配置信息所属的核心接口的业务参数约定规则文件，并将业务参数约定规则文件进行保存；对于每个核心接口，使用核心接口的业务参数约定规则文件和接口配置信息，生成核心接口的兜底数据；基于各个兜底数据，更新应用配置文件所属的应用的兜底服务的兜底数据库。通过对应用配置文件进行处理，得到应用的每个核心接口的业务参数约定规则文件和接口配置信息，并使用业务参数约定规则文件和接口配置信息生成兜底数据，最后使用兜底数据更新兜底数据库，由此可以确定兜底数据库中的兜底数据是不断更新的，后续可以使用兜底数据库为用户提供兜底数据，而为用户提供的兜底数据不是一成不变的，可以向用户提供最新的兜底数据，为用户带来更好的使用体验感。

需要说明的是，使用各个兜底数据更新兜底数据库后，可以使用更新后的兜底数据库中的数据向用户提供，具体如图4，为本发明实施例提供的一种相用户提供兜底数据的方法流程图，具体说明如下所述：

S401：当获取到用户发送的属于应用的数据请求时，获取数据请求中的请求域名以及请求路径。

需要说明的是，在获取到用户发送的属于应用的数据请求时，该请求应该是已经筛选过的请求，该请求可以为需要降级服务的请求。

S402、基于请求域名和请求路径，确定是否存在与数据请求对应的业务参数约定规则文件；若存在与数据请求对应的业务参数约定规则文件，则执行S403；若不存在与数据请求对应的业务参数约定规则文件，则执行S406。

在确定是否存在数据请求对应的业务参数约定规则文件时，可以使用数据请求域名和请求路径生成查找目录，若该查找目录不存在业务参数约定规则文件，则确定不存在与数据请求对应的业务参数约定规则文件，若该查找目录存在业务参数约定规则文件，则确定存在与数据请求对应的业务参数约定规则文件。

S403：使用业务参数约定规则文件生成文件路径。

对业务参数约定规则文件进行处理，从而生成文件路径。

S404：判断兜底数据库中是否存在与文件路径对应的文件数据；若兜底数据库中存在与文件路径对应的文件数据，则执行S405；若兜底数据库中不存在与文件路径对应的文件数据，则执行S406。

S405：将兜底数据库中与文件路径对应的文件数据作为兜底服务的响应数据向用户反馈。

需要说明的是，此时向用户反馈的响应数据为兜底数据。

S406：向用户反馈预设的降级方案。

本发明实施例提供的方法中，在接收到用户发送的数据请求后，使用数据请求中的请求域名和请求路径，精确的判断是否存在与数据请求对应的业务参数约定规则文件，当不存在时，向用户提供别的降级方案，当存在时，需要使用业务参数约定规则文件生成文件路径，并将与文件路径对应的文件数据作为响应数据向用户反馈，在不存在与文件路径对应的文件数据时，向用户反馈别的降级方案，降级方案具体如：httpCode＝404的降级方案，或是可以支持该服务的其余可执行方案；由此，可以最大限度的为用户继续提供服务，进一步的，向用户反馈的响应数据为兜底数据库中最新的数据，使用最新的数据可以保证向用户提供的业务的持续性，为用户提供更好的使用体验。

参照图5，为本发明实施例提供的一种兜底数据处理装置的结构示意图，该结构可以支持上述的兜底数据处理方法在现实生活中的实现，该装置可以设置在计算机终端中，如图5所示，该装置包括配置模块501、数据更新模块502和数据读取模块503；

所述配置模块501，用于获取应用的配置数据，基于所述配置数据生成所述应用的配置文件；

所述数据更新模块502，用于按照预设的轮序周期，读取所述配置模块中的应用配置文件；对所述应用配置文件进行解析，获取各个接口配置信息；对于每个所述接口配置信息，生成所述接口配置信息所属的核心接口的业务参数约定规则文件，并将所述业务参数约定规则文件进行保存；对于每个所述核心接口，使用所述核心接口的业务参数约定规则文件和接口配置信息，生成所述核心接口的兜底数据；基于各个所述兜底数据，更新所述应用配置文件所属的数据；

所述数据读取模块503，用于获取用户发送的属于所述应用的数据请求，基于所述数据请求中的请求域名以及请求路径，确定所述数据更新模块中是否存在与所述数据请求对应的业务参数约定规则文件；若存在与所述数据请求对应的业务参数约定规则文件，则使用所述业务参数约定规则文件生成文件路径；判断所述数据更新模块中是否存在与所述文件路径对应的文件数据；若所述数据更新模块中存在与所述文件路径对应的文件数据，则将所述数据更新模块中与所述文件路径对应的文件数据作为所述兜底服务的响应数据向所述用户反馈；若所述数据更新模块中不存在与所述文件路径对应的文件数据，则向所述用户反馈预设的降级方案。

进一步的，配置模块，用于提供运营后台界面，按应用名称设置各应用下的核心接口参数及数据源，并生成json格式文件，json格式文件为应用配置文件；

数据更新模块由lua定时器实现，通过读取配置的json格式文件，生成参数映射的schema文件；调用数据源接口并获取数据源返回的兜底数据；根据配置的域名host及参数path、queryParam生成指定目录下的文件，并将兜底数据存储在文件中；定时任务来保证配置数据及数据源数据的实时更新；

数据读取模块则是实现在Nginx中的rewrite_by_lua_file块，内部使用lua脚本解析host及参数，读取数据更新模块生成的schema文件，再根据schema组装文件名，读取对应文件后直接返回给客户端。

通过配置模块与业务进行数据源配置交互，仅对业务定义的核心接口提供降级的兜底数据服务，节省兜底数据存储空间；通过数据更新模块为业务提供实时的兜底数据更新；通过数据读取模块直接定位到需要响应的核心接口数据文件，将内容快速响应给客户端。该过程定义了一套兜底数据处理的流程，可接入大量业务使用，可不限机房任意部署，为业务提供兜底数据服务节省大量人力资源。实时的兜底数据更新功能即可提升品牌形象又为用户提供了友好的交互体验。

需要说明的是，本发明实施例提供的装置中，兜底数据处理装置中的数据更新模块在生成所述接口配置信息所属的核心接口的业务参数约定规则文件时，包括：

确定所述接口配置信息中的参数约定规则字段；

确定所述接口配置信息所属的核心接口在所述应用中的各个第一参数；

基于预设的参数转换字段对各个所述第一参数进行处理，得到所述接口配置信息所属的核心接口的业务参数约定规则文件。

本发明实施例提供的装置中，数据更新模块在将所述业务参数约定规则文件进行保存时，包括：

获取所述接口配置信息中的域名信息和路径信息；

使用所述域名信息和所述路径信息，生成文件保存目录；

基于所述文件保存目录将所述业务参数约定规则文件进行保存。

本发明实施例提供的装置中，数据更新模块在使用所述核心接口的业务参数约定规则文件和接口配置信息，生成所述核心接口的兜底数据时，包括：

从所述接口配置信息中获取所述核心接口的数据源接口和参数组，所述参数组中包含多个第二参数；

调用所述数据源接口，获取多个与所述参数组对应的参数值集合，所述参数值集合中包含多个参数值，各个参数值与各个第二参数一一对应；

使用所述业务参数约定规则文件，对各个所述参数值集合进行处理，生成所述核心接口的兜底数据。

为了进一步的说明本发明提供的方式在各种其他场景下的具体应用，本发明提供了一种兜底数据处理方法的另一实现流程，具体流程如下所述：

步骤1：配置模块与应用接入方交互，应用管理员在后台界面上填写应用的域名，有多个域名时需要以逗号分隔的方式填写完整；填写核心接口的Path及Param，其中Param参数以Json格式定义，如ParamA:param_a含义为将客户端请求的ParamA参数转义为数据源需要的param_a参数；同时配置fallback_entity_url和fallback_data_url两个接口地址，该接口为业务提供的降级服务数据源配置，其中fallback_entity_url接口会返回核心的参数及值列表，其中fallback_data_url接口则可根据fallback_entity_url中的参数和值组装后返回实际的兜底降级内容；

步骤2：配置模块依据应用管理员的配置内容，按规则将所有项目整合，以http接口的方式提供完整的application_A_fallback.json配置文件；

步骤3：数据更新模块是一个由Lua实现功能的模块，主要功能为读取配置模块的接口，接口返回的列表数据中会列举每个接口的配置文件，遍历数据列表多线程对每一个应用配置进行处理；

步骤4：数据更新模块，根据应用的配置信息，按host和path生成目录，该目录作为应用当前核心接口的数据存储目录，读取Param参数定义，将需要转换的参数存储在当前目录下名为fallback_schema的文件；

步骤5：数据更新模块调用fallback_entity_url接口，获取到业务方降级数据源为当前path定义的核心数据参数，将参数组装为param，发起调用fallback_data_url接口，将接口返回的内容按参数的ascii码升序排列，如param_a＝1&param_b＝2作为文件名存储响应的内容；

步骤6：数据读取模块，是一个Niginx的Lua代码块，内部解析了Nginx的host、path、param等参数，根据host和path定位到schema文件，再读取schema文件的内容，将客户端的param对应key及value获取到，按参数的ascii码升序排列得到目标文件名；

步骤7：数据读取模块直接读取步骤6中得到的目标文件名，若存在与目标文件名对应的文件，则直接将文件内容作为响应快速返回给客户端，若不存在与目标文件名对应的文件，则意味着当前接口不是核心数据接口，业务方接受直接返回httpCode＝404的降级方案。

示例性的，本发明实施例还提供了实现兜底数据处理场景的架构图，用于具体说明本发明在应用场景中的实现过程，参照图6，为本发明实施例提供的兜底数据处理的架构图，具体说明如下所述：

步骤1，降级兜底服务是一个独立的服务，独立于业务集群之外；若业务集群发生异常时，在流量入口，比如网关或者负载均衡设备上将所有流量转发到独立的降级兜底服务上；降级兜底服务内部会需要各业务方提供核心数据的兜底接口内容，以便快速响应用户的请求；

步骤2，降级兜底服务所有数据都在内部处理，只要能访问到配置模块的规则数据，就可以独立生成一套实时更新的用于兜底降级服务的文件内容，可快速部署、快速扩容；

步骤3，由于各自应用的核心接口、核心参数只有各业务的运营方最熟悉，因此数据配置模块由各应用的业务运营人员进行维护，数据配置模块的主要职责就是提供一个运营管理后台，由业务方填写自身核心业务的接口host、Path、参数列表，兜底数据列表等信息，并最终提供一个接口供数据更新模块访问，接口以应用名为key，返回应用下的所有配置的json格式信息；

步骤4，数据更新模块访问数据配置模块提供的接口，获取到每个应用的配置信息，每个应用之间以域名作为区分的目录，根据配置信息生成每一个接口的文件目录，并在文件目录下生成需要的Schema文件，再根据配置提供的参数和接口，遍历所有接口生成指定参数名的数据文件；若同一个应用存在多个域名，则以第一个域名作为存储数据文件的主目录，其它域名软链指向到第一域名目录；

步骤5，数据读取模块内部以Nginx代理服务为主，辅以Lua脚本进行逻辑处理，Lua脚本首先读取GET/POST的所有参数，再根据host+path定位到目录，对于RESTFul形式的path则会进行递归删减查找，直到找到不是变量名的目录下存有Schema文件的目录，再通过读取Schema文件的内容，从参数中去除指定key的值，并将值按Schema文件中的key组装为数据文件。Lua块读取到数据文件路径后直接返回给Nginx,由Nginx负责读取具体的文件内容并返回给客户端。

需要说明的是，本发明提供部分的编码示例，具体内容如下：

上述的内容即为本发明提供的部分编码内容。

参照图7，为本发明实施例提供的一种兜底数据处理方法的时序图，具体说明如下所述：

步骤1，运营人员通过管理后台，配置应用的核心接口信息，配置应用的兜底数据接口；

进一步的，配置完成后，整体程序如下所示：

上述为运营人员通过管理后台，配置应用的核心接口信息，配置应用的兜底数据接口示例编码。

步骤2，根据上述配置信息，每一个应用都会应用级的接口配置文件，数据更新模块定时读取配置接口的信息，根据domain和path确定当前接口的文件存储路径，根据fallback_schema字段的内容生成Schema文件，存储在当前接口的文件存储路径中；再通过读取data和entity接口的内容，从entity接口拿到核心参数，组装为请求串调用data的接口，获取到数据后将参数和schema结合生成按实际参数key＝value并按ascii升序排列的文件名，文件中存储data接口返回的内容，该内容即是客户端请求兜底服务时返回的兜底数据。

步骤3，当网关或负载均衡设备判断常规服务需要降级时，具体降级方法可以是开关开启，可以是探活检测到异常等，会将客户端请求流量直接转发到兜底服务的Nginx代理上，此时基于Nginx的Lua数据读取模块开始解析客户端的所有参数，并按请求的host和path找寻Schema文件，根据Schema文件中的参数名转换规则定义，获取客户端实际参数，若实际参数为空则取值空串，组装为完整的兜底数据文件，再将文件路径返回给Nginx，由Nginx转发到指定目录并读取文件后返回，此时文件存在时命中核心接口的核心降级数据，直接返回文件内容，若未命中文件则直接返回httpCode＝404,意味未命中核心数据不需要降级处理；

进一步的，Lua脚本rewrite_by_lua_downgrade.lua的核心逻辑如下所示：

上述的内容即为Lua脚本rewrite_by_lua_downgrade.lua的核心逻辑编码。

参照图8，为本发明实施例提供的一种兜底数据生成流程图，具体内容如下所述：

步骤1，根据配置模块提供的接口读取到配置的所有应用数据，解析配置中的host和path，检查对应应用下的数据文件目录是否存在，不存在时创建目录；

步骤2，解析配置文件中fallback_schema按参数生成Schema文件，文件名固定为schema，该名称与读取模块约定为固定值。Schema文件的内容规则使用key1＝transferKey1&key2＝transferKey2的格式，将key按ascii码升序排列后用等号＝连接需要被转换为的参数名，前方的key1为客户端实际入参，后方的transferKey1为将客户端实际入参转为的中间过程参数名，多个参数之间使用&号拼接；

步骤3，解析配置文件中的entityUrl，调用接口获取到所有核心参数的参数列表；遍历每一组参数，将参数组装后进入下一步；

步骤4，解析配置文件中的dataUrl，将上一步参数作为请求参数，调用dataUrl接口，将接口返回的数据与配置的success_key和success_code对比，判断接口是否请求成功；若接口请求成功，则按schema规则将参数值拼接为transferKey1＝value1&transferKey2＝value2格式，同样参数名是按ascii值进行排序的，规则与schema中定义的转换规则一致，以该格式为文件名，存储dataUrl返回的所有内容；改文件即是面向客户端接口时使用的兜底数据文件。

参照图9，为本发明实施例提供的一种读取兜底数据的流程图，具体说明如下所述：

步骤1，网关或负载均衡设备将降级流量转发到兜底服务器，服务器上有Lua脚本内嵌在Nginx中，Lua脚本解析客户端请求的Host、Path及Param(接口的核心参数)；

步骤2，将Host和Path转为目录名，检测指定目录下是否存在Schema文件，若存在则进入步骤3，若不存在则使用递归的方式，将Path中的目录回退一级，继续查找是否存在Schema文件，若直到path只有/时还没有找到Schema文件，则当前流量属于非核心流量，直接返回404；

步骤3，将Schema中对应参数名的客户端参数值取出，按Schema文件定义的文件名，如：transferKey1＝value1&transferKey2＝value2，组装为完成的文件路径。组装路径的规则为：实际文件存储在/data/fallback/host/path/transferKey1＝value1&transferKey2＝value2，使用Nginx内置的lua语法set_uri()函数重写请求的Path为/fallback/host/path/transferKey1＝value1&transferKey2＝value2，Nginx会将请求转发到配置块的^fallback块中处理，由处理块拼接/data/根目录。若文件存在则直接返回文件内容，若文件不存在则响应404。

本发明通过基于Lua脚本实现的实时更新兜底数据，在后端服务发生异常故障时，将流量转发到降级兜底服务器，服务器内的Nginx再次通过Lua脚本处理客户端请求参数及读取指定的数据文件，快速返回兜底数据；业务方通过配置模块定义服务降级时需要被提供服务的接口及参数，保障核心接口的正常数据响应在业务服务故障时可为用户提供有损的可持续服务，保障用户核心功能可正常使用，配置模块最终以json格式数据落在服务器中存储；数据更新模块读取json格式的配置数据，根据配置调用降级服务接口，并将接口内容按配置中的schema定义存储为具体目录及格式下的文件，同时在目录下存储对应schema文件，数据更新模块内部使用定时任务来完成兜底数据的实时更新，将更新后的文件以文本形式存储到降级兜底服务器的磁盘中；数据读取模块接收客户端的请求，并根据请求中的host，path读取指定schema配置，再根据schema中定义的queryConfig及客户端请求的queryParam组装为实际的文件名，读取降级服务本地磁盘中的文件后直接返回文件内容。本发明提供的方法中，业务方接入仅需关注自身哪些核心业务在后端业务服务器宕机后还需要为用户提供服务的接口，并将对应接口及接口关注的重要参数配置在配置模块中，业务方在提供一个降级数据源服务后就可提供一个强大的兜底数据服务，极大的简化了兜底服务的接入流程，更快速的兜底数据更新机制，可实时更新的兜底数据，对业务及用户的使用体验更好。

本发明实施例还提供了一种存储介质，所述存储介质包括存储的指令，其中，在所述指令运行时控制所述存储介质所在的设备执行上述兜底数据处理方法。

本发明实施例还提供了一种电子设备，其结构示意图如图10所示，具体包括存储器601，以及一个或者一个以上的指令602，其中一个或者一个以上指令602存储于存储器601中，且经配置以由一个或者一个以上处理器603执行所述一个或者一个以上指令602执行上述兜底数据处理方法。

上述各个实施例的具体实施过程及其衍生方式，均在本发明的保护范围之内。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种兜底数据处理方法，其特征在于，包括：

按照预设的轮序周期，读取配置模块中的应用配置文件；

对所述应用配置文件进行解析，获取各个接口配置信息；

对于每个所述接口配置信息，生成所述接口配置信息所属的核心接口的业务参数约定规则文件，并将所述业务参数约定规则文件进行保存；

对于每个所述核心接口，使用所述核心接口的业务参数约定规则文件和接口配置信息，生成所述核心接口的兜底数据；

基于各个所述兜底数据，更新所述应用配置文件所属的应用的兜底服务的兜底数据库。

2.根据权利要求1所述的方法，其特征在于，还包括：

当获取到用户发送的属于所述应用的数据请求时，基于所述数据请求中的请求域名以及请求路径，确定是否存在与所述数据请求对应的业务参数约定规则文件；

若存在与所述数据请求对应的业务参数约定规则文件，则使用所述业务参数约定规则文件生成文件路径；

判断所述兜底数据库中是否存在与所述文件路径对应的文件数据；

若所述兜底数据库中存在与所述文件路径对应的文件数据，则将所述兜底数据库中与所述文件路径对应的文件数据作为所述兜底服务的响应数据向所述用户反馈；

若所述兜底数据库中不存在与所述文件路径对应的文件数据，则向所述用户反馈预设的降级方案。

3.根据权利要求1所述的方法，其特征在于，所述生成所述接口配置信息所属的核心接口的业务参数约定规则文件，包括：

确定所述接口配置信息中的参数约定规则字段；

确定所述接口配置信息所属的核心接口在所述应用中的各个第一参数；

基于预设的参数转换字段对各个所述第一参数进行处理，得到所述接口配置信息所属的核心接口的业务参数约定规则文件。

4.根据权利要求1所述的方法，其特征在于，所述将所述业务参数约定规则文件进行保存，包括：

获取所述接口配置信息中的域名信息和路径信息；

使用所述域名信息和所述路径信息，生成文件保存目录；

基于所述文件保存目录将所述业务参数约定规则文件进行保存。

5.根据权利要求1所述的方法，其特征在于，所述使用所述核心接口的业务参数约定规则文件和接口配置信息，生成所述核心接口的兜底数据，包括：

从所述接口配置信息中获取所述核心接口的数据源接口和参数组，所述参数组中包含多个第二参数；

调用所述数据源接口，获取多个与所述参数组对应的参数值集合，所述参数值集合中包含多个参数值，各个参数值与各个第二参数一一对应；

使用所述业务参数约定规则文件，对各个所述参数值集合进行处理，生成所述核心接口的兜底数据。

6.一种兜底数据处理装置，其特征在于，包括：

配置模块和数据更新模块；

所述配置模块，用于获取应用的配置数据，基于所述配置数据生成所述应用的配置文件；

所述数据更新模块，用于按照预设的轮序周期，读取所述配置模块中的应用配置文件；对所述应用配置文件进行解析，获取各个接口配置信息；对于每个所述接口配置信息，生成所述接口配置信息所属的核心接口的业务参数约定规则文件，并将所述业务参数约定规则文件进行保存；对于每个所述核心接口，使用所述核心接口的业务参数约定规则文件和接口配置信息，生成所述核心接口的兜底数据；基于各个所述兜底数据，更新所述应用配置文件所属的数据。

7.根据权利要求6所述的装置，其特征在于，还包括：

数据读取模块：

所述数据读取模块，用于获取用户发送的属于所述应用的数据请求，基于所述数据请求中的请求域名以及请求路径，确定所述数据更新模块中是否存在与所述数据请求对应的业务参数约定规则文件；若存在与所述数据请求对应的业务参数约定规则文件，则使用所述业务参数约定规则文件生成文件路径；判断所述数据更新模块中是否存在与所述文件路径对应的文件数据；若所述数据更新模块中存在与所述文件路径对应的文件数据，则将所述数据更新模块中与所述文件路径对应的文件数据作为所述兜底服务的响应数据向所述用户反馈；若所述数据更新模块中不存在与所述文件路径对应的文件数据，则向所述用户反馈预设的降级方案。

8.根据权利要求6所述的装置，其特征在于，所述数据更新模块在生成所述接口配置信息所属的核心接口的业务参数约定规则文件时，包括：

确定所述接口配置信息中的参数约定规则字段；

确定所述接口配置信息所属的核心接口在所述应用中的各个第一参数；

基于预设的参数转换字段对各个所述第一参数进行处理，得到所述接口配置信息所属的核心接口的业务参数约定规则文件。

9.根据权利要求6所述的装置，其特征在于，所述数据更新模块在将所述业务参数约定规则文件进行保存时，包括：

获取所述接口配置信息中的域名信息和路径信息；

使用所述域名信息和所述路径信息，生成文件保存目录；

基于所述文件保存目录将所述业务参数约定规则文件进行保存。

10.根据权利要求6所述的装置，其特征在于，所述数据更新模块在使用所述核心接口的业务参数约定规则文件和接口配置信息，生成所述核心接口的兜底数据时，包括：

从所述接口配置信息中获取所述核心接口的数据源接口和参数组，所述参数组中包含多个第二参数；

调用所述数据源接口，获取多个与所述参数组对应的参数值集合，所述参数值集合中包含多个参数值，各个参数值与各个第二参数一一对应；

使用所述业务参数约定规则文件，对各个所述参数值集合进行处理，生成所述核心接口的兜底数据。

Images