一种API混合多租户路由方法、系统和API网关与流程

本申请涉及软件技术领域，尤其涉及一种api混合多租户路由方法、系统和api网关。

背景技术：

saas(software-as-a-service，软件即服务)化之后，api(applicationprogramminginterface,应用程序编程接口)网关(gateway)可以将平台或系统等内部的数据或者程序通过restful(representationalstatetransfer，表述性状态传递)api的方式提供给第三方api租户，从而使api租户能够将不同api服务整合到自己的应用中，衍生出新的服务，有利于促进技术生态发展和跨界创新。

不同的api租户，对api资源和安全等的要求不同，由此衍生出了不同的apisla(service-levelagreement，服务等级协议策略)。api网关为了满足不同api租户的sla策略，需要使用不同方案对外提供api服务。目前api网关的租户有两种——物理租户和逻辑租户，相应地使用的多租户(多个物理租户或者多个逻辑租户)方案也不同。

物理多租户方案中，租户之间的api是物理隔离的，例如使用docker容器隔离、vm(virtualmachine，虚拟机)隔离或者物理机隔离。物理多租户方案的原理如图1所示。每个租户在api网关中对应一个或者多个api运行实例，这些api运行实例组成租户(例如租户a)独占的api集群，例如图1中a租户对应api集群1、b租户对应api集群2，以此类推。不同租户的api集群，对外提供的api运行实例url中携带租户id，利用租户id，来区分不同租户的api运行实例url，例如a租户的api运行实例url为：http://xxx.apigatewa/tenanta/order，b租户的api运行实例url为：http://xxx.apigatewa/tenantb/order，因为采用物理资源独占模式，所以每个租户都拥有自己私有的api运行实例url，这些url不会冲突。物理多租户方案中，每个租户的应用程序根据租户id向api网关请求资源后，api网关返回该租户的api运行实例url，所述应用程序直接访问返回的api运行实例url来获取资源，因此不需要进行多租户路由。

逻辑多租户方案中，所有租户共享一个或者多个api运行实例，每个api运行实例内部利用多线程、协程或者消息队列隔离的方式，实现不同租户之间的api隔离。逻辑多租户的原理如图2所示。各个租户共享一个或者多个api运行实例，api集群对外只提供一个运行实例url，例如提供给所有租户的api运行实例url均为：http://xxx.apigatewa/order？id＝1。因为所有的租户共享相同的api运行实例，故api运行实例之间是完全对等的。因此，在逻辑多租户方案中，租户的应用程序根据租户id向api网关请求api资源后，api网关只需要做随机或轮询分发，就能将api运行实例路由至租户的应用程序。

物理多租户方案存在资源占用多和维护成本高等问题，逻辑多租户方案则存在故障隔离性差等问题，为兼顾资源节约和提高故障隔离性，有必要提出混合多租户方案。混合多租户方案可以对重要的租户采用物理多租方案，对普通租户则采用逻辑多租方案。混合多租户场景中，有些api运行实例是被单个物理租户独占的，有些api运行实例是被多个逻辑租户共享的，如何正确地将api运行实例路由至租户的应用程序，是实现混合多租户方案需要解决的主要问题。

技术实现要素：

本申请提供了一种api混合多租户路由方法、系统和api网关，以实现api混合多租户路由。

第一方面，本申请提供了一种api混合多租户路由方法，所述方法包括：api网关接收api调用方发送的api请求消息，所述api请求消息携带有应用关键字appkey，所述appkey用于标识所述api调用方的身份；根据所述api请求消息得到所述appkey；根据所述appkey和多租户路由策略表，得到与所述appkey对应的api运行实例url列表，所述多租户路由策略表用于保存所述appkey和api运行实例url列表之间的映射关系，所述api运行实例url列表对应的api运行实例由所述api网关根据api租户的信息配置，所述api调用方隶属于所述api租户；根据预先配置的api负载均衡策略，从所述api运行实例url列表中确定与所述api请求消息对应的api运行实例url；将所述api运行实例url返回给所述api调用方。采用该实现方式，若api调用方隶属的租户为物理租户，则返回给api调用方的是该租户私有的api运行实例url，若api调用方隶属的租户为逻辑租户，则返回给api调用方的是分配给该租户的共享api运行实例url，这样api调用方只需发送携带有所述appkey的api请求消息，不需获取租户信息，就能够调用到正确的api运行实例，从而实现自适配的混合多租户路由。

