CN114500481A - 业务请求处理方法、系统和装置 - Google Patents

Abstract

本申请公开了一种业务请求处理方法、系统和装置，本方法通过接收业务请求，获取所述业务请求中的请求域名，根据所述请求域名匹配预设的配置文件，每个所述配置文件配置有路由规则；当匹配到所述请求域名对应的配置文件时，根据所述配置文件配置的路由规则请求业务服务器获取返回结果，根据所述返回结果得到响应数据；发送所述响应数据至前端浏览器，以使所述前端浏览器对所述响应数据渲染。本申请解决相关技术中面向商业用户的SaaS(软件即服务)软件开发过程中，不同用户需求不同开发效率低的技术问题，提供一种高复用、易维护、业务隔离、低资源占用的定制需求开发框架，实现对于不同客户之间迥然不同的定制需求，同时为SaaS开发团队降本增效低耦合。

Description

业务请求处理方法、系统和装置

技术领域

本申请属于计算机技术领域，具体而言，涉及一种业务请求处理方法、系统、电子设备及存储介质。

背景技术

在面向商业用户的SaaS(软件即服务)软件开发过程中，用户的需求大体可以分为两类：用户提出，但面向全部用户均有使用场景和使用价值；用户提出，但跟用户自身系统高度耦合，对其他用户不具备使用价值。

为了实现客户的不同需求，需要为每个客户单独维护一整套系统，配备对应的运维人员，成本非常昂贵。使用的代码和SaaS后续迭代的代码隔离，后续SaaS的新增功能和优化等无法及时同步到用户环境。同步工作费事费力，同时充满未知风险。需要为每个客户安排资深的开发人员，开发人员需要对整个系统有充分的了解，初级工程师很难参与其中解决问题。

发明内容

本申请实施例的第一目的在于提供一种业务请求处理方法，旨在解决上述现有技术存在的至少一个问题。

本申请实施例是这样实现的，一种业务请求处理方法，包括：

接收业务请求，获取所述业务请求中的请求域名，根据所述请求域名匹配预设的配置文件，每个所述配置文件配置有路由规则；

当匹配到所述请求域名对应的配置文件时，根据所述配置文件配置的路由规则请求业务服务器获取返回结果，根据所述返回结果得到响应数据；

发送所述响应数据至前端浏览器，以使所述前端浏览器对所述响应数据渲染展示。

在一个实施例中，在接收业务请求之前还包括：加载配置文件中的所述路由规则。

在一个实施例中，还包括：当未匹配到所述请求域名对应的配置文件时，根据默认配置文件请求默认的业务服务器。

在一个实施例中，所述路由规则包括静态的路由规则和带正则的路由规则，所述根据所述请求域名匹配对应的配置文件包括：根据所述请求域名的统一资源标识符和/或请求头参数和/或请求体参数在所述配置文件的静态的路由规则中匹配路由规则，若匹配到，则将该配置文件确定为匹配到的配置文件并停止匹配；若未匹配到，则根据所述请求域名的统一资源标识符和/或请求头参数和/或请求体参数在所述配置文件的带正则的路由规则中匹配路由规则，若匹配到，则将该配置文件确定为匹配到的配置文件并停止匹配；若未匹配到，则确定为无匹配的配置文件。

在一个实施例中，所述静态的路由规则和所述带正则的路由规则均包括以下至少一个路由逻辑：预请求路径、替换路径和附有请求实体的更新路径的处理逻辑，所述根据所述配置文件配置的路由规则请求业务服务器获取返回结果包括：当匹配到的路由规则为静态的路由规则时，以所述业务请求的请求路径根据所述路由逻辑请求业务服务器获取返回结果；当匹配到的路由规则为带正则的路由规则时，获取所述业务请求的请求路径中的资源地址，将所述资源地址作为参数拼接在转发路径上，以所述转发路径根据所述路由逻辑请求业务服务器获取返回结果。

在一个实施例中，所述根据所述路由逻辑请求业务服务器获取返回结果包括：判断所述路由逻辑是否有预请求路径，若有，则根据所述业务请求的请求头参数和请求体参数，请求预请求路径对应的主机接口获取第一返回数据，若无，进行下一逻辑判断；判断所述路由逻辑是否有替换路径，若有、且当所述路由逻辑有所述预请求路径时，则根据所述业务请求的请求头参数、所述第一返回数据作为请求体参数，请求替换路径对应的主机接口获取第二返回数据，若有、且当所述路由逻辑无所述预请求路径时，则根据所述业务请求的请求头参数和请求体参数，请求替换路径对应的主机接口获取第二返回数据，若无，则根据默认的配置文件请求默认业务服务器获取第二返回数据；判断路由逻辑中是否有附有请求实体的更新路径，若有，则根据所述业务请求的请求头参数、所述第二返回数据作为请求体参数，请求附有请求实体的更新路径对应的主机接口获取第三返回结果，若无，则停止执行。

在一个实施例中，所述根据所述返回结果得到响应数据包括：当所述路由逻辑无附有请求实体的更新路径时，将所述第二返回数据确定为所述响应数据，当所述路由逻辑有附有请求实体的更新路径时，将所述第三返回数据确定为所述响应数据。

