服务调用方法、装置及服务器与流程

本申请涉及通信技术领域，更具体地说，涉及一种服务调用方法、装置及服务器。

背景技术：

通过第三方的航空业务管理系统可以对不同航空公司的航班业务进行管理。如，航空公司的工作人员可以登录第三方航空业务管理系统来查询该航空公司下所涉及到的各航班以及管理航班的票务等信息。

其中，每个航空公司所需要的业务服务种类都会有多种，如，航空公司的业务服务可能会涉及到航班控制、机票销售以及报表统计等等业务服务。为了满足同一航空公司的不同业务服务需求，需要第三方的航空业务管理系统配置并调用不同业务服务后台子系统的服务接口。在此基础上，第三方的航空业务管理系统需要针对每个航空公司需要开发不同种业务服务的页面，同时分别定义不同的业务服务所需的接口调用方法。

由于第三方的航空业务管理系统会涉及多个航空公司相关的业务服务，而不同航班的同种业务的业务服务也会存在差别，因此，第三方的航空业务管理系统需要开发大量的业务服务的页面，同时开发和定义大量的接口调用方法，增加了业务服务调用的复杂度。

技术实现要素：

本申请提供了一种服务调用方法、装置及服务器，以减少调用业务服务的接口的复杂度。

为了实现如上目的，本申请提供了如下技术方案：

一方面，本申请还提供了一种服务调用方法，包括：

在用户通过终端登录航空业务管理系统后，向所述用户的终端输出业务管理页面；

获得所述用户在所述业务管理页面输入的至少一个业务操作请求，所述业务操作请求用于请求目标业务服务；

获得所述用户关联的服务特征信息，所述服务特征信息用于表征所述用户所属的航空公司以及所述用户所属的航空公司针对所述用户提供业务服务的需求类型；

针对每个业务操作请求，从所述业务操作请求所请求的目标业务服务关联的至少一个服务接口地址中，确定出与所述服务特征信息匹配的目标服务接口地址，调用所述目标服务接口地址所指向的服务接口处理所述业务操作请求。

又一方面，本申请还提供了一种服务调用装置，包括：

页面输出单元，用于在用户通过终端登录航空业务管理系统后，向所述用户的终端输出业务管理页面；

请求获得单元，用于获得所述用户在所述业务管理页面输入的至少一个业务操作请求，所述业务操作请求用于请求目标业务服务；

信息获得单元，用于获得所述用户关联的服务特征信息，所述服务特征信息用于表征所述用户所属的航空公司以及所述用户所属的航空公司针对所述用户提供业务服务的需求类型；

调用处理单元，用于针对每个业务操作请求，从所述业务操作请求所请求的目标业务服务关联的至少一个服务接口地址中，确定出与所述服务特征信息匹配的目标服务接口地址，调用所述目标服务接口地址所指向的服务接口处理所述业务操作请求。

又一方面，本申请还提供了一种服务器，所述服务器包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如上所述的服务调用方法。

通过以上技术方案可知，本申请可以向不同航空公司的用户提供统一的业务管理界面，且任意航空公司的用户在登录业务管理系统之后，均可以在业务管理界面中申请业务操作请求。在此基础上，业务管理系统可以根据用户关联的服务特征信息，自动匹配出该业务操作请求所请求的目标业务服务所需调用的服务接口地址并调用相应的服务接口，从而无需针对不同航空公司的每种业务服务单独开发一套业务页面并定义接口调用方法，进而降低了服务调用的复杂度。

附图说明

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

图1为本申请实施例提供的一种服务调用方法一个流程示意图；

图2为航空公司的业务服务配置启用的服务接口的一种实现流程示意图；

图3为本申请中地址配置界面的一种示意图；

图4为本申请实施例提供的一种服务调用方法又一个流程示意图；

图5为本申请中配置路由规则的规则配置界面的一种示意图；

图6为本申请规则脚本输入界面的一种示意图；

图7为本申请实施例提供的一种服务调用装置一个实施例的组成结构示意图；

图8为本申请实施例提供的一种服务器的组成结构示意图。

说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的部分，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示的以外的顺序实施。

具体实施方式

本申请的方案适用于航空业务管理系统，该航空业务管理系统为航空公司之外的第三方管理平台，该航空业务管理系统可以接入多个航空公司，以为多个航空公司提供航班以及售票等相关业务的业务服务。

