WO2019062340A1 - 一种api混合多租户路由方法、系统和api网关 - Google Patents

一种api混合多租户路由方法、系统和api网关 Download PDF

Info

Publication number
WO2019062340A1
WO2019062340A1 PCT/CN2018/099362 CN2018099362W WO2019062340A1 WO 2019062340 A1 WO2019062340 A1 WO 2019062340A1 CN 2018099362 W CN2018099362 W CN 2018099362W WO 2019062340 A1 WO2019062340 A1 WO 2019062340A1
Authority
WO
WIPO (PCT)
Prior art keywords
api
tenant
appkey
caller
running instance
Prior art date
Application number
PCT/CN2018/099362
Other languages
English (en)
French (fr)
Inventor
李林锋
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP18863352.3A priority Critical patent/EP3678358B1/en
Publication of WO2019062340A1 publication Critical patent/WO2019062340A1/zh
Priority to US16/831,314 priority patent/US11272036B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/0012—Details of application programming interfaces [API] for telephone networks; Arrangements which combine a telephonic communication equipment and a computer, i.e. computer telephony integration [CPI] arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5019—Ensuring fulfilment of SLA
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H04L45/306—Route determination based on the nature of the carried application
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H04L45/308—Route determination based on user's profile, e.g. premium users
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5019—Ensuring fulfilment of SLA
    • H04L41/5022—Ensuring fulfilment of SLA by giving priorities, e.g. assigning classes of service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/508—Network service management, e.g. ensuring proper service fulfilment according to agreements based on type of value added network service under agreement
    • H04L41/5096—Network service management, e.g. ensuring proper service fulfilment according to agreements based on type of value added network service under agreement wherein the managed service relates to distributed or central networked applications