本申请实施例的另一目的在于提供一种业务请求处理系统，包括：

请求接收模块，用于接收业务请求，获取所述业务请求中的请求域名，根据所述请求域名匹配预设的配置文件，每个所述配置文件配置有路由规则；

请求处理模块，用于：当匹配到所述请求域名对应的配置文件时，根据所述配置文件配置的路由规则请求业务服务器获取返回结果，根据所述返回结果得到响应数据；

响应数据发送模块，用于发送所述响应数据至前端浏览器，以使所述前端浏览器对所述响应数据渲染展示。

本申请实施例的又一目的在于提供一种电子设备，包括存储器和处理器，所述存储器中存储有计算机程序，所述计算机程序被所述处理器执行时，使得所述处理器执行所述业务请求处理方法的步骤。

本申请实施例的再一目的在于一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时，使得所述处理器执行所述业务请求处理方法的步骤。

本申请实施例提供的一种业务请求处理方法、系统、电子设备及存储介质，通过接收业务请求，获取所述业务请求中的请求域名，根据所述请求域名匹配预设的配置文件，每个所述配置文件配置有路由规则；当匹配到所述请求域名对应的配置文件时，根据所述配置文件配置的路由规则请求业务服务器获取返回结果，根据所述返回结果得到响应数据；发送所述响应数据至前端浏览器，以使所述前端浏览器对所述响应数据渲染展示。提供一种高复用、易维护、业务隔离、低资源占用的定制需求开发框架，实现对于不同客户之间迥然不同的定制需求，同时为SaaS开发团队降本增效低耦合。

附图说明

图1为本申请一个实施例提供的业务请求处理方法的实现流程；

图2为本申请一个实施例提供的业务请求处理系统的主要模块示意图；

图3为本申请实施例提供的可以应用于其中的示例性系统架构图；

图4为适于用来实现本申请实施例的终端设备或服务器的计算机系统的结构示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

在本申请实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请实施例和所附权利要求书中所使用的单数形式的“一种”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。

需要指出的是，在不冲突的情况下，本申请中的实施例以及实施例中的特征可以互相组合。

为了进一步阐述本申请为实现预定发明目的所采取的技术手段及功效，以下结合附图及较佳实施例，对依据本申请的具体实施方式、结构、特征及其功效，详细说明如下。

在面向商业用户的SaaS(软件即服务)软件开发过程中，用户的需求大体可以分为两类：

一、用户提出，但面向全部用户均有使用场景和使用价值；

二、用户提出，但跟用户自身系统高度耦合，对其他用户不具备使用价值。

第一类需求，可以直接在SaaS服务上实现对应的需求即可。

第二类需求，可以考虑如下几种方案：基于当前的代码为客户单独开发和部署一套独立的环境，在该环境中满足客户的定制需求；提供开放平台，开放api等文档，由客户自行开发并系统对接；基于当前代码为指定用户添加功能，功能对其他用户不可见。

对于基于当前的代码为客户单独开发和部署一套独立的环境，在该环境中满足客户的定制需求的方案，优点是：每个客户由单独的环境和单独的代码，环境隔离性好，定制代码开发的复杂度较低；客户后续迭代的需求开发难度较低，需求实现简单方便。缺点是：需要为每个客户单独维护一整套系统，配备对应的运维人员，成本非常昂贵；使用的代码和SaaS后续迭代的代码隔离，后续SaaS的新增功能和优化等无法及时同步到用户环境。同步工作费事费力，同时充满未知风险；需要为每个客户安排资深的开发人员，开发人员需要对整个系统有充分的了解。初级工程师很难参与其中解决问题。

对于提供开放平台，开放api等文档，由客户自行开发并系统对接提供开放平台，开放api等文档，由客户自行开发并系统对接的方案，优点是：客户可根据开放平台的文档与系统自行对接，实现自己的需求；所有代码均在SaaS维护，维护成本低，一次开发，多个客户可使用。缺点是：开放平台的系统对接需要客户拥有一定的开发能力，同时对平台能力熟悉；开放平台在双方深度耦合的需求(如：替换注册接口，联系人数据导入，标签分组)等方面力有不逮，开发起来复杂度较高，同时影响原有业务的复杂度。

对于基于当前代码为指定用户添加功能，功能对其他用户不可见的方案，优点是：客户的需求直接实现在同一套代码中，代码升级较为简单；相对节省服务器资源和人力资源。缺点是：需要单独实现一套资源管理机制，保证普通客户和定制客户的隔离，实现复杂度较高；代码开发过程中会碰到许多冲突场景，对业务需求的满足可能随着定制业务增多而寸步难行，降低系统健壮性；定制业务和SaaS需同步发布，测试工作量巨大。

因此，上述方案或存在成本高昂，或存在功能限制，或存在影响功能开发。比如，方案一存在的服务器资源等成本昂贵，升级困难的问题，方案二存在客户没有开发能力，系统深度对接时开放平台开发时间长，复杂度高，对已有业务有冲突的问题，方案三存在定制代码和SaaS代码过于耦合问题，环境耦合问题。