在本申请中，航空业务服务系统可以为多个服务器组成的集群或者分布式系统等，如航空业务服务系统可以为云平台等。

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

如图1所示，其示出了本申请的一种服务调用方法一个实施例的流程示意图，本实施例的方法应用于航空业务管理系统，本实施例的方法可以包括：

s101，在用户通过终端登录航空业务管理系统后，向用户的终端输出业务管理页面。

其中，用户可以通过终端的浏览器登录到该航空业务管理系统。可以理解的是，在用户成功登录航空业务管理系统之前，航空业务管理系统会对用户的身份进行验证。如，验证用户的用户名和密码等，以判断用户是否为接入该航空业务管理系统的航空公司的工作人员。

该业务管理页面为航空业务管理系统向不同航空公司的用户提供的统一的入口页面。该业务管理页面可以提供用户输入业务服务相关的参数并触发业务操作请求。

如，在该业务管理页面可以包括多个类别的服务选项，在选择了某种服务选项后，可以展现该服务选项相关界面，在该种服务选项相关的界面上可以进行相应的业务服务。例如，以航班管理这一应用场景，服务选项可以包括航班查询、航班修改、航班批量修改以及航班历史等等服务选项，在点击了服务选项后可以展现出相应的子页面，从而可以在子页面中输入业务操作。

s102，获得用户在业务管理页面输入的至少一个业务操作请求，业务操作请求用于请求目标业务服务。

其中，该业务操作请求可以指示有所请求的目标业务服务，如，可以携带目标业务服务的名称，或者所需调用的业务服务的服务接口名称等。

如，业务操作请求为用户请求修改航班的请求，该业务操作请求所请求的业务服务为航班修改。

可以理解的是，该业务操作请求还可以包括请求目标业务服务的相关参数，以便后续通过调用相应的接口完成该业务操作请求相关处理。其中，业务操作请求的参数可以基于用户在该业务管理界面上输入或者选择的信息来确定。

如，以目标业务服务为航班修改为例，在业务管理界面中，用户需要输入所需修改的航班的航班号、起飞日期，还可以选择该航班中待修改的舱位等等信息，在此基础上，用户点击界面中的“修改”选项可以触发业务操作请求，而业务操作请求也可以包括航班号、起飞日期以及舱位等信息中的一种或者几种。

s103，获得用户关联的服务特征信息。

其中，服务特征信息用于表征用户所属的航空公司以及用户所属的航空公司用户提供业务服务的需求类型。也就是说，该服务特征信息为用于表征适合为该用户提供该目标业务服务的服务接口的用户关联信息。

在本申请中，该服务特征信息至少可以包括该用户所属的航空公司。在实际应用中，该服务特征信息还可以包括该用户在其所属的航空公司中的用户角色。

作为一种可选方式，该用户关联的服务特征信息除了与用户自身的属性，如用户所属的航司以及用户角色等之外，还可以包括：配置的参数，如，指定参数的参数值等；还可以包括：用户关联的设备环境信息，如用户所在设备的ip地址和版本生效时间范围等等。

可以理解的是，在用户通过终端登录业务管理系统后，服务器便可以查询到该用户关联的这些服务特征信息。

s104，针对每个业务操作请求，从业务操作请求所请求的目标业务服务关联的至少一个服务接口地址中，确定出与服务特征信息匹配的目标服务接口地址，调用目标服务接口地址所指向的服务接口处理该业务操作请求。

可以理解的是，每个业务服务对应了一个服务接口名称，而由于不同航司或者同一航司的多种需求，同一服务接口名称可能会对应有多个服务接口，在此基础上，为了确定出需要通过哪些服务接口处理该业务操作请求，本申请需要利用用户关联的服务特征信息，来确定适合调用的服务接口。其中，每个服务接口对应一个服务接口地址。

其中，目标服务接口地址与服务特征信息匹配是指服务特征信息中的部分或者全部与该目标服务接口地址所配置的配置信息相匹配。

通过用户关联的服务特征信息可以精准的定位适合为给用户调用该服务接口，从而可以通过该第三方的业务管理系统来完成相应接口的调用。