Definitions

  • the present application relates to the field of software technologies, and in particular, to an API hybrid multi-tenant routing method, system, and API gateway.
  • the API gateway can pass internal data or programs such as platforms or systems to Restful (Representational State Transfer,
  • Restful Representational State Transfer
  • the expressive state delivery API provides the third-party API tenant so that the API tenant can integrate different API services into their own applications and derive new services, which will promote the ecological development of technology and cross-border innovation.
  • API SLAs Service Level Agreements
  • the API gateway needs to provide API services to different external solutions.
  • there are two types of tenants in the API gateway - physical tenants and logical tenants, and the corresponding multi-tenancy (multiple physical tenants or multiple logical tenants) schemes are also different.
  • the APIs between tenants are physically isolated, such as using Docker container isolation, VM (Virtual Machine) isolation, or physical machine isolation.
  • the principle of the physical multi-tenancy scheme is shown in Figure 1.
  • Each tenant runs an instance in the API gateway corresponding to one or more APIs.
  • These API running instances form an exclusive API cluster of the tenant (for example, tenant A).
  • tenant A For example, the ten tenant corresponding API cluster 1 and the B tenant corresponding API cluster 2 in FIG. And so on.
  • the APIs of different tenants are configured to carry the tenant IDs in the API running instance URLs. The tenant IDs are used to distinguish the API running instance URLs of different tenants.
  • the API running instance URL of the A tenant is: http://xxx.apigatewa/ TenantA/order
  • B tenant's API running instance URL is: http://xxx.apigatewa/tenantB/order
  • the API gateway returns the API running instance URL of the tenant, and the application directly accesses the returned API running instance URL to obtain the resource, so No multi-tenant routing is required.
  • each API running instance shares one or more API running instances.
  • the API cluster provides only one running instance URL.
  • the physical multi-tenant scheme has problems such as high resource occupation and high maintenance cost.
  • the logical multi-tenant scheme has problems such as poor fault isolation.
  • the hybrid multi-tenancy scheme can adopt a physical multi-tenancy scheme for important tenants and a logical multi-tenancy scheme for ordinary tenants.
  • some API running instances are monopolized by a single physical tenant.
  • Some API running instances are shared by multiple logical tenants. How to correctly route API running instances to tenant applications is to implement mixed multi-tenancy. The main problem that the solution needs to solve.
  • the application provides an API hybrid multi-tenant routing method, system and API gateway to implement API hybrid multi-tenant routing.
  • the present application provides an API hybrid multi-tenant routing method, where the method includes: an API gateway receives an API request message sent by an API caller, where the API request message carries an application keyword APPkey, and the APPkey uses Identifying the identity of the API caller; obtaining the APPkey according to the API request message; obtaining, according to the APPkey and the multi-tenant routing policy table, an API running instance URL list corresponding to the APPkey, the multi-tenant route
  • the policy table is configured to save a mapping relationship between the APPkey and the API running instance URL list, where the API running instance corresponding to the API running instance URL list is configured by the API gateway according to the information of the API tenant, and the API caller belongs to Determining, by the API tenant, an API running instance URL corresponding to the API request message from the API running instance URL list according to a pre-configured API load balancing policy; returning the API running instance URL to the API Caller.
  • the API running instance URL of the tenant is returned to the API caller, and if the tenant to which the API caller belongs is a logical tenant, the API caller is returned.
  • the shared API running instance URL assigned to the tenant so that the API caller only needs to send the API request message carrying the APPkey, and can obtain the correct API running instance without acquiring the tenant information, thereby implementing self-adaptation. Mixed multi-tenant routing.
  • the method before the API gateway receives the API request message sent by the API caller, the method further includes: generating the APPkey according to the information of the API caller Returning the APPkey to the API caller; generating the multi-tenant routing policy table.
  • the API gateway only needs to generate an APPkey before the API caller requests the API to run the instance resource for the first time, and returns the APPkey to the API caller.
  • the API caller saves the API caller, and the API caller sends the carry to the API gateway every time the API is run. There is an APPkey request message, and no need to obtain tenant information.
  • the API gateway pre-generates a multi-tenant routing policy table that saves the mapping relationship between the APPkey and the API running instance URL list. After receiving the request message sent by the API caller, the API gateway can directly directly apply the APPkey and the multi-tenant routing policy according to the request message. The table determines the URL of the API running instance that is routed to the API caller.
  • the method is characterized in that the generating a multi-tenant routing policy table includes: obtaining, according to the APPkey Generating, by the tenant ID of the API tenant, a first mapping table between the APPkey and the tenant ID; obtaining the API running instance URL list according to the tenant ID, generating the tenant ID and the API running instance a second mapping table between the URL lists; generating the multi-tenant routing policy table according to the first mapping table and the second mapping table.
  • the first mapping table and the second mapping table are saved, which is convenient for generating a multi-tenant routing policy table, and is also beneficial for re-multi-tenancy routing policy table to complete multi-tenancy routing when the tenant corresponding API running instance URL list changes. Update of the policy table.
  • the obtaining, by the APPkey, the corresponding tenant ID includes: following the APPkey from the identity recognition and access management module
  • the IAM obtains the information of the corresponding API caller; determines the API tenant to which the API caller belongs according to the information of the API caller, and obtains the tenant ID of the API tenant.
  • APPkey is generated according to the API caller information. If the API caller information itself contains the relevant identifier information of the tenant ID, the corresponding relationship between the APPkey and the tenant ID can be directly obtained.
  • the tenant to which the API caller belongs is determined according to the information of the API caller, and then the tenant ID is obtained, so as to obtain an accurate correspondence between the APPkey and the tenant ID.
  • the present application provides an API hybrid multi-tenant routing system, where the system includes a multi-tenant routing module, and the multi-tenant routing module is configured to: receive an API request message sent by an API consumer, and the API request message Carrying an APPkey, the APPkey is used to identify the identity of the API consumer; the APPkey is obtained according to the API request message; and an API running instance corresponding to the APPkey is obtained according to the APPkey and the multi-tenant routing policy table.
  • a URL list where the multi-tenant routing policy table is used to save a mapping relationship between the APPkey and the API running instance URL list, where an API running instance corresponding to the API running instance URL list is used by the API gateway according to an API tenant.
  • the information is opened, the API consumer belongs to the API tenant; and the API running instance URL corresponding to the API request message is determined from the API running instance URL list according to a pre-configured API load balancing policy; The API runtime instance URL is returned to the API consumer.
  • the system further includes a tenant module, where the tenant module is configured to: generate the APPkey according to the information of the API consumer, and use the APPkey Returning to the API consumer; the multi-tenant routing module is further configured to: generate the multi-tenant routing policy table.
  • the system further includes the tenant management module, where the tenant management module is configured to: obtain, according to the APPkey a tenant ID of the API tenant, generating a first mapping table between the APPkey and the tenant ID; obtaining the API running instance URL list according to the tenant ID, generating the tenant ID and the API running instance URL a second mapping table between the lists; the multi-tenant routing module is further configured to generate the multi-tenant routing policy table according to the first mapping table and the second mapping table.
  • the tenant management module is specifically configured to: obtain, according to the APPkey, an identity recognition and access management module IAM. Information of the API consumer; determining an API tenant to which the API consumer belongs according to the information of the API consumer, and obtaining a tenant ID of the API tenant.
  • the embodiment of the present application provides another API hybrid multi-tenant routing system, where the system includes: a receiving module, configured to receive an API request message sent by an API caller, where the API request message carries an APPkey, The APPkey is used to identify the identity of the API caller; the parsing module is configured to obtain the APPkey according to the API request message; and the routing module is configured to: obtain the APPkey according to the APPkey and the multi-tenant routing policy table.
  • the multi-tenant routing policy table is used to save a mapping relationship between the APPkey and the API running instance URL list, and the API running instance URL list corresponding to the API running instance is
  • the API gateway is configured according to the information of the API tenant, and the API caller belongs to the API tenant; and the API running corresponding to the API request message is determined from the API running instance URL list according to the pre-configured API load balancing policy.
  • An instance URL returning the API runtime instance URL to the API caller.
  • the system further includes: an APPkey generating module, configured to generate the APPkey according to the information of the API caller, and return the APPkey to the The API caller; the multi-tenant routing policy table generating module is configured to generate the multi-tenant routing policy table.
  • the multi-tenant routing policy table generating module is specifically configured to: obtain the tenant of the API tenant according to the APPkey ID, generating a first mapping table between the APPkey and the tenant ID; obtaining the API running instance URL list according to the tenant ID, and generating a first between the tenant ID and the API running instance URL list a second mapping table; generating the multi-tenant routing policy table according to the first mapping table and the second mapping table.
  • the multi-tenant routing policy table generating module is specifically configured to: according to the APPkey from the identity recognition and access management module The IAM obtains the information of the corresponding API caller; determines the API tenant to which the API caller belongs according to the information of the API caller, and obtains the tenant ID of the API tenant.
  • an embodiment of the present application further provides an API gateway, where the API gateway includes a memory, a receiver, a transmitter, and a processor, where the receiver is configured to receive an API request message sent by an API caller, where the API request
  • the message carries an APPkey, where the APPkey is used to identify the identity of the API caller;
  • the processor by executing code stored in the memory, is configured to: obtain the APPkey according to the API request message;
  • the APPkey and the multi-tenant routing policy table obtains an API running instance URL list corresponding to the APPkey, where the multi-tenant routing policy table is stored in the memory, and is used to save a mapping between the APPkey and the API running instance URL list.
  • the API running instance corresponding to the API running instance URL list is configured by the processor according to information of an API tenant, the API caller belongs to the API tenant; according to a pre-configured API load balancing policy, from the Determining, by the API running instance URL list, an API running instance URL corresponding to the API request message; the sender is configured to return the API running instance URL to the A PI caller.
  • the processor is further configured to: generate the APPkey according to the information of the API caller, and return the APPkey to the API caller Generating the multi-tenant routing policy table and saving in the memory.
  • the processor is specifically configured to: obtain the corresponding tenant ID according to the APPkey, generate the APPkey, and a first mapping table between tenant IDs, storing the first mapping table in the memory; obtaining the API running instance URL list according to the tenant ID, generating the tenant ID and the API running instance URL a second mapping table between the lists, the second mapping table is saved in the memory; and the multi-tenant routing policy table is generated according to the first mapping table and the second mapping table.
  • the processor is specifically configured to: obtain, according to the APPkey, an identity recognition and access management module IAM The information of the API caller; determining, according to the information of the API caller, the API tenant to which the API caller belongs, and obtaining the tenant ID of the API tenant.
  • the embodiment of the present application further provides a computer readable storage medium, comprising instructions, when executed on a computer, causing the computer to perform the method as described in the first aspect.
  • the embodiment of the present application further provides a computer program product comprising instructions, when executed on a computer, causing the computer to perform the method as described in the first aspect.
  • the API hybrid multi-tenant routing technical solution provided by the embodiment of the present application, after receiving the API request message sent by the API caller, parses the application key (APPkey: Application Key) carried in the API request message;
  • the multi-tenant routing policy table obtains an API running instance URL list corresponding to APPkey; finally, an API running instance URL is determined from the API running instance URL list and returned to the API caller, and the API caller invokes the API running instance URL to point to The concrete API runs an instance, thereby completing the routing of the API running instance to the API caller.
  • the APPkey is used to identify the identity of the API caller; the multi-tenant routing policy table is used to save the mapping relationship between the APPkey and the API running instance URL list; the API running instance URL corresponding to the API running instance is configured by the API.
  • the gateway is configured according to the information of the tenant, and the API caller belongs to the tenant. If the tenant to which the API caller belongs is a physical tenant, the API running instance URL of the tenant is returned to the API caller. If the tenant to which the API caller belongs is a logical tenant, the return to the API caller is assigned to the API caller.
  • the tenant's shared API runs the instance URL, so that the API caller only needs to send the API request message carrying the APPkey, and can obtain the correct API running instance without acquiring the tenant information, thereby implementing self-adapting mixed multi-tenancy. routing.
  • FIG. 1 is a schematic diagram of a physical multi-tenancy scheme in the prior art
  • FIG. 2 is a schematic diagram of a logical multi-tenancy scheme in the prior art
  • FIG. 3 is a block diagram of a hybrid multi-tenant routing system according to an embodiment of the present application.
  • FIG. 4 is a block diagram of another hybrid multi-tenant routing system according to an embodiment of the present application.
  • FIG. 5 is a schematic flowchart of a hybrid multi-tenant routing method according to an embodiment of the present disclosure
  • FIG. 6 is a schematic structural diagram of an API gateway according to an embodiment of the present application.
  • the tenant type (physical tenant or logical tenant) is determined, and then the SLA protocol is signed to complete the API purchase.
  • the API gateway creates an account for the tenant.
  • the tenant ID is generated, and tenant information such as the tenant ID, the tenant category corresponding to the tenant ID, and the information of the API caller belonging to the tenant is stored in IAM (Identity and Access Management), where the tenant The ID corresponds to the tenant type, and the tenant type can be determined according to the tenant ID, and the tenant ID also corresponds to the API caller information.
  • IAM Identity and Access Management
  • a specific symbol may be set in the tenant ID to identify the tenant category, so that the API gateway may directly determine the tenant category according to the tenant ID; in another embodiment, the tenant category is used as the tenant ID.
  • the tenant attribute the API gateway can obtain the tenant type according to the tenant ID, thereby completing the tenant type determination.
  • the IAM can be part of the API gateway, or it can be a standalone device, independent of the API gateway.
  • the API caller belongs to the tenant and runs the instance user for the tenant's API.
  • the API caller can be specifically a client or an application that needs to call the API to run the instance.
  • the API running instance is configured by the API gateway according to the tenant information.
  • the configuration is specifically to deploy a new set of API running examples only by the tenant privately. If the tenant type is a logical tenant, the The configuration is specifically to allocate a set of existing shared API running instances. Each API running instance has an API running instance URL. After the API running instance is configured, the API gateway generates a URL running instance URL list to save the configured API running instance URL, and the API runs the instance URL list and the tenant.
  • the tenant ID corresponds to the list of API running instance URLs that can be saved in the IAM or other storage module.
  • the request message is sent to the API gateway to request the API to run the instance resource to the API gateway, where the request message carries the APPkey, and the APPkey is used to identify The identity of the API caller, APPkey can be saved in the application.
  • the API gateway receives the request message sent by the API caller, parses the request message to obtain the APPkey, determines the tenant ID of the tenant to which the API caller belongs according to the APPkey, and returns the API running instance URL corresponding to the tenant ID to the API call. Party for the API caller to call.
  • an implementation manner of a hybrid multi-tenant routing system provided by an embodiment of the present disclosure may include a tenant module, a tenant management module, and a multi-tenant routing module.
  • the arrow indicates the data flow direction.
  • the API hybrid multi-tenant routing system provided by the embodiment of the present application may also include the database, the memory, and the IAM as shown in FIG. 3.
  • the tenant module can be used to:
  • the API caller sends its API caller information to the API gateway before requesting the API running instance to the API gateway for the first time, or the API caller's technical personnel input the API caller information into the API gateway through the user interface.
  • the tenant module receives the API caller information sent by the API caller or input by the technician, generates an APPkey according to the API caller information, saves the APPkey in the IAM, and returns it to the API caller, and the APPkey is used to identify the API call. The identity of the party.
  • the API caller saves the APPkey locally after receiving the APPkey.
  • the API caller can transmit the API caller information to the API gateway before the API gateway requests the API to run the instance, and the tenant module generates the APPkey, but the redundant steps are wasteful resources, so the API caller only needs to be in the first
  • the secondary API gateway requests the API to run the instance before transmitting the API caller information to the API gateway, and the tenant module only needs to generate the APPkey once.
  • the API caller After receiving the APPkey returned by the tenant module, the API caller does not need to transmit the API caller information to the API gateway, and each time the APPkey sends a request message to the API gateway according to the APPkey.
  • API authorization credential (API authorization token) may be generated according to the APPkey, and the API authorization credential is returned to the API caller, and the API caller saves the API authorization credential locally after receiving the API authorization credential.
  • the tenant management module may be specifically configured to:
  • mapping table between the tenant ID and the running instance of the API: according to the obtained tenant ID, query the IAM or other storage module to obtain a corresponding API running instance URL list, and generate a list between the tenant ID and the API running instance URL list. Mapping table.
  • the tenant management module can persist the mapping table between the tenant ID and the API running instance URL list in a storage module (for example, a database).
  • mapping table between the generated APPkey and the tenant ID (referred to as a first mapping table for convenience of description) and a mapping table between the generated tenant ID and the API running instance list (referred to as a second for convenience of description)
  • the mapping table is transmitted to the multi-tenant routing module.
  • the multi-tenant routing module can save the above mapping table in the cache.
  • the multi-tenant routing module can be a multi-tenant routing engine, specifically for:
  • Generating a multi-tenant routing policy table generating a multi-tenant routing policy table according to the first mapping table and the second mapping table, where the multi-tenant routing policy table is a mapping table between the APPkey and the API running instance URL list.
  • the multi-tenant routing policy table can be in the form of a data table such as a hash table, and the multi-tenant routing module can cache the multi-tenant routing policy table in the memory.
  • the API caller needs to send an API request message to the API gateway (specifically, to the multi-tenant routing module in the API gateway), and the API request message carries the APPkey.
  • the API caller can carry the APPkey in the API request header (for example, Http Header).
  • the multi-tenant routing module parses the API request message to obtain an APPkey; and then, according to the multi-tenant routing policy table and the obtained APPkey, queries the API running instance URL list corresponding to the APPkey; Pre-set API load balancing policy (random selection, weight selection, polling, etc.), determine an API running instance URL from the API running instance URL list; finally return the determined API running instance URL to the API caller, API The caller invokes the API running instance pointed to by the API running instance URL, thereby completing the route of the API running instance to the API caller, and implementing self-adapting hybrid multi-tenant routing.
  • Pre-set API load balancing policy random selection, weight selection, polling, etc.
  • the API caller further carries an API authorization credential in the API request message, and after receiving the API request message, the multi-tenant routing module parses the API request message to obtain APPkey and API authorization.
  • the voucher is used to verify the validity of the API authorization voucher. If the API authorization voucher is legal, according to the multi-tenant routing policy table and the obtained APPkey, the API running instance URL list corresponding to the APPkey is obtained, and if the API authorization voucher is invalid. And return a request failure message to the API caller.
  • the API caller does not need to obtain the tenant information when calling the API running instance, and only needs to send the request message carrying the APPkey to the API gateway, and the API gateway according to the APPkey Returning the corresponding API running instance URL to the API caller. If the API caller belongs to the physical tenant, the API running instance URL of the physical tenant is received. If the API caller belongs to the logical tenant, the received API is received. Is the shared API running instance URL assigned to this logical tenant. The API consumption may invoke an API running instance pointed to by the API running instance URL to implement self-adaptive routing of the hybrid multi-tenant without the API caller being aware of the tenant.
  • implementation manner of the hybrid multi-tenant routing system is not limited to the manner shown in FIG. 3, and the system may be divided into other manners according to functions implemented by each functional module.
  • FIG. 4 another implementation manner of an API hybrid multi-tenant routing system according to an embodiment of the present disclosure includes:
  • the APPkey generation module U401 is configured to receive the API caller information transmitted by the API caller or input by the technician, generate an APPkey according to the API caller information, save the APPkey in the IAM, and return the call to the API caller.
  • the APPkey is used to uniquely identify the identity of the API caller.
  • the multi-tenant routing policy table generating module U402 is configured to generate a multi-tenant routing policy table, and save the multi-tenant routing policy table in a cache or a database, where the multi-tenant routing policy table is used to save the APPkey and the API running. a mapping relationship between instance URL lists;
  • the receiving module U403 is configured to receive an API request message sent by the API caller, where the API request message carries the APPkey;
  • the parsing module U404 is configured to parse the API request message to obtain the APPkey
  • a routing module U405 configured to obtain, according to the APPkey and the multi-tenant routing policy table, a multi-tenant routing policy table generated by the module, to obtain a list of API running instance URLs corresponding to the APPkey; and, according to a pre-configured API load balancing And determining, by the API running instance URL list, an API running instance URL corresponding to the API request message, and returning the API running instance URL to the API caller.
  • the multi-tenant routing policy table generating module may be configured to: obtain a corresponding tenant ID from the IAM query according to the APPkey, and generate a first mapping table between the APPkey and the tenant ID; according to the tenant The ID is obtained from the IAM or other storage module to obtain an API running instance URL list, and generates a second mapping table between the tenant ID and the API running instance URL list; according to the first mapping table and the second mapping table.
  • the multi-tenant routing policy table is generated, and the first mapping table and the second mapping table may be persistently stored in a database.
  • the multi-tenant routing policy table generating module may be configured to: obtain, according to the APPkey, information of a corresponding API caller from the IAM according to the APPkey; according to the API caller The information from the IAM determines the tenant to which the API caller belongs, and obtains the tenant ID of the tenant.
  • the APPkey generation module may be further configured to: generate an API authorization credential according to the APPkey, and return the API authorization credential to the API caller.
  • the receiving module is configured to receive an API request message sent by the API caller, where the API request message carries the APPkey and the API authorization credential; and the parsing module is configured to parse the API request message.
  • the routing module U406 is further configured to verify the legality of the APPkey, and if the APPkey is legal, it is used according to the APPkey and the multi-tenant routing policy
  • the table determines the API running instance URL returned to the API caller and returns the API running instance URL to the API caller.
  • the API running instance URL is returned to the API caller, and the API caller invokes the API running instance pointed to by the API running instance URL. .
  • the API hybrid multi-tenant routing system returns the API running instance URL of the physical tenant to the API caller, and if the API caller belongs to the logical tenant, the API is mixed.
  • the tenant routing system returns the shared API running instance URL of the logical tenant to the API caller, so that the API hybrid multi-tenant routing system provided by the embodiment of the present application can adaptively route the correct API running instance URL to the API.
  • the caller does not need the API caller to get the tenant information.
  • the API hybrid multi-tenant routing system provided by the embodiment of the present application can be used to implement the API hybrid multi-tenant routing method provided by the embodiment of the present application.
  • an API hybrid multi-tenant routing method is provided in the embodiment of the present application. The method is applied to an API gateway, and the method includes:
  • step S501 the API gateway generates an APPkey according to the information of the API caller, and returns the APPkey to the API caller, where the APPkey is used to identify the identity of the API caller.
  • Step S502 Generate a multi-tenant routing policy table according to the APPkey, where the multi-tenant routing policy table is used to save a mapping relationship between the APPkey and an API running instance URL list, and the API runs an instance URL list corresponding to the API running.
  • the instance is configured by the API gateway according to the information of the API tenant, and the API caller belongs to the API tenant;
  • Step S503 receiving an API request message sent by the API caller, where the API request message carries the APPkey;
  • Step S504 obtaining the APPkey according to the API request message
  • Step S505 obtaining, according to the APPkey and the multi-tenant routing policy table, an API running instance URL list corresponding to the APPkey;
  • Step S506 determining, according to the pre-configured API load balancing policy, an API running instance URL corresponding to the API request message from the API running instance URL list;
  • Step S507 returning the API running instance URL to the API caller.
  • the generating a multi-tenant routing policy table may include: obtaining a first mapping table between the APPkey and the tenant ID according to the APPkey, and obtaining an API running according to the tenant ID. a second mapping table between the tenant ID and the API running instance URL list, and the multi-tenant routing policy table is generated according to the first mapping table and the second mapping table.
  • the obtaining the corresponding tenant ID according to the APPkey may include: obtaining information of the corresponding API caller from the IAM according to the APPkey; determining, according to the information of the API caller, the tenant to which the API caller belongs Get the tenant ID corresponding to the tenant.
  • the API gateway After determining the API running instance URL corresponding to the API request message, the API gateway returns the API running instance URL to the API caller to complete the API hybrid multi-tenant routing. .
  • the API running instance is configured by the API gateway according to the information of the tenant. If the tenant to which the API caller belongs is a physical tenant, the API running instance URL of the physical tenant is returned to the API caller, if the tenant to which the API caller belongs is The logical tenant, which is returned to the API caller, is the shared API running instance URL assigned to the logical tenant. In this way, the API caller does not need to obtain the tenant information, and only needs to send an API request message carrying the APPkey to the API gateway, so that the correct API running instance can be called, thereby implementing self-adapting hybrid multi-tenant routing.
  • an API gateway is provided in an embodiment of the present application.
  • the API hybrid multi-tenant routing system provided by the embodiment of the present application is a functional module in the API gateway.
  • the API gateway includes a memory, a receiver, a transmitter, and a processor:
  • the receiver is configured to receive an API request message sent by an API caller, where the API request message carries an APPkey, where the APPkey is used to identify an identity of the API caller;
  • the processor executes the code stored in the memory, and is configured to: parse the API request message to obtain the APPkey; and obtain an API running instance corresponding to the APPkey according to the APPkey and the multi-tenant routing policy table.
  • a URL list the multi-tenant routing policy table is stored in the memory, configured to save a mapping relationship between the APPkey and the API running instance URL list; and, according to a pre-configured API load balancing policy, from the Determining an API running instance URL corresponding to the API request message in the API running instance URL list;
  • the generator is configured to send the API running instance URL to the API caller.
  • the processor is further configured to: receive API caller information transmitted by an API caller or input by a technician, generate an APPkey according to the API caller information, and save the APPkey in the memory, where the APPkey is used by The identity that uniquely identifies the API caller.
  • the sender is further configured to send the APPkey to an API caller. .
  • the processor is further configured to generate the multi-tenant routing policy table and save the multi-tenant routing policy table in the memory.
  • the processor may be configured to: obtain a corresponding tenant ID from the IAM query according to the APPkey, generate a first mapping table between the APPkey and the tenant ID, and save the first mapping table in In the memory, obtaining an API running instance URL list from the IAM according to the tenant ID, generating a second mapping table between the tenant ID and the API running instance URL list, and saving the second mapping table in And generating, in the memory, the multi-tenant routing policy table according to the first mapping table and the second mapping table, where the multi-tenant routing policy table may be saved in the memory.
  • the processor is specifically configured to: obtain, according to the APPkey, the information of the corresponding API caller from the IAM; determine, according to the information of the API caller, the tenant to which the API caller belongs, and obtain the tenant ID of the tenant. .
  • the processor may be further configured to: generate an API authorization credential according to the APPkey; the sender is further configured to send the API authorization credential to the API caller.
  • the receiver is used for an API request message sent by an API caller, and the API request message carries the APPkey and the API authorization credential.
  • the processor is further configured to check the legality of the APPkey; if the APPkey is legal, determine an API running instance URL returned to the API caller according to the APPkey.
  • the sender is configured to send the API running instance URL to the API caller.
  • the API caller needs to obtain the tenant information, and sends the tenant ID and the tenant category to the API gateway to obtain the corresponding API running instance, which is very inconvenient for the operation of the API caller, if obtained If the tenant information is incorrect, you cannot call the correct API to run the instance.
  • the API hybrid multi-tenant routing technical solution provided by the embodiment of the present application generates a specific APPkey for the API caller according to the information of the API caller, and the APPkey identifies the identity of the API caller.
  • the API caller only needs to send an API request message carrying the APPkey to the API gateway, and the API gateway determines, according to the APPkey in the API request message, that the correct API running instance URL is returned to the API caller for the API caller. Calling the API running instance pointed to by the API running instance URL. If the API caller belongs to the physical tenant, returning the API running party's private API running instance URL to the API caller, if the API caller belongs to the logical tenant, then the The API caller returns the shared API running instance URL of the logical tenant.
  • the information of the APPkey, the API caller, and the tenant's information (including the tenant ID) to which the API caller belongs may be stored in the IAM. Therefore, the API hybrid multi-tenant routing technology solution provided by the embodiment of the present application can implement self-adaptive routing of an API running instance without requiring the tenant information to be acquired by the guest API caller, thereby improving the convenience of the API caller. And success rate.
  • the embodiment of the present application further provides a computer readable storage medium, including instructions, when executed on a computer, causing the computer to perform the function of the API hybrid multi-tenant routing system provided by the embodiment of the present application.
  • the embodiment of the present application further provides a computer program product including instructions, which when executed on a computer, causes the computer to perform the functions of the API hybrid multi-tenant routing system provided by the embodiment of the present application.

Abstract

本申请实施例提供了一种API混合多租户路由方法、系统及API网关。所述方法包括：在接收到所述API调用方发送的API请求消息后，获取该消息中携带的APPkey；再根据多租户路由策略表，得到与APPkey对应的API运行实例URL列表；最后从API运行实例URL列表中确定一个API运行实例URL返回给API调用方。其中APPkey用于标识API调用方的身份；多租户路由策略表保存APPkey和API运行实例URL列表间的映射关系。所述方法能实现自适配的混合多租户路由，API调用方只需发送携带APPkey的API请求消息，不需租户信息，便可调用到正确的API运行实例。

Description

一种API混合多租户路由方法、系统和API网关
本申请要求于2017年9月26日提交中国专利局、申请号为201710883549.3，发明名称为“一种API混合多租户路由方法、系统和API网关”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及软件技术领域，尤其涉及一种API混合多租户路由方法、系统和API网关。
背景技术
SaaS(software-as-a-service，软件即服务)化之后，API(Application Programming Interface,应用程序编程接口)网关(Gateway)可以将平台或系统等内部的数据或者程序通过Restful(Representational State Transfer，表述性状态传递)API的方式提供给第三方API租户，从而使API租户能够将不同API服务整合到自己的应用中，衍生出新的服务，有利于促进技术生态发展和跨界创新。
不同的API租户，对API资源和安全等的要求不同，由此衍生出了不同的API SLA(Service-Level Agreement，服务等级协议策略)。API网关为了满足不同API租户的SLA策略，需要使用不同方案对外提供API服务。目前API网关的租户有两种——物理租户和逻辑租户，相应地使用的多租户(多个物理租户或者多个逻辑租户)方案也不同。
物理多租户方案中，租户之间的API是物理隔离的，例如使用Docker容器隔离、VM(Virtual Machine，虚拟机)隔离或者物理机隔离。物理多租户方案的原理如图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：Application Key)；再根据多租户路由策略表，得到与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(Identity and Access Management，身份识别与访问管理)中，其中，租户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请求消息头(例如Http Header)中携带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混合多租户路由系统的功能。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、系统或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、系统或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、系统或者设备中还存在另外的相同要素。
本说明书中各个实施例之间相同相似的部分互相参见即可。尤其，对于方法和设备实施例而言，由于其基本相似于装置实施例，所以描述得较简单，相关之处参见装置实施例中的说明即可。