因此，为解决上述方案的至少一个技术问题，本发明主要提供一种低耦合，高复用，易维护，业务隔离，低资源占用的定制需求开发框架，解决上述方案的痛点，满足我不同客户之间迥然不同的定制需求，同时为SaaS开发团队降本增效。

图1示出了本申请一个实施例提供的一种业务请求处理方法的实现流程，为了便于说明，仅示出与本申请实施例相关的部分，详述如下：

一种业务请求处理方法，包括以下步骤：

S101：接收业务请求，获取所述业务请求中的请求域名，根据所述请求域名匹配预设的配置文件，每个所述配置文件配置有路由规则；

S102：当匹配到所述请求域名对应的配置文件时，根据所述配置文件配置的路由规则请求业务服务器获取返回结果，根据所述返回结果得到响应数据；

S103：发送所述响应数据至前端浏览器，以使所述前端浏览器对所述响应数据渲染展示。

在步骤S101中：接收业务请求，获取所述业务请求中的请求域名，根据所述请求域名匹配预设的配置文件，每个所述配置文件配置有路由规则。

在这里，整体方案的实现原理主要是通过配置OpenResty(nginx+lua动态服务代理网关)的路由规则，满足不同租户之间相同的服务调用，后端的逻辑不同的功能。可以通过对于不同的SaaS软件用户配置不同的路由规则，进而实现对于不同用户的不同需求。在进行openresty文件配置时，对于不同的用户的个性化需求，可以根据个性化逻辑进行配置路由逻辑，对于通用的需求可以配置默认的路由逻辑。当有需求的用户请求业务时，请求路由至定制的逻辑，当没有定制需求的用户请求业务时，请求路由至SaaS通用代码。

需要说明的是，不同的客户使用不同的二级域名来访问系统，因此可以通过识别不同的用户的请求业务时的请求域名，识别出该业务请求对应的配置文件，然后基于配置文件中配置的路由规则进行请求业务服务器。

在配置openresty路由规则时，可以先进行编写yaml(是一个可读性高，用来表达数据序列化的格式)配置文件，主要包含了路由调度逻辑，如接收到一个请求，接下来是转发，组合，替换等逻辑。然后为客户定制的逻辑进行代码单独开发。再通过编写lua(是一个小巧的脚本语言)插件，解析第一步的配置逻辑，并实现具体的逻辑功能。最后将lua插件集成到openresty软件中，openresty启动时加载具体的配置规则即可。

在一个实施例中，在接收业务请求之前还包括：加载配置文件中的所述路由规则。即在处理业务请求之前，先启动openresty软件，加载配置的openresty配置文件，以解析配置文件中的路由规则。

例如，本实施例通过路由规则在服务请求中如何实现请求的代理，组合，替换等操作。以以下配置为例：

Route:

/api/ping:

POST:

pre_host:127.0.0.1:3000

pre_path:/api/user/

replace_host:127.0.0.1:3000

replace_path:/api/user/users/

RegexRoute:

/api/user/([a-fA-F0-9]{24})/info/$:

method:[POST,PUT,GET]

enable_match_value:true

replace_host:127.0.0.1:5001

replace_path:/api/user/s％/info/

本申请使用YAML格式解析数据。如上代码示例所示，第一层包括Route和RegexRoute,分别对应了静态的路由规则和带正则的路由规则(即，可取出请求中特定格式的数据传递到后续的请求中)。

在Route中的示例，/api/ping代表是一次请求的URI,POST,代表的是请求时的请求方法。

本实施例支持对请求的组装和替换，主要通过三个请求的步骤来实现，即：

请求前请求，即在开始真正请求之前先触发一次其他的请求，使用场景可覆盖到api调用统计，api功能增强，外部数据注入等。可通过pre_host,配置请求的地址，pre_path，配置请求的uri。

请求替换，即把正式请求替换为指定的请求，使用场景可覆盖到客户定制完全不同的逻辑，但实现了接口的兼容，即前端无感知的定制。主要应对，无法使用请求前请求和请求后请求进行定制的复杂定制场景等。可通过replace_host配置请求的地址,replace_path配置请求的uri。

请求后请求，即在正式请求请求之后触发的请求，使用场景一般为，请求后通知，或者其他需要异步触发的定制逻辑，等等。可通过post_host配置请求的地址,post_path配置请求的uri。

因此，本实施例支持对这三步请求的任意配置，同时，支持静态URI匹配和正则URI匹配，支持请求方法匹配，指向在任意步骤中设置cookie。

在一个实施例中，所述路由规则包括静态的路由规则(Route)和带正则的路由规则(RegexRoute)，所述根据所述请求域名匹配对应的配置文件包括：根据所述请求域名的统一资源标识符和/或请求头参数和/或请求体参数在所述配置文件的静态的路由规则中匹配路由规则，若匹配到，则将该配置文件确定为匹配到的配置文件并停止匹配；若未匹配到，则根据所述请求域名的统一资源标识符和/或请求头参数和/或请求体参数在所述配置文件的带正则的路由规则中匹配路由规则，若匹配到，则将该配置文件确定为匹配到的配置文件并停止匹配；若未匹配到，则确定为无匹配的配置文件。