在一种可选方式中，由于针对不同航司设置的接口对应的子系统所支持的数据格式也会有所不同，因此，每个服务接口地址还对应有相应的接口数据格式。相应的，调用目标服务接口地址所指向的服务接口处理转换格式后的该业务操作请求。

可以理解的是，在调用该目标服务接口地址所指向的服务接口后，还可以获得该服务接口返回的页面数据，则可以展现该页面数据，该页面数据可以包括业务操作请求的处理结果数据。

当然，如果同时存在多个业务操作请求且多个业务操作请求调用的是不同的服务接口，那么可以合并这多个业务操作请求对应的页面数据并展现。

可见，本申请可以向不同航空公司的用户提供统一的业务管理界面，且任意航空公司的用户在登录业务管理系统之后，均可以在业务管理界面中申请业务操作请求。在此基础上，业务管理系统可以根据用户关联的服务特征信息，自动匹配出该业务操作请求所请求的目标业务服务所需调用的服务接口地址并调用相应的服务接口，从而无需针对不同航空公司的每种业务服务单独开发一套业务页面并定义接口调用方法，进而降低了服务调用的复杂度。

同时，相对于针对不同航司的而不同需求单独涉及独立的程序入口和程序实现，为每种后台接口服务单独开发一套独立的代码，本申请的方案不仅可以减少接口调用开发的复杂度，也可以避免在服务需求变动后大量修改接口调用代码的情况。

另外，由于本申请是统一的业务管理界面来进行业务操作便可以自动调用到不同业务操作所需的接口版本，从而无需用户根据针对不同业务需求打开不同页面，从而可以减少用户错误打开页面，导致执行调整航班库存等操作出错的情况。

在本申请中，针对同一业务服务的服务接口名称，为该服务接口名称对应的各服务接口地址所配置的匹配规则可以有多种可能。

如，在一种可能的情况中，针对同一个航空公司的一种业务服务，可以不关心用户角色以及其他信息，在该种情况下，则可以为该业务服务配置一个或者多个服务接口以及服务接口对应的服务接口地址，但是在同一时刻可以仅仅启动一个服务接口对应的服务接口地址。在此基础上，获得的用户关联服务特征信息至少包括：该用户所属的航空公司的信息，如航空公司的标识或者名称等。

相应的，如该业务操作请求所请求的目标业务服务配置有该航空公司对应的一个已启用的服务接口地址，将该目标业务服务配置的服务接口地址确定为该服务特征信息匹配的目标服务接口地址。

以上该种情况属于一种简单配置服务接口的情况，针对该种情况，为了便于开发人员为航空公司的某个服务业务配置服务接口地址等相关参数，本申请还可以向开发人员提供相应的配置界面，以在航空公司的用户执行业务操作之前完成相应业务服务的接口相关的配置及启动。

如图2所示，其示出了本申请为航空公司的业务服务配置启用的服务接口的一种实现流程示意图，本流程可以包括：

s201，向开发人员的终端输出地址配置界面。

其中，该地址配置界面包括航司输入框和接口相关的至少一个接口参数输入框。

s202，基于开发人员在航司输入框内输入待配置的目标航空公司的信息以及至少一个接口参数输入框输入的接口参数，确定该目标航空公司为业务服务配置的服务接口地址并存储。

如图3所示为地址配置界面的一种示意图，由图3可以看出，该界面中包括“航司”的输入框，可以输入航空公司的标识或者简称等。同时，该界面中能够还包括接口名、数据格式、版本以及子系统的输入框，其中，子系统代表该接口名称对应接口所调用的子系统子系统。通过该接口名称、子系统和版本可以唯一确定一个接口地址。

可以理解的是，开发人员为一个航空公司的一个接口名称配置一个或者多个不同版本，每个版本对应一个接口地址。

s203，向开发人员展现接口地址选择界面。

其中，该接口地址选择界面包括目标航空公司为业务服务配置的至少一个服务接口地址。

s204，将该开发人员在接口地址选择界面选择的一个服务接口地址配置为该目标航空公司为业务服务开启的服务接口地址。