结合第一方面，在第一方面第一种可能的实现方式中，所述api网关接收所述api调用方发送的api请求消息之前，还包括：根据所述api调用方的信息生成所述appkey，将所述appkey返回给所述api调用方；生成所述多租户路由策略表。api网关只需在api调用方第一次请求api运行实例资源前生成一次appkey，将appkey返回给api调用方有api调用方保存，api调用方每次请求api运行实例资源时向api网关发送携带有appkey的请求消息即可，不需获取租户信息。api网关预先生成保存appkey和api运行实例url列表之间的映射关系的多租户路由策略表，在收到api调用方发送的请求消息后，便可以直接根据请求消息中的appkey和多租户路由策略表来确定路由给api调用方的api运行实例url。

结合第一方面第一种可能的实现方式，在第一方面第二种可能的实现方式中，所述的方法，其特征在于，所述生成多租户路由策略表，包括：根据所述appkey得到所述api租户的租户id，生成所述appkey和所述租户id之间的第一映射表；根据所述租户id得到所述api运行实例url列表，生成所述租户id和所述api运行实例url列表之间的第二映射表；根据所述第一映射表以及所述第二映射表生成所述多租户路由策略表。由于appkey和api运行实例url列表之间没有直接映射关系，而appkey和租户id的直接映射关系容易获得，租户id和api运行实例url列表之间的直接映射关系也容易获得，因此先生成所述第一映射表和第二映射表并保存，有利于更方便地生成多租户路由策略表，也有利于在租户对应的api运行实例url列表发生变化时重新多租户路由策略表以完成多租路由策略表的更新。

结合第一方面第二种可能的实现方式，在第一方面第三种可能的实现方式中，所述根据所述appkey得到对应的租户id，包括：根据所述appkey从身份识别与访问管理模块iam得到对应的api调用方的信息；根据所述api调用方的信息确定所述api调用方隶属的api租户，得到所述api租户的租户id。appkey根据api调用方信息生成，若api调用方信息本身包含有租户id的相关标识信息，则可以直接得到appkey与租户id的对应关系，若api调用方信息本身只包含与租户id的对应关系或者隶属信息，则先根据api调用方的信息确定api调用方隶属的租户，再获取租户id，以便得到准确的appkey与租户id的对应关系。

第二方面，本申请提供了一种api混合多租户路由系统，所述系统包括多租户路由模块，所述多租户路由模块用于：接收api消费者发送的api请求消息，所述api请求消息携带有appkey，所述appkey用于标识所述api消费者的身份；根据所述api请求消息得到所述appkey；根据所述appkey和多租户路由策略表，得到与所述appkey对应的api运行实例url列表，所述多租户路由策略表用于保存所述appkey和所述api运行实例url列表之间的映射关系，所述api运行实例url列表对应的api运行实例由所述api网关根据api租户的信息开通，所述api消费者隶属于所述api租户；根据预先配置的api负载均衡策略，从所述api运行实例url列表中确定与所述api请求消息对应的api运行实例url；将所述api运行实例url返回给所述api消费者。

结合第二方面，在第二方面第一种可能的实现方式中，所述系统还包括租户模块，所述租户模块用于：根据所述api消费者的信息生成所述appkey，将所述appkey返回给所述api消费者；所述多租户路由模块还用于：生成所述多租户路由策略表。

结合第二方面第一种可能的实现方式，在第二方面第二种可能的实现方式中，所述系统还包括所述租户管理模块，所述租户管理模块用于：根据所述appkey得到所述api租户的租户id，生成所述appkey和所述租户id之间的第一映射表；根据所述租户id得到所述api运行实例url列表，生成所述租户id和所述api运行实例url列表之间的第二映射表；所述多租户路由模块，还用于根据所述第一映射表以及所述第二映射表生成所述多租户路由策略表。

结合第二方面第二种可能的实现方式，在第二方面第三种可能的实现方式中，所述租户管理模块，具体用于：根据所述appkey从身份识别与访问管理模块iam得到对应的api消费者的信息；根据所述api消费者的信息确定所述api消费者隶属的api租户，得到所述api租户的租户id。