例如，以上述配置为例进行说明。本系统可以定义为Nexus，是为了解决我们定制和通用迭代，升级，定制过程中碰到的难点，复杂的一套协作框架。可以将上述配置保存到Nexus根路径下conf/config.yaml文件中。这个文件作为路由规则的配置文件，在系统启动时会自动加载。当一个请求发送到Nexus，Nexus会首先在Route中按照URI和请求方法进行规则匹配，如匹配到，则到下一步执行对应的逻辑。如在Route中无匹配，则进行RegexRoute匹配，匹配到同样进行下一步的逻辑，无匹配则转发到默认的应用服务器。

在步骤S102中：当匹配到所述请求域名对应的配置文件时，根据所述配置文件配置的路由规则请求业务服务器获取返回结果，根据所述返回结果得到响应数据。

在一个实施例中，当未匹配到所述请求域名对应的配置文件时，根据默认配置文件请求默认的业务服务器。

在一个实施例中，所述静态的路由规则和所述带正则的路由规则均包括以下至少一个路由逻辑：预请求路径、替换路径和附有请求实体的更新路径的处理逻辑，所述根据所述配置文件配置的路由规则请求业务服务器获取返回结果包括：当匹配到的路由规则为静态的路由规则时，以所述业务请求的请求路径根据所述路由逻辑请求业务服务器获取返回结果；当匹配到的路由规则为带正则的路由规则时，获取所述业务请求的请求路径中的资源地址，将所述资源地址作为参数拼接在转发路径上，以所述转发路径根据所述路由逻辑请求业务服务器获取返回结果。

在一个实施例中，所述根据所述路由逻辑请求业务服务器获取返回结果包括：判断所述路由逻辑是否有预请求路径，若有，则根据所述业务请求的请求头参数和请求体参数，请求预请求路径对应的主机接口获取第一返回数据，若无，进行下一逻辑判断；判断所述路由逻辑是否有替换路径，若有、且当所述路由逻辑有所述预请求路径时，则根据所述业务请求的请求头参数、所述第一返回数据作为请求体参数，请求替换路径对应的主机接口获取第二返回数据，若有、且当所述路由逻辑无所述预请求路径时，则根据所述业务请求的请求头参数和请求体参数，请求替换路径对应的主机接口获取第二返回数据，若无，则根据默认的配置文件请求默认业务服务器获取第二返回数据；判断路由逻辑中是否有附有请求实体的更新路径，若有，则根据所述业务请求的请求头参数、所述第二返回数据作为请求体参数，请求附有请求实体的更新路径对应的主机接口获取第三返回结果，若无，则停止执行。

在一个实施例中，所述根据所述返回结果得到响应数据包括：当所述路由逻辑无附有请求实体的更新路径时，将所述第二返回数据确定为所述响应数据，当所述路由逻辑有附有请求实体的更新路径时，将所述第三返回数据确定为所述响应数据。在一个实施例中，所述根据所述返回结果得到响应数据包括：当所述路由逻辑无附有请求实体的更新路径时，将所述第二返回数据确定为所述响应数据，当所述路由逻辑有附有请求实体的更新路径时，将所述第三返回数据确定为所述响应数据。

例如，本实施例的系统可以为SaaS系统，系统设计上为不同的租户使用了不同的域名。如系统官网www.bestcem.com,租户1域名：idy.bestcem.com,租户2域名：arg.bestcem.com。用户从浏览器发起请求，首先根据用户的域名匹配到对应的nginx配置文件。默认所有租户都会走*.bestcem.com配置文件，有明确配置则走配置的文件。当openresty启动时，定制的nginx配置文件，会加载配置的请求匹配和转换规则。用户请求先依据URI(统一资源标识符)在Route(即配置的规则，静态的路由规则)中匹配，如匹配不到则到RegexRoute(带正则的路由规则)中匹配。

匹配到任意规则，则依据配置的转换逻辑进行请求。如无匹配，依照默认的*.bestcem.com对应的配置文件请求应用服务器，并返回结果。

在这里，当匹配到Router中的路由规则的逻辑(Rule)时，则取出对应的pre_path(预请求路径),replace_path(替换路径),post_path(附有请求实体的更新路径)，以进行接下来的请求。当匹配到RegexRoute,检查是否需要提取原URI中的数据，如要提取，则执行提取并拼接至pre_path,replace_path,post_path。

在匹配到对应的路由规则进行处理时，判断Rule中是否有pre_path。如果有，使用用户请求的请求头和请求体等参数请求pre_host的pre_path接口，获取返回数据，并使用返回数据作为下一步请求的请求体参数。如果没有，到下一步判断。

判断Rule中是否有replace_path(更新路径)。这一步的请求头参数依然使用用户请求的请求头参数。请求体则会依据是否有pre_path来决定。此时如有pre_path的请求，请求体为pre_path请求的响应数据。如无pre_path的请求，请求体为用户原请求的请求体。如果有replace_path，请求replace_host的replace_path接口。如果没有replace_path配置，此时会依据默认的*.bestcem.com对应的配置文件请求应用服务器。

判断是否有post_path。这一步的请求头参数依然使用用户请求的请求头参数。请求体为replace_path请求的响应结果。如果有post_path,请求post_host的post_path接口，获取返回结果，直接返回给浏览器。如果没有，直接返回浏览器replacepath接口的响应结果。