在实际应用中，该步骤s202和s203的开发人员可以相同也可以不同。通过步骤s202为一个接口名称配置了不同接口版本对应的服务接口地址后，如果希望采用某一个接口版本作为处理该业务服务所需调用的接口版本，则可以请求展现地址选择界面，相应的业务服务系统可以通过显示屏显示或者向开发人员的终端展现该接口地址选择界面，开发人员选择了某一个服务接口地址后，被选择的服务接口地址作为该业务服务所需调用的唯一接口地址。

在又一种可能的情况中，还可以根据需要针对不同航空公司、航空公司中的不同用户角色以及用户关联的其他信息来决定某个业务服务所需调用的接口地址。在该种情况中，可以针对同一个业务服务(或者说服务接口名称)配置多种路由规则，并根据用户的服务特征信息确定匹配路由规则。下面结合图4的流程图说明。

如图4所示，其示出了本申请一种服务调用方法又一个实施例的流程示意图，本实施例的方法应用于航空业务管理系统，本实施例的方法可以包括：

s401，在用户通过终端登录航空业务管理系统后，向用户的终端输出业务管理页面。

s402，获得用户在业务管理页面输入的至少一个业务操作请求，业务操作请求用于请求目标业务服务。

s403，获得用户关联的服务特征信息。

如，用户关联的服务特征信息可以包括：用户所属的航司、用户角色、用户所在设备的设备ip地址，当前时间等等信息中的部分或者全部。

s404，针对每个业务操作请求，确定该业务操作请求所请求的目标业务服务配置的多条路由规则。

如，每个业务操作请求会请求一种目标业务服务，该目标业务服务对应一个服务接口名称，同时，该服务接口名称可能会配置有多个服务接口地址。在本实施例中，每个服务接口地址对应一个路由规则，因此，可以得到多条待匹配的路由规则。

其中，该路由规则包括路由条件和服务接口地址。

路由规则中的路由条件是用于匹配该路由规则中服务接口地址的匹配条件，只有符合该路由条件才可以调用该服务接口地址。

作为一种可选方式，路由规则还可以包括：用于表征匹配优先级的优先级级别。该优先级级别用于后续确定路由规则与用户的服务特征信息进行匹配的先后顺序。

其中，路由规则可以为规则表达式，其可以以字符串的格式保存。

如，路由规则的格式的具体形式可以表示为：service:a<->b：priority，其中service为服务接口名，a为路由条件，b为子平台系统(代表服务接口地址)，priority为优先级。其中，优先级可以根据需要设置或者不设置。该路由规则表示对于服务接口service，如果a条件成立，那么调用后台子系统为b，此条规则的优先级为priority。

在路由规则中可以包括多种表达式符号，如，可以包括：

‘＝’表示条件精确匹配；

‘^’表示不相同；

‘&’条件的并且关系；

‘|’条件的或者关系；

括号，括号内的表达式优先计算。

其中，在路由规则中，涉及到的参数值可以采用逗号分割的多个值，并以通配符“*”表示通配。

举例说明：

路由规则1如下：

travelsky.air.inv.setsegmentclassinhibit:orihost＝172.24.1.39<->sat/2.0/json:1；

该路由规则中，travelsky.air.inv.setsegmentclassinhibit这个接口名称的访问，如果是用户所在设备的ip为172.24.1.39，那么访问后台托管软件统一调用服务的2.0版本的接口，并且数据格式为json，此条规则的优先级为1(其中，优先级的数值越小优先级越高)。

针对如上接口名称还可以存在路由规则2，路由规则2为：

travelsky.air.inv.setsegmentclassinhibit:orihost＝172.24.2.20<->sat/1.0/json:2；

该路由规则2表示：从ip为172.24.2.20的主机发出的请求，那么就去访问后台托管软件统一调用服务的1.0版本的接口。

可见，通过这两条路由规则可以实现根据不同的条件，自动判断并调用不同的后台子系统接口的效果。

s405，从该多条路由规则中，确定路由条件与该用户的服务特征信息匹配的目标路由规则，将该目标路由规则中的服务接口地址确定为目标服务接口地址。

如前面的介绍可知，由于每条路由规则中都包括路由条件，路由条件中包括满足该路由规则所需的条件，因此如果用户的服务特征信息与路由规则中的路由条件匹配，那么则说明该路由规则中的服务接口地址是需要调用的服务接口地址。为了便于区分，将与用户的服务特征信息匹配的路由规则称为目标路由规则。