第三方面，本申请实施例提供另一种api混合多租户路由系统，所述系统包括：接收模块，用于接收api调用方发送的api请求消息，所述api请求消息携带有appkey，所述appkey用于标识所述api调用方的身份；解析模块，用于根据所述api请求消息得到所述appkey；路由模块，用于：根据所述appkey和多租户路由策略表，得到与所述appkey对应的api运行实例url列表，所述多租户路由策略表用于保存所述appkey和所述api运行实例url列表之间的映射关系，所述api运行实例url列表对应的api运行实例由所述api网关根据api租户的信息配置，所述api调用方隶属于所述api租户；根据预先配置的api负载均衡策略，从所述api运行实例url列表中确定与所述api请求消息对应的api运行实例url；将所述api运行实例url返回给所述api调用方。

结合第三方面，在第三方面第一种可能的实现方式中，所述系统还包括：appkey生成模块，用于根据所述api调用方的信息生成所述appkey，将所述appkey返回给所述api调用方；多租户路由策略表生成模块，用于生成所述多租户路由策略表。

结合第三方面第一种可能的实现方式，在第三方面第二种可能的实现方式中，所述多租户路由策略表生成模块，具体用于：根据所述appkey得到所述api租户的租户id，生成所述appkey和所述租户id之间的第一映射表；根据所述租户id得到所述api运行实例url列表，生成所述租户id和所述api运行实例url列表之间的第二映射表；根据所述第一映射表以及所述第二映射表生成所述多租户路由策略表。

结合第三方面第二种可能的实现方式，在第三方面第三种可能的实现方式中，所述多租户路由策略表生成模块，具体用于：根据所述appkey从身份识别与访问管理模块iam得到对应的api调用方的信息；根据所述api调用方的信息确定所述api调用方隶属的api租户，得到所述api租户的租户id。

第四方面，本申请实施例还提供一种api网关，所述api网关包括存储器、接收器、发送器和处理器，所述接收器用于接收api调用方发送的api请求消息，所述api请求消息携带有appkey，所述appkey用于标识所述api调用方的身份；所述处理器通过执行存储于所述存储器的代码，用于：根据所述api请求消息得到所述appkey；根据所述appkey和多租户路由策略表，得到与所述appkey对应的api运行实例url列表，所述多租户路由策略表存储于所述存储器，用于保存所述appkey和api运行实例url列表之间的映射关系，所述api运行实例url列表对应的api运行实例由所述处理器根据api租户的信息配置，所述api调用方隶属于所述api租户；根据预先配置的api负载均衡策略，从所述api运行实例url列表中确定与所述api请求消息对应的api运行实例url；所述发送器用于将所述api运行实例url返回给所述api调用方。

结合第四方面，在第四方面第一种可能的实现方式中，所述处理器还用于：根据所述api调用方的信息生成所述appkey，将所述appkey返回给所述api调用方；生成所述多租户路由策略表并保存于所述存储器。

结合第四方面第一种可能的实现方式，在第四方面第二种可能的实现方式中，所述处理器具体用于：根据所述appkey得到对应的租户id，生成所述appkey和所述租户id之间的第一映射表，将所述第一映射表保存于所述存储器中；根据所述租户id得到所述api运行实例url列表，生成所述租户id和所述api运行实例url列表之间的第二映射表，将所述第二映射表保存于所述存储器中；根据所述第一映射表以及所述第二映射表生成所述多租户路由策略表。

结合第四方面第二种可能的实现方式，在第四方面第三种可能的实现方式中，所述所述处理器具体用于：根据所述appkey从身份识别与访问管理模块iam得到对应的api调用方的信息；根据所述api调用方的信息确定所述api调用方隶属的api租户，得到所述api租户的租户id。

第五方面，本申请实施例还提供一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行如第一方面所述的方法。

第六方面，本申请实施例还提供一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行如第一方面所述的方法。