需要说明的是，对于pre_path,replace_path,post_path三步的请求响应头会做并集随返回浏览器，一并返回。

具体的，以上述配置为例进行说明。

Route的匹配和处理：如/api/ping的规则，当请求的URI与/api/ping,匹配，且请求方法是POST时，先请求127.0.0.1:3000/api/user/,获取返回结果，然后将返回结果转为请求体，发送到127.0.0.1:3000/api/user/users/,最终返回数据到浏览器。

RegexRoute的匹配和处理：RegexRoute的处理流程与Route一致，在路径匹配上做了增强。以/api/user/([a-fA-F0-9]{24})/info/$为例，当请求为/api/user/6050236737e13eeaa3721de9/info/时，6050236737e13eeaa3721de9其实作为资源id出现在路径中，经常需要将此id作为参数拼接在转发的路径上。如replace_path:/api/user/s％/info/在实际请求时会转换为/api/user/6050236737e13eeaa3721de9/info/进行请求。

在步骤S103中：发送所述响应数据至前端浏览器，以使所述前端浏览器对所述响应数据渲染展示。当根据路由规则请求业务服务器，得到响应数据后，将响应数据发送至前端浏览器，该浏览器为用户发起业务请求的浏览器，以使所述前端浏览器对所述响应数据渲染，实现用户访问需求。

由此，本申请实施例提供的业务请求处理方法，通过接收业务请求，获取所述业务请求中的请求域名，根据所述请求域名匹配预设的配置文件，每个所述配置文件配置有路由规则；当匹配到所述请求域名对应的配置文件时，根据所述配置文件配置的路由规则请求业务服务器获取返回结果，根据所述返回结果得到响应数据；发送所述响应数据至前端浏览器，以使所述前端浏览器对所述响应数据渲染展示。提供一种高复用、易维护、业务隔离、低资源占用的定制需求开发框架，实现对于不同客户之间迥然不同的定制需求，同时为SaaS开发团队降本增效低耦合。

图2示出了本申请一个实施例提供的业务请求处理系统的主要模块示意图。为了便于说明，仅示出与本申请实施例相关的部分，详述如下：

一种业务请求处理系统200，包括：

请求接收模块201，用于接收业务请求，获取所述业务请求中的请求域名，根据所述请求域名匹配预设的配置文件，每个所述配置文件配置有路由规则；

请求处理模块202，用于：当匹配到所述请求域名对应的配置文件时，根据所述配置文件配置的路由规则请求业务服务器获取返回结果，根据所述返回结果得到响应数据；

响应数据发送模块203，用于发送所述响应数据至前端浏览器，以使所述前端浏览器对所述响应数据渲染展示。

对于请求接收模块201：用于接收业务请求，获取所述业务请求中的请求域名，根据所述请求域名匹配预设的配置文件，每个所述配置文件配置有路由规则。

在这里，整体方案的实现原理主要是通过配置OpenResty(nginx+lua动态服务代理网关)的路由规则，满足不同租户之间相同的服务调用，后端的逻辑不同的功能。可以通过对于不同的SaaS软件用户配置不同的路由规则，进而实现对于不同用户的不同需求。在进行openresty文件配置时，对于不同的用户的个性化需求，可以根据个性化逻辑进行配置路由逻辑，对于通用的需求可以配置默认的路由逻辑。当有需求的用户请求业务时，请求路由至定制的逻辑，当没有定制需求的用户请求业务时，请求路由至SaaS通用代码。

需要说明的是，不同的客户使用不同的二级域名来访问系统，因此可以通过识别不同的用户的请求业务时的请求域名，识别出该业务请求对应的配置文件，然后基于配置文件中配置的路由规则进行请求业务服务器。

在配置openresty路由规则时，可以先进行编写yaml(是一个可读性高，用来表达数据序列化的格式)配置文件，主要包含了路由调度逻辑，如接收到一个请求，接下来是转发，组合，替换等逻辑。然后为客户定制的逻辑进行代码单独开发。再通过编写lua(是一个小巧的脚本语言)插件，解析第一步的配置逻辑，并实现具体的逻辑功能。最后将lua插件集成到openresty软件中，openresty启动时加载具体的配置规则即可。

在一个实施例中，在接收业务请求之前还包括：加载配置文件中的所述路由规则。即在处理业务请求之前，先启动openresty软件，加载配置的openresty配置文件，以解析配置文件中的路由规则。

例如，本实施例通过路由规则在服务请求中如何实现请求的代理，组合，替换等操作。以以下配置为例：

Route:

/api/ping:

POST:

pre_host:127.0.0.1:3000

pre_path:/api/user/

replace_host:127.0.0.1:3000

replace_path:/api/user/users/

RegexRoute:

/api/user/([a-fA-F0-9]{24})/info/$:

method:[POST,PUT,GET]

enable_match_value:true

replace_host:127.0.0.1:5001

replace_path:/api/user/s％/info/

本申请使用YAML格式解析数据。如上代码示例所示，第一层包括Route和RegexRoute,分别对应了静态的路由规则和带正则的路由规则(即，可取出请求中特定格式的数据传递到后续的请求中)。