其中，用户的服务特征信息可以包括多种类型的不同信息，而每条路由规则中的路由条件可以为一种或者几种类型所需满足的条件。

下面举例说明：

假设路由规则如下：

travelsky.air.inv.interf:param.key＝v1&user.airline＝mu<->tap/1.0/xml：1

该路由规则为在需要访问travelsky.air.inv.interf这一接口名称的接口时，路由条件为“key＝v1&user.airline＝mu”，已草拟，如果用户的服务特征信息存在名称为key且值为v1的参数，并用户所属的航空公司为mu，那么该用户特征信息与该路由规则匹配。同时，路由规则中服务接口地址为tap/1.0，表示依据该路由规则，需要调用tap1.0版本的接口。其中，xml表示数据格式，接口服务地址和数据格式组成为路由规则中的结果，结果使用‘/’分割的三部分数据，例如tap/1.0/xml对应的含义为：接口提供方/接口版本/数据格式。

又如，假设路由规则如下：

travelsky.air.inv.interf:time＝[2020-01-0100:00:00,2020-01-3100:00:00]<->tap/1.0/xml：1

如果需要访问travelsky.air.inv.interf接口，那么如果当前所处时间为2020年的1月份，则可以调用tap1.0版本的接口。

可以理解的是，针对同一个目标服务业务，本申请还可以各条路由规则的优先，即，在路由规则中还设置有优先级级别。在该种情况下，可以按照该多条路由规则的优先级级别从高到低的顺序，依次将用户的服务特征信息与该至少一条路由规则的路由条件进行匹配，直至确定出路由条件与用户的服务特征信息匹配的目标路由规则。

也就是说。按照路由规则的优先级的高度顺序，如果匹配出该用户的服务服务特征信息与某个路由规则中的路由条件匹配，则直接将该路由规则确定为目标路由规则，且无需再继续匹配其他路由规则。

举例说明，针对同一目标服务业务的服务接口名称配置了如下几条路由规则：

路由规则1：

travelsky.air.inv.interf:orihost＝172.24.1.*，10.221.158.159<->tap/2.0/xml：1

路由规则2：

travelsky.air.inv.interf:param.key^v1&(user.airline＝mu|user.airline＝ca)<->tap/1.0/xml：2

路由规则3：

travelsky.air.inv.interf:nil<->nil：3

在路由规则的最后的数字代表路由规则的优先级，其中数值越小优先级越高，如路由规则1的优先级为1，优先级最高；路由规则3的优先级为3，优先级最低。

相应的，可以将用户的服务特征信息先与路由规则1的路由条件匹配，如果路由规则不匹配，则将将服务特征信息与路由规则2的路由条件匹配，如果符合该路由规则2的路由条件，则将路由规则2确定为目标路由规则，而无需再匹配路由规则3。

s406，调用目标服务接口地址所指向的服务接口处理该业务操作请求。

当然，在调用目标服务接口地址之后，可以获得该服务接口所反映的页面数据并展现。

结合图3的相关介绍以及图4实施例的相关介绍可知，本申请在开发一个后台接口的调用时，只需要开发人员做接口定义以及配置，而其他涉及到接口调用的部分均由航空业务管理系统完成，从而减少了开发人员的其他编码工作。同时，通过本申请的方案将服务接口的路由配置工作与航班调整这个业务功能彻底解耦，业务功能开发者无需关心服务接口的链接操作以及交互细节，只需要专心处理功能本身的业务逻辑即可。

其中，图4实施例中涉及到的路由规则可以由开发人员配置，使得航空业务管理系统获得并保存路由规则。

如，在一种可能的情况中，可以先向开发人员的终端输出业务服务的规则配置界面，该规则配置界面包括：服务接口的服务接口地址的第一配置操作区和路由条件的第二配置操作区。

其中，该第一配置操作区可以输入服务接口对应的后台子系统和版本等表征服务接口地址的信息。还可以输入适合该服务接口地址所适合的数据格式的信息。

该第二配置操作区可以选择或者输入路由条件相关的参数以及条件。

在此基础上，该航空业务管理系统可以基于该开发人员在规则配置界面的第一配置操作区配置的服务接口地址的参数以及在第二配置操作区配置的路由条件相关的参数，确定业务服务的路由规则，并存储业务服务的路由规则。