本申请实施例所提供的api混合多租户路由技术方案，在接收到api调用方发送的api请求消息后，解析得到所述api请求消息中携带的应用关键字(appkey：applicationkey)；再根据多租户路由策略表，得到与appkey对应的api运行实例url列表；最后从所述api运行实例url列表中确定一个api运行实例url返回给api调用方，api调用方调用所述api运行实例url指向的具体api运行实例，由此完成api运行实例到api调用方的路由。其中，所述appkey用于标识所述api调用方的身份；所述多租户路由策略表用于保存appkey和api运行实例url列表之间的映射关系；api运行实例url对应的api运行实例由api网关根据租户的信息配置，所述api调用方隶属于所述租户。若api调用方隶属的租户为物理租户，则返回给api调用方的是该租户私有的api运行实例url，若api调用方隶属的租户为逻辑租户，则返回给api调用方的是分配给该租户的共享api运行实例url，这样api调用方只需发送携带有所述appkey的api请求消息，不需获取租户信息，就能够调用到正确的api运行实例，从而实现自适配的混合多租户路由。

附图说明

图1为现有技术中物理多租户方案的原理图；

图2为现有技术中逻辑多租户方案的原理图；

图3为本申请实施例提供的一种混合多租户路由系统的框图；

图4为本申请实施例提供的另一种混合多租户路由系统的框图；

图5为本申请实施例提供的一种混合多租户路由方法的流程示意图；

图6为本申请实施例提供的一种api网关的结构示意图。

具体实施方式

根据本申请实施例提供的混合多租户路由方案，租户通过api网关购买api的时候确定租户种类(物理租户或者逻辑租户)，然后签署sla协议完成api购买，购买成功后api网关为租户创建账户，生成租户id，并将租户id、该租户id对应的租户种类和隶属于该租户的api调用方的信息等租户信息保存于iam(identityandaccessmanagement，身份识别与访问管理)中，其中，租户id与租户种类对应，根据租户id可以确定租户种类，租户id也与api调用方信息对应。在一种实施方式中，可以在租户id中设置特定的符号来标识租户种类，这样api网关可以根据租户id直接确定租户种类；在另一种实施方式中，将租户种类作为与租户id对应的租户属性，api网关可以根据租户id获取到租户种类，由此完成租户种类确定。其中iam可以为api网关的一部分，也可以为独立装置，独立于api网关。api调用方隶属于租户，为租户的api运行实例的使用者,api调用方可以具体为需要调用api运行实例的客户端或者应用程序等。api运行实例则由api网关根据租户的信息配置，若租户种类为物理租户，则所述配置具体为部署一套新的仅由租户私有的api运行实例，若租户种类为逻辑租户，则所述配置具体为分配一套已有的共享api运行实例。每个api运行实例有一个api运行实例url，api运行实例配置完毕后，api网关会相应地生成api运行实例url列表来保存配置的api运行实例的url，且所述api运行实例url列表和租户的租户id对应，所述api运行实例url列表可以保存于iam或者其他存储模块中。

本申请实施例提供的技术方案中，api调用方需要调用api运行实例时，向api网关发送请求消息，以向api网关请求api运行实例资源，该请求消息中携带有appkey，该appkey用于标识所述api调用方的身份，appkey可以保存在应用程序中。api网关接收api调用方发送的请求消息，解析所述请求消息得到appkey，根据appkey确定所述api调用方隶属的租户的租户id，将与所述租户id对应的api运行实例url返回给api调用方，以供所述api调用方调用。

具体的，本申请实施例提供一种混合多租户路由系统，所述系统应用于api网关。参见图3，为本申请实施例提供的一种混合多租户路由系统的实现方式，所述系统可以包括租户模块、租户管理模块和多租户路由模块。图3中，箭头表示数据流向，本申请实施例所提供的api混合多租户路由系统也可以包含如图3中所示的数据库、内存和iam。

其中，租户模块可以用于：

1)生成appkey。api调用方在第一次向api网关请求api运行实例之前，将自身的api调用方信息发送给api网关，或者由管理api调用方的技术人员将api调用方信息通过用户界面输入api网关，具体的，由租户模块接收api调用方发送过来的或者技术人员输入的api调用方信息，根据api调用方信息生成appkey，将appkey保存于iam中，并返回给api调用方，appkey用于标识api调用方的身份。api调用方接收到appkey后将appkey保存于本地。

api调用方可以每次向api网关请求api运行实例前，将api调用方信息传输给api网关，由租户模块生成appkey，但这样重复冗余的步骤浪费资源，因此api调用方只需在第一次向api网关请求api运行实例之前向api网关传输api调用方信息，租户模块只需生成一次appkey即可。api调用方在接收到租户模块返回的appkey后不需再向api网关传输api调用方信息，每次皆根据此appkey向api网关发送请求消息即可。