在Route中的示例，/api/ping代表是一次请求的URI,POST,代表的是请求时的请求方法。

本实施例支持对请求的组装和替换，主要通过三个请求的步骤来实现，即：

请求前请求，即在开始真正请求之前先触发一次其他的请求，使用场景可覆盖到api调用统计，api功能增强，外部数据注入等。可通过pre_host,配置请求的地址，pre_path，配置请求的uri。

请求替换，即把正式请求替换为指定的请求，使用场景可覆盖到客户定制完全不同的逻辑，但实现了接口的兼容，即前端无感知的定制。主要应对，无法使用请求前请求和请求后请求进行定制的复杂定制场景等。可通过replace_host配置请求的地址,replace_path配置请求的uri。

请求后请求，即在正式请求请求之后触发的请求，使用场景一般为，请求后通知，或者其他需要异步触发的定制逻辑，等等。可通过post_host配置请求的地址,post_path配置请求的uri。

因此，本实施例支持对这三步请求的任意配置，同时，支持静态URI匹配和正则URI匹配，支持请求方法匹配，指向在任意步骤中设置cookie。

在一个实施例中，所述路由规则包括静态的路由规则(Route)和带正则的路由规则(RegexRoute)，所述根据所述请求域名匹配对应的配置文件包括：根据所述请求域名的统一资源标识符和/或请求头参数和/或请求体参数在所述配置文件的静态的路由规则中匹配路由规则，若匹配到，则将该配置文件确定为匹配到的配置文件并停止匹配；若未匹配到，则根据所述请求域名的统一资源标识符和/或请求头参数和/或请求体参数在所述配置文件的带正则的路由规则中匹配路由规则，若匹配到，则将该配置文件确定为匹配到的配置文件并停止匹配；若未匹配到，则确定为无匹配的配置文件。

例如，以上述配置为例进行说明。本系统可以定义为Nexus，是为了解决我们定制和通用迭代，升级，定制过程中碰到的难点，复杂的一套协作框架。可以将上述配置保存到Nexus根路径下conf/config.yaml文件中。这个文件作为路由规则的配置文件，在系统启动时会自动加载。当一个请求发送到Nexus，Nexus会首先在Route中按照URI和请求方法进行规则匹配，如匹配到，则到下一步执行对应的逻辑。如在Route中无匹配，则进行RegexRoute匹配，匹配到同样进行下一步的逻辑，无匹配则转发到默认的应用服务器。

对于请求处理模块202：用于当匹配到所述请求域名对应的配置文件时，根据所述配置文件配置的路由规则请求业务服务器获取返回结果，根据所述返回结果得到响应数据。

在一个实施例中，当未匹配到所述请求域名对应的配置文件时，根据默认配置文件请求默认的业务服务器。

在一个实施例中，所述静态的路由规则和所述带正则的路由规则均包括以下至少一个路由逻辑：预请求路径、替换路径和附有请求实体的更新路径的处理逻辑，所述根据所述配置文件配置的路由规则请求业务服务器获取返回结果包括：当匹配到的路由规则为静态的路由规则时，以所述业务请求的请求路径根据所述路由逻辑请求业务服务器获取返回结果；当匹配到的路由规则为带正则的路由规则时，获取所述业务请求的请求路径中的资源地址，将所述资源地址作为参数拼接在转发路径上，以所述转发路径根据所述路由逻辑请求业务服务器获取返回结果。

在一个实施例中，所述根据所述路由逻辑请求业务服务器获取返回结果包括：判断所述路由逻辑是否有预请求路径，若有，则根据所述业务请求的请求头参数和请求体参数，请求预请求路径对应的主机接口获取第一返回数据，若无，进行下一逻辑判断；判断所述路由逻辑是否有替换路径，若有、且当所述路由逻辑有所述预请求路径时，则根据所述业务请求的请求头参数、所述第一返回数据作为请求体参数，请求替换路径对应的主机接口获取第二返回数据，若有、且当所述路由逻辑无所述预请求路径时，则根据所述业务请求的请求头参数和请求体参数，请求替换路径对应的主机接口获取第二返回数据，若无，则根据默认的配置文件请求默认业务服务器获取第二返回数据；判断路由逻辑中是否有附有请求实体的更新路径，若有，则根据所述业务请求的请求头参数、所述第二返回数据作为请求体参数，请求附有请求实体的更新路径对应的主机接口获取第三返回结果，若无，则停止执行。

在一个实施例中，所述根据所述返回结果得到响应数据包括：当所述路由逻辑无附有请求实体的更新路径时，将所述第二返回数据确定为所述响应数据，当所述路由逻辑有附有请求实体的更新路径时，将所述第三返回数据确定为所述响应数据。在一个实施例中，所述根据所述返回结果得到响应数据包括：当所述路由逻辑无附有请求实体的更新路径时，将所述第二返回数据确定为所述响应数据，当所述路由逻辑有附有请求实体的更新路径时，将所述第三返回数据确定为所述响应数据。