下面结合图5进行说明，图5为本申请中配置路由规则的规则配置界面的一种示意图；

在图5为一个服务接口名称对应的与路由规则配置界面。其中，该界面中“目的地”对应的“后台”、“版本”、“数据格式”可以为第一配置操作区，用户可以选择后台子系统的名称以及版本，以完成接口服务地址的配置。同时，还可以配置该接口服务地址所指向的接口所采用的数据格式。

而目的地对应的输入栏为第二配置操作区，如在该第二配置操作区可以配置该路由规则中的至少一条路由条件，每条路由条件中可以包括至少一个条件及规则和值的输入框，同时，还可以设置每条路由规则的优先级。

可以理解的是，如果所需配置的路由规则较多，那么在界面上配置路由规则也可能会较为麻烦，为了进一步提高配置路由规则的便捷性，开发人员还可以直接生成用于配置路由规则的规则配置脚本。如图6所示为规则脚本输入界面的一种示意图，航空业务管理系统可以向开发人员的终端输出规则脚本输入界面，开发人员为某个服务接口名称输入用于配置路由规则的脚本。

该航空业务管理系统获得该开发人员为业务服务编写的规则配置脚本之后，可以解析该规则配置脚本，得到业务服务的至少一条路由规则；相应的，可以存储业务服务的至少一条路由规则。

可以理解的是，在开发人员通过脚本方式配置路由规则并生效后，开发人员无需再重复利用前面其他方式来配置该路由规则。

在本申请以上实施例中，在确定出目标服务接口地址之后，在调用该目标服务接口地址所指向的服务接口之前，还可以获得用户的权限验证信息，如根据所述权限验证信息验证出用户具备调用该服务接口的权限，则调用该目标服务接口地址所指向的服务接口。

在又一种可能的情况中，本申请在调用该目标服务接口地址所指向的服务接口后，还可以记录接口调用日志，在该日志中可以记录调用接口的时间以及耗时等等信息，以便后续根据该日志进行异常分析。

在又一种可能的情况中，在调用该目标服务接口地址所指向的服务接口之前，本申请还可以检测当前调用该目标服务接口地址所指向的服务接口的调用请求在单位时间内的总调用量是否超过设定阈值，如果未超过设定阈值，则执行该服务接口的调用；如果当前调用该服务接口的总调用量超过设定阈值，则说明并发请求量过大，则拒绝本次调用。如，单位时间可以为1分钟，具体可以根据需要设定。

在一种可能的情况中，本申请还可以通过添加扩展拦截器等程序，监控到不同接口对应的调用失败率。在此基础上，在一个业务服务配置有多条路由规则的情况下，在匹配出目标路由规则，且获得该目标路由规则中的服务接口地址之后，还可以检测该目标服务接口地址所指向的服务接口的历史调用失败率；如果该目标服务接口地址对应的历史调用失败率超过设定阈值，则可以依据多路由规则的优先级，将该用户的服务特征信息与尚未被匹配且优先级最高的路由规则进行匹配，直至匹配到与服务特征信息匹配且调用失败率低于设定阈值的路由规则。

如果该目标服务接口地址对应的历史调用失败率未超过设定阈值，则可以执行调用该目标服务接口地址所指向的服务接口的操作。

例如，假设针对某个后台服务接口，与用户的服务特征信息匹配的服务接口地址有a、b和c三个服务接口地址。a所在的路由规则的优先级最高，c所在的路由规则的优先级最低。如果a接口失败率达到90％，表示此接口存在问题。那么程序自动切换去调用b接口。如果b接口失败率同样超过阈值，那么去调用c接口。

当然，如果按照路由规则只能匹配到一个目标地址，如只匹配到a一个服务接口地址，就不需要动态切换这了。

对应本申请的一种服务调度方法，本申请还提供了一种服务调用装置。如图7所示，其示出了本申请一种服务调用装置一个实施例的组成结构示意图，本实施例的装置可以包括：

页面输出单元701，用于在用户通过终端登录航空业务管理系统后，向所述用户的终端输出业务管理页面；

请求获得单元702，用于获得所述用户在所述业务管理页面输入的至少一个业务操作请求，所述业务操作请求用于请求目标业务服务；