Claims (14)

  1. 一种应用程序编程接口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调用方。
  2. 如权利要求1所述的方法，其特征在于，在所述API网关接收所述API调用方发送的API请求消息之前，还包括：
    根据所述API调用方的信息生成所述APPkey，将所述APPkey返回给所述API调用方；
    生成所述多租户路由策略表。
  3. 如权利要求2所述的方法，其特征在于，所述生成多租户路由策略表，包括：
    根据所述APPkey得到所述API租户的租户ID，生成所述APPkey和所述租户ID之间的第一映射表；
    根据所述租户ID得到所述API运行实例URL列表，生成所述租户ID和所述API运行实例URL列表之间的第二映射表；
    根据所述第一映射表以及所述第二映射表生成所述多租户路由策略表。
  4. 如权利要求3所述的方法，其特征在于，所述根据所述APPkey得到对应的租户ID，包括：
    根据所述APPkey从身份识别与访问管理模块IAM得到对应的API调用方的信息；
    根据所述API调用方的信息确定所述API调用方隶属的API租户，得到所述API租户的租户ID。
  5. 一种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调用方。
  6. 如权利要求5所述的系统，其特征在于，还包括：
    APPkey生成模块，用于根据所述API调用方的信息生成所述APPkey，将所述APPkey返 回给所述API调用方；
    多租户路由策略表生成模块，用于生成所述多租户路由策略表。
  7. 如权利要求6所述的系统，其特征在于，所述多租户路由策略表生成模块，具体用于：
    根据所述APPkey得到所述API租户的租户ID，生成所述APPkey和所述租户ID之间的第一映射表；
    根据所述租户ID得到所述API运行实例URL列表，生成所述租户ID和所述API运行实例URL列表之间的第二映射表；
    根据所述第一映射表以及所述第二映射表生成所述多租户路由策略表。
  8. 如权利要求7所述的系统，其特征在于，所述多租户路由策略表生成模块，具体用于：
    根据所述APPkey从身份识别与访问管理模块IAM得到对应的API调用方的信息；
    根据所述API调用方的信息确定所述API调用方隶属的API租户，得到所述API租户的租户ID。
  9. 一种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调用方。
  10. 如权利要求9所述的API网关，其特征在于，所述处理器还用于：
    根据所述API调用方的信息生成所述APPkey，将所述APPkey返回给所述API调用方；
    生成所述多租户路由策略表并保存于所述存储器。
  11. 如权利要求10所述的API网关，其特征在于，所述处理器具体用于：
    根据所述APPkey得到对应的租户ID，生成所述APPkey和所述租户ID之间的第一映射表，将所述第一映射表保存于所述存储器中；
    根据所述租户ID得到所述API运行实例URL列表，生成所述租户ID和所述API运行实例URL列表之间的第二映射表，将所述第二映射表保存于所述存储器中；
    根据所述第一映射表以及所述第二映射表生成所述多租户路由策略表。
  12. 如权利要求11所述的API网关，其特征在于，所述所述处理器具体用于：
    根据所述APPkey从身份识别与访问管理模块IAM得到对应的API调用方的信息；
    根据所述API调用方的信息确定所述API调用方隶属的API租户，得到所述API租户的租户ID。
  13. 一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行如 权利要求1-4任意一项所述的方法。
  14. 一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行如权利要求1-4任意一项所述的方法。