例如，本实施例的系统可以为SaaS系统，系统设计上为不同的租户使用了不同的域名。如系统官网www.bestcem.com,租户1域名：idy.bestcem.com,租户2域名：arg.bestcem.com。用户从浏览器发起请求，首先根据用户的域名匹配到对应的nginx配置文件。默认所有租户都会走*.bestcem.com配置文件，有明确配置则走配置的文件。当openresty启动时，定制的nginx配置文件，会加载配置的请求匹配和转换规则。用户请求先依据URI(统一资源标识符)在Route(即配置的规则，静态的路由规则)中匹配，如匹配不到则到RegexRoute(带正则的路由规则)中匹配。

匹配到任意规则，则依据配置的转换逻辑进行请求。如无匹配，依照默认的*.bestcem.com对应的配置文件请求应用服务器，并返回结果。

在这里，当匹配到Router中的路由规则的逻辑(Rule)时，则取出对应的pre_path(预请求路径),replace_path(替换路径),post_path(附有请求实体的更新路径)，以进行接下来的请求。当匹配到RegexRoute,检查是否需要提取原URI中的数据，如要提取，则执行提取并拼接至pre_path,replace_path,post_path。

在匹配到对应的路由规则进行处理时，判断Rule中是否有pre_path。如果有，使用用户请求的请求头和请求体等参数请求pre_host的pre_path接口，获取返回数据，并使用返回数据作为下一步请求的请求体参数。如果没有，到下一步判断。

判断Rule中是否有replace_path(更新路径)。这一步的请求头参数依然使用用户请求的请求头参数。请求体则会依据是否有pre_path来决定。此时如有pre_path的请求，请求体为pre_path请求的响应数据。如无pre_path的请求，请求体为用户原请求的请求体。如果有replace_path，请求replace_host的replace_path接口。如果没有replace_path配置，此时会依据默认的*.bestcem.com对应的配置文件请求应用服务器。

判断是否有post_path。这一步的请求头参数依然使用用户请求的请求头参数。请求体为replace_path请求的响应结果。如果有post_path,请求post_host的post_path接口，获取返回结果，直接返回给浏览器。如果没有，直接返回浏览器replacepath接口的响应结果。

需要说明的是，对于pre_path,replace_path,post_path三步的请求响应头会做并集随返回浏览器，一并返回。

具体的，以上述配置为例进行说明。

Route的匹配和处理：如/api/ping的规则，当请求的URI与/api/ping,匹配，且请求方法是POST时，先请求127.0.0.1:3000/api/user/,获取返回结果，然后将返回结果转为请求体，发送到127.0.0.1:3000/api/user/users/,最终返回数据到浏览器。

RegexRoute的匹配和处理：RegexRoute的处理流程与Route一致，在路径匹配上做了增强。以/api/user/([a-fA-F0-9]{24})/info/$为例，当请求为/api/user/6050236737e13eeaa3721de9/info/时，6050236737e13eeaa3721de9其实作为资源id出现在路径中，经常需要将此id作为参数拼接在转发的路径上。如replace_path:/api/user/s％/info/在实际请求时会转换为/api/user/6050236737e13eeaa3721de9/info/进行请求。

对于响应数据发送模块203：用于发送所述响应数据至前端浏览器，以使所述前端浏览器对所述响应数据渲染展示。当根据路由规则请求业务服务器，得到响应数据后，将响应数据发送至前端浏览器，该浏览器为用户发起业务请求的浏览器，以使所述前端浏览器对所述响应数据渲染，实现用户访问需求。

由此，本申请实施例提供的业务请求处理系统，提供一种高复用、易维护、业务隔离、低资源占用的定制需求开发框架，实现对于不同客户之间迥然不同的定制需求，同时为SaaS开发团队降本增效低耦合。

本申请实施例还提供一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当一个或多个程序被一个或多个处理器执行，使得一个或多个处理器实现本申请实施例的业务请求处理方法。

本申请实施例还提供一种计算机可读介质，其上存储有计算机程序，程序被处理器执行时实现本申请实施例的业务请求处理方法。

图3示出了可以应用本申请实施例的业务请求处理方法或系统的示例性系统架构300。

如图3所示，系统架构300可以包括终端设备301、302、303，网络304和服务器305。网络304用以在终端设备301、302、303和服务器305之间提供通信链路的介质。网络304可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备301、302、303通过网络304与服务器305交互，以接收或发送消息等。终端设备301、302、303上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等。

终端设备301、302、303可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于车载智能屏、智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器305可以是提供各种服务的服务器，例如对用户利用终端设备301、302、303所发送的往来消息提供支持的后台管理服务器。后台管理服务器可以在接收到终端设备请求后进行分析等处理，并将处理结果反馈给终端设备。

需要说明的是，本申请实施例所提供的业务请求处理方法一般由服务器305执行，相应地，业务请求处理系统一般设置于服务器305中。

应该理解，图3中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

下面参考图4，其示出了适于用来实现本申请实施例的电子设备的计算机系统400的结构示意图。图4示出的计算机系统仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图4所示，计算机系统400包括中央处理单元(CPU)401，其可以根据存储在只读存储器(ROM)402中的程序或者从存储部分408加载到随机访问存储器(RAM)403中的程序而执行各种适当的动作和处理。在RAM 403中，还存储有系统400操作所需的各种程序和数据。CPU 401、ROM 402以及RAM 403通过总线404彼此相连。输入/输出(I/O)接口405也连接至总线404。