信息获得单元703，用于获得所述用户关联的服务特征信息，所述服务特征信息用于表征所述用户所属的航空公司以及所述用户所属的航空公司针对所述用户提供业务服务的需求类型；

调用处理单元704，用于针对每个业务操作请求，从所述业务操作请求所请求的目标业务服务关联的至少一个服务接口地址中，确定出与所述服务特征信息匹配的目标服务接口地址，调用所述目标服务接口地址所指向的服务接口处理所述业务操作请求。

在一种可能的实现方式中，该调用处理单元，包括：

规则确定单元，用于针对每个业务操作请求，确定所述业务操作请求所请求的目标业务服务配置的多条路由规则，所述路由规则包括路由条件和服务接口地址；

路由匹配单元，用于从所述多条路由规则中，确定路由条件与所述用户的服务特征信息匹配的目标路由规则，将所述目标路由规则中的服务接口地址确定为目标服务接口地址；

第一接口调用单元，用于调用所述目标服务接口地址所指向的服务接口处理所述业务操作请求。

作为一种可选方式，该规则确定单元确定出的路由规则还包括：用于表征匹配优先级的优先级级别；

路由匹配单元，具体为，用于按照所述多条路由规则的优先级级别从高到低的顺序，依次将所述用户的服务特征信息与所述至少一条路由规则的路由条件进行匹配，直至确定出路由条件与所述用户的服务特征信息匹配的目标路由规则，将所述目标路由规则中的服务接口地址确定为目标服务接口地址。

在一种可能的实现方式中，该装置还包括：

第一界面输出单元，用于在用户通过终端登录航空业务管理系统之前，向开发人员的终端输出业务服务的规则配置界面，所述规则配置界面包括：服务接口的服务接口地址的第一配置操作区和路由条件的第二配置操作区；

规则配置单元，用于基于所述开发人员在所述规则配置界面的第一配置操作区配置的服务接口地址的参数以及在所述第二配置操作区配置的路由条件相关的参数，确定所述业务服务的路由规则，并存储所述业务服务的路由规则。

在又一种可能的实现方式中，该装置还包括：

脚本获得单元，用于在用户通过终端登录航空业务管理系统之前，获得开发人员为业务服务编写的规则配置脚本；

规则获得单元，用于解析所述规则配置脚本，得到所述业务服务的至少一条路由规则；

规则存储单元，用于存储所述业务服务的至少一条路由规则。

在又一种可能的实现方式中，信息获得单元获得的该用户关联的服务特征信息包括：用户所属的航空公司的信息；

调用处理单元，包括：

第二接口调用单元，用于针对每个业务操作请求，如所述业务操作请求所请求的目标业务服务配置有所述航空公司对应的一个已启用的服务接口地址，将所述目标业务服务配置的服务接口地址确定为所述服务特征信息匹配的目标服务接口地址，调用所述目标服务接口地址所指向的服务接口处理所述业务操作请求。

在又一种可能的实现方式中，该装置还包括：

第二界面输出单元，用于在用户通过终端登录航空业务管理系统之前，向开发人员的终端输出地址配置界面，所述地址配置界面包括航司输入框和接口相关的至少一个接口参数输入框；

信息存储单元，用于基于开发人员在所述航司输入框内输入待配置的目标航空公司的信息以及所述至少一个接口参数输入框输入的接口参数，确定所述目标航空公司为业务服务配置的服务接口地址并存储；

第三界面输出单元，用于向所述开发人员展现接口地址选择界面，所述接口地址选择界面包括所述目标航空公司为所述业务服务配置的至少一个服务接口地址；

接口启动单元，用于将所述开发人员在所述接口地址选择界面选择的一个服务接口地址配置为所述目标航空公司为所述业务服务开启的服务接口地址。

又一方面，本申请还提供了一种服务器，该服务器可以为航空业务管理系统的服务器。如图8所示，其示出了本申请提供的服务器的组成结构示意图，由图8可以看出，该服务器至少包括处理器801和存储器802。

该服务器还可以包括通信模块803。其中，处理器801、存储器802以及通信模块803可以通过通信总线804相连。

其中，存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以实现如上任一实施例所述的服务调用方法。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

同时，本说明书中各实施例中记载的特征可以相互替换或者组合，使本领域专业技术人员能够实现或使用本申请。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

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