PCT/CN2018/099362 2017-09-26 2018-08-08 一种api混合多租户路由方法、系统和api网关 WO2019062340A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP18863352.3A EP3678358B1 (en) 2017-09-26 2018-08-08 Api hybrid multi-tenant routing method, system, and api gateway
US16/831,314 US11272036B2 (en) 2017-09-26 2020-03-26 API hybrid multi-tenant routing method and system, and API gateway

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710883549.3A CN109561226B (zh) 2017-09-26 2017-09-26 一种api混合多租户路由方法、系统和api网关
CN201710883549.3 2017-09-26

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/831,314 Continuation US11272036B2 (en) 2017-09-26 2020-03-26 API hybrid multi-tenant routing method and system, and API gateway

Publications (1)

Publication Number Publication Date
WO2019062340A1 true WO2019062340A1 (zh) 2019-04-04

Family

ID=65862957

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/099362 WO2019062340A1 (zh) 2017-09-26 2018-08-08 一种api混合多租户路由方法、系统和api网关

Country Status (4)

Country Link
US (1) US11272036B2 (zh)
EP (1) EP3678358B1 (zh)
CN (1) CN109561226B (zh)
WO (1) WO2019062340A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110022412A (zh) * 2019-05-20 2019-07-16 努比亚技术有限公司 通话界面响应方法、可穿戴设备和计算机可读存储介质

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10834054B2 (en) 2015-05-27 2020-11-10 Ping Identity Corporation Systems and methods for API routing and security
US10587580B2 (en) 2016-10-26 2020-03-10 Ping Identity Corporation Methods and systems for API deception environment and API traffic control and security
EP3471007B1 (en) 2017-10-13 2022-02-23 Ping Identity Corporation Methods and apparatus for analyzing sequences of application programming interface traffic to identify potential malicious actions
US11044337B2 (en) * 2018-09-12 2021-06-22 International Business Machines Corporation Runtime localized messages for cloud services
US11140169B1 (en) * 2018-10-31 2021-10-05 Workday, Inc. Cloud platform access system
US11496475B2 (en) * 2019-01-04 2022-11-08 Ping Identity Corporation Methods and systems for data traffic based adaptive security
CN110311867A (zh) * 2019-07-02 2019-10-08 江苏满运软件科技有限公司 应用模块化管理方法、装置、电子设备、存储介质
CN110443048A (zh) * 2019-07-04 2019-11-12 广州海颐信息安全技术有限公司 数据中心查数系统
CN110784551A (zh) * 2019-11-05 2020-02-11 中国建设银行股份有限公司 基于多租户的数据处理方法、装置、设备和介质
CN110995829B (zh) * 2019-11-29 2022-07-22 广州市百果园信息技术有限公司 实例调用方法、装置及计算机存储介质
CN111314491B (zh) * 2020-03-27 2022-07-08 北京尚医智信健康管理有限公司 跨租户数据交互方法、装置、服务器集群及介质
US11513876B2 (en) 2021-02-23 2022-11-29 Sap Se Resolving data location for queries in a multi-system instance landscape
CN113271334B (zh) * 2021-03-25 2023-07-21 西藏宁算科技集团有限公司 基于SaaS场景下的业务策略分发方法、装置及电子设备
US20230015697A1 (en) * 2021-07-13 2023-01-19 Citrix Systems, Inc. Application programming interface (api) authorization
CN113590341B (zh) * 2021-09-27 2022-02-22 腾讯科技（深圳）有限公司 服务组件调用方法、装置、计算机设备和存储介质
CN114726809B (zh) * 2022-06-10 2022-09-20 北京沃丰时代数据科技有限公司 多租户路由方法、装置、设备、存储介质及程序产品
US11895238B1 (en) * 2022-08-15 2024-02-06 Expel, Inc. Systems and methods for intelligently constructing, transmitting, and validating spoofing-conscious digitally signed web tokens using microservice components of a cybersecurity threat mitigation platform

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102281330A (zh) * 2011-08-03 2011-12-14 深圳市科迪特信息技术有限公司 用于saas平台的数据存储、通讯访问及控制的方法
US8601000B1 (en) * 2011-06-27 2013-12-03 Amazon Technologies, Inc. System and method for conditionally updating an item with attribute granularity
CN106464534A (zh) * 2014-06-09 2017-02-22 思科技术公司 配设和管理用户驻地设备装置的片
CN106462466A (zh) * 2014-06-23 2017-02-22 甲骨文国际公司 用于在多租户应用服务器环境中提供工作管理器的系统和方法

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8718241B2 (en) * 2010-05-07 2014-05-06 Salesforce.Com, Inc. Methods and apparatus for interfacing with a phone system in an on-demand service environment
US8634415B2 (en) * 2011-02-16 2014-01-21 Oracle International Corporation Method and system for routing network traffic for a blade server
CN102708316B (zh) * 2012-04-19 2015-04-08 北京华胜天成科技股份有限公司 一种用于多租户架构中数据隔离的方法
US9521040B2 (en) * 2013-04-03 2016-12-13 Salesforce.Com, Inc. System and method for generic configuration management system application programming interface
US9632878B1 (en) * 2013-09-20 2017-04-25 Amazon Technologies, Inc. Verification of database table partitions during backup
US10063654B2 (en) * 2013-12-13 2018-08-28 Oracle International Corporation Systems and methods for contextual and cross application threat detection and prediction in cloud applications
US10511694B2 (en) * 2014-07-23 2019-12-17 Citrix Systems, Inc. Systems and methods for application specific load balancing
US9742626B2 (en) * 2014-09-16 2017-08-22 CloudGenix, Inc. Methods and systems for multi-tenant controller based mapping of device identity to network level identity
US10757170B2 (en) * 2014-10-13 2020-08-25 Vmware, Inc. Cross-cloud namespace management for multi-tenant environments
US10230571B2 (en) * 2014-10-30 2019-03-12 Equinix, Inc. Microservice-based application development framework
US10834054B2 (en) * 2015-05-27 2020-11-10 Ping Identity Corporation Systems and methods for API routing and security
US10419514B2 (en) * 2015-08-14 2019-09-17 Oracle International Corporation Discovery of federated logins
US10721328B2 (en) * 2015-08-26 2020-07-21 International Business Machines Corporation Offering application program interfaces (APIs) for sale in cloud marketplace

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8601000B1 (en) * 2011-06-27 2013-12-03 Amazon Technologies, Inc. System and method for conditionally updating an item with attribute granularity
CN102281330A (zh) * 2011-08-03 2011-12-14 深圳市科迪特信息技术有限公司 用于saas平台的数据存储、通讯访问及控制的方法
CN106464534A (zh) * 2014-06-09 2017-02-22 思科技术公司 配设和管理用户驻地设备装置的片
CN106462466A (zh) * 2014-06-23 2017-02-22 甲骨文国际公司 用于在多租户应用服务器环境中提供工作管理器的系统和方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3678358A4

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110022412A (zh) * 2019-05-20 2019-07-16 努比亚技术有限公司 通话界面响应方法、可穿戴设备和计算机可读存储介质