以下部件连接至I/O接口405：包括键盘、鼠标等的输入部分406；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分407；包括硬盘等的存储部分408；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分409。通信部分409经由诸如因特网的网络执行通信处理。驱动器410也根据需要连接至I/O接口405。可拆卸介质411，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器410上，以便于从其上读出的计算机程序根据需要被安装入存储部分408。

特别地，根据本申请公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分409从网络上被下载和安装，和/或从可拆卸介质411被安装。在该计算机程序被中央处理单元(CPU)401执行时，执行本申请的系统中限定的上述功能。

需要说明的是，本申请所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括确定模块、提取模块、训练模块和筛选模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定，例如，确定模块还可以被描述为“确定候选用户集的模块”。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种业务请求处理方法，其特征在于，包括：

接收业务请求，获取所述业务请求中的请求域名，根据所述请求域名匹配预设的配置文件，每个所述配置文件配置有路由规则；

当匹配到所述请求域名对应的配置文件时，根据所述配置文件配置的路由规则请求业务服务器获取返回结果，根据所述返回结果得到响应数据；

发送所述响应数据至前端浏览器，以使所述前端浏览器对所述响应数据渲染展示。

2.根据权利要求1所述的业务请求处理方法，其特征在于，在接收业务请求之前还包括：加载配置文件中的所述路由规则。

3.根据权利要求1所述的业务请求处理方法，其特征在于，还包括：当未匹配到所述请求域名对应的配置文件时，根据默认配置文件请求默认的业务服务器。

4.根据权利要求1所述的业务请求处理方法，其特征在于，所述路由规则包括静态的路由规则和带正则的路由规则，所述根据所述请求域名匹配对应的配置文件包括：根据所述请求域名的统一资源标识符和/或请求头参数和/或请求体参数在所述配置文件的静态的路由规则中匹配路由规则，若匹配到，则将该配置文件确定为匹配到的配置文件并停止匹配；若未匹配到，则根据所述请求域名的统一资源标识符和/或请求头参数和/或请求体参数在所述配置文件的带正则的路由规则中匹配路由规则，若匹配到，则将该配置文件确定为匹配到的配置文件并停止匹配；若未匹配到，则确定为无匹配的配置文件。

5.根据权利要求4所述的业务请求处理方法，其特征在于，所述静态的路由规则和所述带正则的路由规则均包括以下至少一个路由逻辑：预请求路径、替换路径和附有请求实体的更新路径的处理逻辑，所述根据所述配置文件配置的路由规则请求业务服务器获取返回结果包括：当匹配到的路由规则为静态的路由规则时，以所述业务请求的请求路径根据所述路由逻辑请求业务服务器获取返回结果；当匹配到的路由规则为带正则的路由规则时，获取所述业务请求的请求路径中的资源地址，将所述资源地址作为参数拼接在转发路径上，以所述转发路径根据所述路由逻辑请求业务服务器获取返回结果。

6.根据权利要求5所述的业务请求处理方法，其特征在于，所述根据所述路由逻辑请求业务服务器获取返回结果包括：判断所述路由逻辑是否有预请求路径，若有，则根据所述业务请求的请求头参数和请求体参数，请求预请求路径对应的主机接口获取第一返回数据，若无，进行下一逻辑判断；判断所述路由逻辑是否有替换路径，若有、且当所述路由逻辑有所述预请求路径时，则根据所述业务请求的请求头参数、所述第一返回数据作为请求体参数，请求替换路径对应的主机接口获取第二返回数据，若有、且当所述路由逻辑无所述预请求路径时，则根据所述业务请求的请求头参数和请求体参数，请求替换路径对应的主机接口获取第二返回数据，若无，则根据默认的配置文件请求默认业务服务器获取第二返回数据；判断路由逻辑中是否有附有请求实体的更新路径，若有，则根据所述业务请求的请求头参数、所述第二返回数据作为请求体参数，请求附有请求实体的更新路径对应的主机接口获取第三返回结果，若无，则停止执行。

7.根据权利要求6所述的业务请求处理方法，其特征在于，所述根据所述返回结果得到响应数据包括：当所述路由逻辑无附有请求实体的更新路径时，将所述第二返回数据确定为所述响应数据，当所述路由逻辑有附有请求实体的更新路径时，将所述第三返回数据确定为所述响应数据。

8.一种业务请求处理系统，其特征在于，包括：

请求接收模块，用于接收业务请求，获取所述业务请求中的请求域名，根据所述请求域名匹配预设的配置文件，每个所述配置文件配置有路由规则；

请求处理模块，用于：当匹配到所述请求域名对应的配置文件时，根据所述配置文件配置的路由规则请求业务服务器获取返回结果，根据所述返回结果得到响应数据；

响应数据发送模块，用于发送所述响应数据至前端浏览器，以使所述前端浏览器对所述响应数据渲染展示。

9.一种电子设备，其特征在于，包括存储器和处理器，所述存储器中存储有计算机程序，所述计算机程序被所述处理器执行时，使得所述处理器执行权利要求1至7中任一项所述的业务请求处理方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时，使得所述处理器执行权利要求1至7中任一项所述的业务请求处理方法的步骤。

Images