2)生成appkey后，还可以根据appkey生成api授权凭证(api授权token)，将api授权凭证返回给api调用方，api调用方接收到api授权凭证后将api授权凭证保存于本地。

其中，所述租户管理模块可以具体用于：

1)生成appkey和租户id之间的映射表：可以根据appkey在iam中查询得到appkey对应的api调用方信息，再根据api调用方信息和租户信息之间的隶属关系，查询到api调用方所隶属的租户的信息，获取到租户id，生成appkey和租户id之间的映射表，appkey和租户id之间的映射表可以持久化保存于存储模块例如数据库中。

2)生成租户id和api运行实例之间的映射表：根据得到的租户id，在iam或其他存储模块中查询得到对应的api运行实例url列表，生成租户id和api运行实例url列表之间的映射表。租户管理模块可以将租户id和api运行实例url列表之间的映射表持久化保存于存储模块(例如数据库)中。

3)将生成的appkey和租户id之间的映射表(为方便描述，称为第一映射表)以及生成的租户id和api运行实例列表之间的映射表(为方便描述，称为第二映射表)传输给多租户路由模块。多租户路由模块可以在缓存中保存上述映射表。

所述多租户路由模块可以为一个多租户路由引擎，具体用于：

1)接收租户管理模块传输的appkey和租户id之间的映射表、以及租户id和api运行实例url列表之间的映射表。生成多租户路由策略表：根据第一映射表以及第二映射表生成多租户路由策略表，所述多租户路由策略表为appkey和api运行实例url列表之间的映射表。多租户路由策略表可以为哈希表等数据表格式，多租户路由模块可以将多租户路由策略表缓存在内存中。

2)多租户路由：api调用方需要调用api运行实例时，向api网关(具体为向api网关中的多租户路由模块)发送api请求消息，所述api请求消息中携带有所述appkey，具体地，api调用方可以在api请求消息头(例如httpheader)中携带appkey。多租户路由模块接收到所述api请求消息后，解析所述api请求消息，获取appkey；再根据多租户路由策略表以及获取到的appkey，查询得到该appkey对应的api运行实例url列表；然后根据预先设定的api负载均衡策略(随机选择、按权重选择或者轮询等)，从api运行实例url列表中确定一个api运行实例url；最后将确定的api运行实例url返回给api调用方，api调用方调用所述api运行实例url指向的api运行实例，由此完成api运行实例到api调用方的路由，实现自适配的混合多租户路由。

在另一种实施方式中，api调用方还在所述api请求消息中携带api授权凭证，所述多租户路由模块接收到所述api请求消息后，解析所述api请求消息得到appkey和api授权凭证，校验所述api授权凭证的合法性，若api授权凭证合法，则根据多租户路由策略表以及获取到的appkey，查询得到该appkey对应的api运行实例url列表，若api授权凭证不合法，则向所述api调用方返回请求失败消息。基于本申请实施例提供的api混合多租户路由系统，api调用方在需要调用api运行实例时不需获取租户信息，只需向api网关发送携带有appkey的请求消息，由api网关根据所述appkey将对应的api运行实例url返回给api调用方，若api调用方隶属于物理租户，则接收到的是该物理租户私有的api运行实例url，若api调用方隶属于逻辑租户，则接收到的是分配该逻辑租户的共享api运行实例url。api消费可调用所述api运行实例url指向的api运行实例，从而在api调用方对租户无感知的情况下实现混合多租户的自适配路由。

需要说明的是，所述混合多租户路由系统的实现方式并不仅限于图3所示的方式，可以依据各功能模块实现的功能，对所述系统进行其他方式的划分。参见图4，为本申请实施例提供的一种api混合多租户路由系统的另一种实现方式，所述系统包括：

appkey生成模块u401，用于接收api调用方传输过来的或者技术人员输入的api调用方信息，根据所述api调用方信息生成appkey，将所述appkey保存于iam中，并返回给api调用方，所述appkey用于唯一标识所述api调用方的身份。

多租户路由策略表生成模块u402，用于生成多租户路由策略表，并将所述多租户路由策略表保存于缓存或数据库中，所述多租户路由策略表用于保存所述appkey和api运行实例url列表之间的映射关系；

接收模块u403，用于接收所述api调用方发送的api请求消息，所述api请求消息携带有所述appkey；