Also Published As

Publication number Publication date
EP3678358B1 (en) 2022-06-15
EP3678358A1 (en) 2020-07-08
CN109561226A (zh) 2019-04-02
EP3678358A4 (en) 2020-09-30
CN109561226B (zh) 2020-06-26
US20200228629A1 (en) 2020-07-16
US11272036B2 (en) 2022-03-08

Similar Documents

Publication Publication Date Title
WO2019062340A1 (zh) 一种api混合多租户路由方法、系统和api网关
US10965772B2 (en) Interface invocation method and apparatus for hybrid cloud
EP2806612B1 (en) Method, device and system for using and invoking oauth api
KR102372568B1 (ko) 서버 요청에서 캡슐화된 코드를 통한 멀티테넌시
US10135803B2 (en) Dynamic identity switching
CN107005582B (zh) 一种使用存储在不同目录中的凭证来访问公共端点的方法
WO2019165665A1 (zh) 一种域名解析方法、服务器及系统
US8832271B2 (en) Identity provider instance discovery
US11750721B2 (en) Bidirectional command protocol via a unidirectional communication connection for reliable distribution of tasks
JP6190949B2 (ja) 仮想ネットワーク機能マネージャによる仮想インフラストラクチャマネージャへのアクセスの自動化構成
US20170048225A1 (en) Method, Apparatus, and System for Secure Authentication
CN104639603B (zh) 一种基于Spring MVC的RESTful服务设计方法
CN107979520B (zh) 消息处理方法及消息处理装置
US10678906B1 (en) Multi-service and multi-protocol credential provider
US9401908B1 (en) Authentication interworking in communications networks
WO2015096344A1 (zh) App获取终端的mac地址的方法及系统
WO2013152565A1 (zh) 能力聚合开放的方法和系统
CN112165454A (zh) 访问控制方法、装置、网关和控制台
Mehmood et al. Multi-agent based framework for secure and reliable communication among open clouds
CN113067803B (zh) 一种资源隔离系统、请求处理方法及请求处理装置
CN114338682A (zh) 流量身份标识传递方法、装置、电子设备及存储介质
CN107770203B (zh) 一种服务请求转发方法、装置及系统
WO2013098925A1 (ja) 情報処理装置、情報処理システム、情報処理方法およびプログラム
WO2010072158A1 (zh) 一种业务链中的用户身份验证方法、设备及系统
CN114025023B (zh) 回源方法、装置、设备及计算机可读存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18863352

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2018863352

Country of ref document: EP

Effective date: 20200331