解析模块u404，用于解析所述api请求消息，得到所述appkey，；

路由模块u405，用于根据所述appkey和所述多租户路由策略表生成模块生成的多租户路由策略表，得到与所述appkey对应的api运行实例url列表；以及，根据预先配置的api负载均衡策略，从所述api运行实例url列表中确定与所述api请求消息对应的api运行实例url，将所述api运行实例url返回至所述api调用方。

其中，所述多租户路由策略表生成模块具体可以用于：根据所述appkey从iam查询得到对应的租户id，生成所述appkey和所述租户id之间的第一映射表；根据所述租户id从iam或其他存储模块查询得到api运行实例url列表，生成所述租户id和所述api运行实例url列表之间的第二映射表；根据所述第一映射表以及所述第二映射表生成所述多租户路由策略表，所述第一映射表和第二映射表可以持久化保存于数据库中。

所述多租户路由策略表生成模块，在所述根据所述appkey得到对应的租户id时，具体可以用于：根据所述appkey从iam得到对应的api调用方的信息；根据所述api调用方的信息从iam确定所述api调用方隶属的租户，获取所述租户的租户id。

其中，所述appkey生成模块，还可以用于：根据appkey生成api授权凭证，并将所述api授权凭证返回给api调用方。相应地，所述接收模块用于接收所述api调用方发送的api请求消息，所述api请求消息携带有所述appkey和所述api授权凭证；所述解析模块用于解析所述api请求消息，得到所述appkey和所述api授权凭证；所述路由模块u406，还用于校验所述appkey的合法性，若所述appkey合法，则用于根据所述appkey和所述多租户路由策略表，确定返回给api调用方的api运行实例url，并将所述api运行实例url返回给所述api调用方。

其中，所述路由模块在确定与所述api请求消息对应的api运行实例url后，将api运行实例url返回给api调用方，所述api调用方调用所述api运行实例url指向的api运行实例。若api调用方隶属于物理租户，则所述api混合多租户路由系统向所述api调用方返回该物理租户私有的api运行实例url，若api调用方隶属于逻辑租户，则所述api混合多租户路由系统向所述api调用方返回该逻辑租户的共享api运行实例url，这样，本申请实施例所提供的api混合多租户路由系统可以自适配地将正确的api运行实例url路由至api调用方，而不需api调用方获取租户信息。

本申请实施例提供的api混合多租户路由系统可以用于实施本申请实施例提供的api混合多租户路由方法。参见图5，为本申请实施例所提供的一种api混合多租户路由方法，所述方法应用于api网关，所述方法包括：

步骤s501,api网关根据api调用方的信息生成appkey，将所述appkey返回给所述api调用方，所述appkey用于标识所述api调用方的身份；

步骤s502，根据所述appkey生成多租户路由策略表，所述多租户路由策略表用于保存所述appkey和api运行实例url列表之间的映射关系，所述api运行实例url列表对应的api运行实例由所述api网关根据api租户的信息配置，所述api调用方隶属于所述api租户；

步骤s503，接收所述api调用方发送的api请求消息，所述api请求消息携带有所述appkey；

步骤s504，根据所述api请求消息得到所述appkey；

步骤s505，根据所述appkey和所述多租户路由策略表，得到与所述appkey对应的api运行实例url列表；

步骤s506，根据预先配置的api负载均衡策略，从所述api运行实例url列表中确定与所述api请求消息对应的api运行实例url；

步骤s507，将所述api运行实例url返回给所述api调用方。

其中，所述生成多租户路由策略表，具体可以包括：根据所述appkey得到对应的租户id，生成所述appkey和所述租户id之间的第一映射表；根据所述租户id得到api运行实例url列表，生成所述租户id和所述api运行实例url列表之间的第二映射表；根据所述第一映射表以及所述第二映射表生成所述多租户路由策略表。

具体地，所述根据所述appkey得到对应的租户id，可以包括：根据所述appkey从iam得到对应的api调用方的信息；根据所述api调用方的信息确定所述api调用方隶属的租户，得到与所述租户对应的租户id。

本申请实施例所提供的api混合多租户路由方法中，api网关在确定与api请求消息对应的api运行实例url后，将所述api运行实例url返回至api调用方，完成api混合多租户路由。其中api运行实例由api网关根据租户的信息配置，若api调用方隶属的租户为物理租户，则返回给api调用方的是该物理租户私有的api运行实例url，若api调用方隶属的租户为逻辑租户，则返回给api调用方的是分配给该逻辑租户的共享api运行实例url。这样api调用方不需获取租户信息，只需向api网关发送携带有appkey的api请求消息，就能够调用到正确的api运行实例，从而实现自适配的混合多租户路由。

参见图6，为本申请实施例的一种api网关。本申请实施例所提供的api混合多租户路由系统为api网关中的功能模块。所述api网关包括存储器、接收器、发送器和处理器：

所述接收器用于接收api调用方发送的api请求消息，所述api请求消息携带有appkey，所述appkey用于标识所述api调用方的身份；

所述处理器通过执行存储于所述存储器的代码，用于：解析所述api请求消息，得到所述appkey；根据所述appkey和多租户路由策略表，得到与所述appkey对应的api运行实例url列表，所述多租户路由策略表存储于所述存储器，用于保存所述appkey和所述api运行实例url列表之间的映射关系；以及，根据预先配置的api负载均衡策略，从所述api运行实例url列表中确定与所述api请求消息对应的api运行实例url；

所述发生器用于向所述api调用方发送所述api运行实例url。

所述处理器还用于：接收api调用方传输过来的或者技术人员输入的api调用方信息，根据所述api调用方信息生成appkey，将所述appkey保存于所述存储器中，所述appkey用于唯一标识所述api调用方的身份。所述发送器还用于将所述appkey发送给api调用方。。

所述处理器还用于生成所述多租户路由策略表并将所述多租户路由策略表保存于所述存储器。具体地，所述处理器可以用于：根据所述appkey从iam查询得到对应的租户id，生成所述appkey和所述租户id之间的第一映射表，将所述第一映射表保存于所述存储器中；根据所述租户id从iam得到api运行实例url列表，生成所述租户id和所述api运行实例url列表之间的第二映射表，，将所述第二映射表保存于所述存储器中；根据所述第一映射表以及所述第二映射表生成所述多租户路由策略表，所述多租户路由策略表可以保存于所述存储器中。

其中，所述处理器具体用于：根据所述appkey从iam得到对应的api调用方的信息；根据所述api调用方的信息确定所述api调用方隶属的租户，获取所述租户的租户id。

其中，所述处理器还可以用于：根据所述appkey生成api授权凭证；所述发送器还用于将所述api授权凭证发送至所述api调用方。所述接收器用于api调用方发送的api请求消息，所述api请求消息携带有所述appkey和所述api授权凭证。所述处理器还用于校验所述appkey的合法性；若所述appkey合法，则根据所述appkey确定返回给所述api调用方的api运行实例url。所述发送器用于将所述api运行实例url发送给所述api调用方。

现有技术中，所述api调用方需获取租户信息，将租户id和租户种类发送给api网关来得到对应的api运行实例，这对api调用方的运行来讲是很不方便的，若获取租户信息错误，便不能调用到正确的api运行实例。本申请实施例所提供的api混合多租户路由技术方案，根据api调用方的信息为所述api调用方生成特定的appkey，appkey标识所述api调用方的身份。所述api调用方只需向api网关发送携带有appkey的api请求消息，api网关会根据api请求消息中的appkey确定正确的api运行实例url返回给所述api调用方，供所述api调用方调用api运行实例url指向的api运行实例，若api调用方隶属于物理租户，则向所述api调用方返回该物理租户私有的api运行实例url，若api调用方隶属于逻辑租户，则向所述api调用方返回该逻辑租户的共享api运行实例url。其中，appkey、api调用方的信息、api调用方隶属的租户的信息(包括租户id)可以保存于iam中。由此本申请实施例所提供的api混合多租户路由技术方案可以在客api调用方不需获取租户信息的情况下，实现api运行实例的自适配路由，从而提高api调用方运行的便利性和成功率。

本申请实施例还提供一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行本申请实施例所提供的api混合多租户路由系统的功能。

本申请实施例还提供一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行本申请实施例所提供的api混合多租户路由系统的功能。

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

本说明书中各个实施例之间相同相似的部分互相参见即可。尤其，对于方法和设备实施例而言，由于其基本相似于装置实施例，所以描述得较简单，相关之处参见装置实施例中的说明即可。