协助api调用处理的加速系统

文档序号:1432477 发布日期:2020-03-17 浏览:6次 >En<

阅读说明:本技术 协助api调用处理的加速系统 (Acceleration system for assisting API call processing ) 是由 奥利维尔·吉恩·普瓦特雷 于 2018-06-19 设计创作,主要内容包括:一个实施例包括加速系统,该加速系统作为API处理系统和客户端之间的中介进行操作以减少API调用往返延迟。加速系统是互连系统的网络,其中这些互连系统分布在全球各地。给定的加速系统与给定的客户端建立网络连接,并通过该连接接收用于处理API调用的请求。与API调用相关联的编程功能被配置在API处理系统中。加速系统通过与API处理系统已建立的连接来协助API调用的处理。(One embodiment includes an acceleration system that operates as an intermediary between an API processing system and a client to reduce API call round-trip latency. An acceleration system is a network of interconnected systems, where these interconnected systems are distributed around the globe. A given acceleration system establishes a network connection with a given client and receives a request to process an API call over the connection. The programming functions associated with the API calls are configured in the API processing system. The acceleration system assists in the processing of the API calls through the established connection with the API processing system.)

协助API调用处理的加速系统

相关申请交叉引用

本申请要求2017年6月20日提交的美国专利申请序列号15/628,509的权益,其通过引用合并于此。

技术领域

本发明一般涉及基于云的计算,并且更具体地,涉及用于协助应用编程接口(API)调用处理的加速系统。

背景技术

许多基于互联网的服务被托管在基于云的系统上。基于云的系统通常包括地理上分布式的服务器,使得基于云的系统上所托管的服务的客户端被路由到基于云的系统的最近的服务器。在某些情况下,即使是基于云的系统中最近的服务器也距客户端相当远。

一般地,客户端离其路由到的服务器越远,服务器与客户端之间的通信往返就越慢并且通信延迟就越高。此外,为了与服务器建立通信连接,客户端必须执行若干通信握手,例如传输控制协议(TCP)握手。此外,客户端与服务器进行传输层安全性(TLS)握手,以建立安全的通信会话。TLS握手通常在客户端和服务器之间进行两次往返。

客户端离其路由到的服务器越远,执行这些握手并因此在客户端和服务器之间建立连接所花费的时间就越长。因此,在客户端与服务器距离相当远的情况下,通过基于云的系统访问基于互联网的服务的功能可能会非常慢,并导致不良的用户体验。

发明内容

本发明的一个实施例阐述了一种方法,该方法包括用于将客户端设备引导至适当的API边缘网关的方法。该方法包括从客户端设备接收与应用编程接口(API)调用相关联的引导请求。该方法还包括:响应于接收引导请求,基于可达性选择标准来选择加速系统,并将客户端设备路由到该加速系统,其中该加速系统作为客户端设备和API处理系统之间的中介进行操作并同时使得API调用能够被处理。

所公开的方法的一个优点在于,当加速系统作为客户端设备和API处理系统之间的中介进行操作时,减少了用于处理API调用的往返时间。特别地,相对于需要在客户端设备和API处理系统之间建立连接的情况,在客户端设备和加速系统之间建立通信连接所需的任何往返时间都较短。

附图说明

图1示出了被配置为实现本发明的一个或多个方面的系统环境。

图2是根据本发明的一个实施例,示出图1的组件之间的交互的交互图。

图3示出了被配置为实现本发明的一个或多个方面的引导系统环境。

图4是根据本发明的一个实施例,示出使用唯一标识符的图3的组件之间的交互的交互图。

图5是根据本发明的另一实施例,用于将客户端引导到API接入端点的方法步骤的流程图。

具体实施方式

在下面的描述中,阐述了许多具体细节以提供对本发明的更透彻的理解。然而,对于本领域的技术人员将显而易见的是,可在没有这些具体细节中的一个或多个的情况下实践本发明。在其他情况下,没有描述众所周知的特征,以避免使本发明晦涩难懂。

图1示出了被配置为实现本发明的一个或多个方面的系统环境100。如图所示,系统环境100包括API处理系统102、客户端104(0)-104(N)(统称为“客户端104”,并且各自称为“客户端104”)、加速系统106(0)-106(N)(统称为“加速系统106”,并且各自称为“加速系统106”)。

API处理系统102、加速系统104、和客户端102通过通信网络(未示出)进行通信。该通信网络包括被配置为协助数据通信的多个网络通信系统,例如路由器和交换机。本领域技术人员将认识到,存在许多用于构建通信网络的技术上可行的技术,包括在部署众所周知的互联网通信网络中实践的技术。

API处理系统102包括互连节点的网络,该互连节点分布在全球各地,并且接收、发送、处理和/或存储与系统环境100相关联的数据。互连节点可以包括用于执行这些所需功能的软件、固件、和硬件的任何适当组合。特别地,API处理系统102包括可以位于同一地点或物理上彼此分布的多个计算设备。例如,这些计算设备可以包括一个或多个通用PC、Macintosh、工作站、基于Linux的计算机、服务器计算机、一个或多个服务器池、或任何其他适当的设备。计算设备存储并执行一个或多个程序,这些程序可通过相应的应用编程接口(API)进行远程访问。在一些实施例中,API处理系统102以收费方式向外部实体提供计算资源。这样的实体对API处理系统102的部分进行配置,并且那些实体的客户端访问API处理系统102的经配置的部分以执行与该实体相关联的操作。

客户端104在一个或多个物理位置处包括一个或多个计算机系统。每个计算机系统可以包括任何适当的输入设备(例如,小键盘、触摸屏、鼠标、或其他可以接受信息的设备)、输出设备、大容量存储介质、或其他用于接收、处理、存储、和传送数据的适当的组件。输入设备和输出设备两者都可以包括固定或可移动存储介质,例如磁性计算机盘、CD-ROM。每个计算机系统可以包括个人计算机、工作站、网络计算机、一体机(kiosk)、无线数据端口、平板计算机、这些或其他设备内的一个或多个处理器、或任何其他适当的处理设备。

每个客户端104可以包括计算机系统、机顶盒、诸如移动电话之类的移动设备、或具有网络连接性的任何其他技术上可行的计算平台。在一个实施例中,客户端104被耦合至或包括显示设备和扬声器设备,分别用于呈现视频内容和生成声音输出。每个客户端104包括依赖于API处理系统102进行某些操作的计算机硬件和/或计算机软件。

特别地,客户端104执行一个或多个基于云的应用,该应用通过通信网络与API处理系统102通信以执行各种操作。在一个实施例中,基于云的应用通过向API处理系统102的一部分发出请求来进行操作,其中API处理系统102的该部分配置有处理该请求所需的处理基础设施。响应于接收该请求,API处理系统102处理该请求并生成输出数据,该输出数据被发送回基于云的应用。在客户端104上执行的基于云的应用与远程服务器之间的这种往返被称为API调用往返。一般地,客户端104离API处理系统102的该部分越远,API调用往返的延迟就越高。此外,API处理系统102的该部分处理该请求的拥塞越高,API调用往返的延迟就越高。

加速系统106作为API处理系统102与客户端104之间的中介进行操作,以减少API调用往返延迟。加速系统106包括互连系统的网络,该互连系统分布在全球各地,并且每个互连系统作为客户端104和API处理系统102之间的中介进行操作。给定的加速系统106与给定的客户端104建立网络连接并通过该连接接收用于处理API调用的请求。在API处理系统102中配置与API调用相关联的编程功能。加速系统106通过与API处理系统102的连接来协助API调用的处理。

当加速系统106作为API处理系统102与客户端104之间的中介进行操作时,API调用往返时间出于至少两个原因而减小。第一,在一些实施例中,相对于API处理系统102,加速系统106一般在物理上更靠近客户端104。因此,相对于需要在客户端104与API处理系统102之间建立连接的情况,在客户端104与加速系统106之间建立通信连接所需的任何往返时间均较短。第二,在一些实施例中,由于加速系统106具有源自多个客户端104的大量请求,因此加速系统106具有连贯的且与API处理系统102已建立的连接。因此,不需要针对每个API调用建立与API处理系统102的连接。

图2是根据本发明的一个实施例,示出图1的组件之间的交互的交互图。特别地,客户端104和加速系统106执行202传输控制协议(TCP)握手。TCP握手是客户端104和加速系统106通过其来协商并开始用于彼此通信的TCP通信会话的机制。客户端104和加速系统106执行204传输层安全性(TLS)握手。TLS握手是客户端104和加速系统106通过其来交换建立安全通信会话所需的安全密钥的机制。

一旦建立了安全通信会话,客户端104就通过已建立的连接发送206用于处理给定的API调用的超文本传输协议(HTTP)请求。加速系统106将用于处理API调用的HTTP请求转发208给API处理系统102。在一个实施例中,加速系统106管理多个HTTP请求,这些HTTP请求进而被转发给API处理系统102。为了管理这些请求的传输和/或顺序,加速系统106使用HTTP/2多路复用那些请求。API处理系统102处理API调用,并将处理结果以HTTP响应的方式发送210给加速系统106。加速系统106将HTTP响应转发212给客户端104。

从TCP握手开始到客户端104接收到HTTP响应之间的持续时间是API调用往返时间。在一个实施例中,该API调用往返时间比其中客户端104直接与API处理系统102进行通信的实施方式低。API调用往返时间较低,部分原因是在执行TCP握手和TLS握手时客户端104与加速系统106之间的通信的低延迟。

图3示出了被配置为实现本发明的一个或多个方面的引导系统环境300。系统环境300包括API边缘网关302、客户端304、测量系统306、和客户端引导系统308。

API边缘网关302包括可以由客户端304访问以处理给定API调用的不同系统。在所示的实施例中,API边缘网关302包括嵌入式加速系统320(各自称为“加速系统320”)、互联网交换(IX)加速系统318(各自称为“加速系统322”)、和图1的API处理系统102。

嵌入式加速系统320和IX加速系统322包括许多在地理上分布的加速系统106的实例,并与API处理系统102一起协助API调用的处理。每个嵌入式加速系统320都是嵌入在与ISP相关联的网络内的加速系统106。在一个实施例中,因为加速系统320在ISP内部,所以加速系统320仅可由与ISP相关联和/或订阅ISP的客户端访问。IX加速系统322中的每一个都是在互联网交换点之内操作或与互联网交换点相关联地操作,并且独立于ISP的加速系统106。互联网交换点是ISP和内容传递网络(CDN)通过其来交换互联网业务的物理基础设施。

测量系统306监测客户端(例如,客户端304)与API边缘网关302之间的交互,以测量不同的客户端或客户端组与不同的API边缘网关302之间的延迟。引导系统308将客户端(例如,客户端304)引导到API边缘网关302中的一个(即,嵌入式加速系统320中的一个、IX加速系统322中的一个、或API处理系统102),以基于由测量系统测量到的延迟来处理API调用。以这种方式,来自客户端的API调用由API边缘网关302处理,该API边缘网关302,基于过去的延迟测量,可以与关于该客户端的最低延迟相关联。

以下讨论提供了关于测量系统306如何测量客户端304和API边缘网关302之间的延迟的细节。该讨论还提供了关于客户端引导系统308如何使用测量到的延迟来将客户端304引导到适当的API边缘网关302的细节。

客户端304包括探测模块310,用于使测量系统306能够监测客户端304与API边缘网关302之间的交互。探测模块310查询监测API端点以请求与要监测的不同API边缘网关302相关联的唯一资源定位符(URL)的列表。列表中的每个URL都有给定的名称,该名称对应于与该URL相关联的API边缘网关302。来自监测API端点的响应包括URL的列表以及控制测量过程的参数集合。这些参数包括等待参数,该等待参数指定探测模块310在完成给定测量过程之后应等待的时间长度以开始另一测量过程。这些参数还包括指定在测量过程期间要为每个所提供的URL执行的请求数量的脉冲参数、指定在针对所提供的URL的每个请求之间等待的时间长度的脉冲间隔参数、以及指定等待针对所提供的URL的请求完成的最长时间长度的脉冲超时参数。在一个实施例中,列表中提供的返回到探测模块310的URL与到期相关联。

在测量过程期间,探测模块310收集测量数据集合,该测量数据集合与针对由监测API端点提供的URL的每个请求相关联。测量数据包括但不限于,请求的总持续时间、建立TCP连接所花费的时间长度、执行TLS握手所花费的时间长度、解析与URL相关联的主机名的时间长度、到第一个字节的时间(即,从请求的开始到响应于请求而接收到第一个字节之间的时间)、与对请求的响应相关联的HTTP状态码、以及响应于请求而接收到的有效负载大小。除了参数之外,探测模块310还收集与URL相关联的API端点与客户端304之间的任何中介系统。这些中介系统包括加速系统320和322或API托管服务。探测模块310将收集到的与在测量过程期间发出的每个请求相关联的测量数据发送到测量系统306。

在一个实施例中,客户端304配置有HTTP保持活动状态,使得在连接被建立之后,对同一URL的后续请求可以重新使用该连接。在这样的实施例中,用于后续请求的测量参数的长度可以比其中首先建立连接的第一个请求要短。在一个实施例中,探测模块310对同一测量过程内和/或跨越两个测量过程的不同请求之间的已建立的连接进行重置。

测量系统306包括映射引擎312和测量存储装置314。测量系统306将从包括客户端304在内的不同客户端接收的测量数据存储在测量存储装置314中,以用于进一步的处理。映射引擎312在客户端集合与API边缘网关302中的一个(即,嵌入式加速系统320中的一个、IX加速系统322中的一个、或API处理系统102)之间生成映射。给定的API边缘网关302基于延迟标准和可达性标准最适合于处理客户端集合所发出的API调用。

关于延迟标准,映射引擎312考虑了由存储在测量存储装置314中的测量数据捕获的API调用往返时间(也称为“延迟”)。在一个实施例中,延迟表示在测量过程期间完成与给定URL相关联的请求或请求集合所花费的总时间。所表示的时间在客户端和与URL相关联的API边缘网关302之间的连接被发起时开始,并且在客户端接收到与API调用相关联的响应时结束。在一个实施例中,对于给定的客户端集合,映射引擎312基于存储在测量存储装置314中的测量数据对API边缘网关302集合中的每一个进行评分。给定的API边缘网关302的得分可以基于处理由给定客户端或客户端集合发出的API调用的中值延迟。

关于可达性标准,映射引擎312将客户端集合仅映射到那些客户端可访问的那些加速系统320或322。如上所述,因为嵌入式加速系统320在ISP内部,所以嵌入式加速系统320仅可由与ISP相关联和/或订阅ISP的客户端访问。因此,仅当客户端集合与给定的嵌入式加速系统320所嵌入的ISP相关联和/或订阅该ISP时,映射引擎312才将该客户端集合映射到该嵌入式加速系统320。类似地,由于IX加速系统322在互联网交换点内部,因此IX加速系统322仅可由可以访问该互联网交换点的客户端访问。因此,仅当客户端304可以访问包括给定的IX加速系统322的互联网交换点时,映射引擎312才将客户端集合映射到该IX加速系统322。

映射引擎312基于客户端集合与最适合于处理由那些客户端集合发出的API调用的各个API边缘网关302之间所确定的映射来生成网关映射。映射引擎312将网关映射发送到客户端引导系统308,以响应于来自客户端的引导请求来执行客户端引导。网关映射存储密钥-网关配对,其中密钥-网关配对中的密钥标识一个或多个客户端,并且密钥-网关配对中的网关标识最适合处理该客户端集合发出的API调用的API边缘网关302。在一个实施例中,密钥-网关配对中的密钥是与给定客户端相关联的IP地址。基于存储在测量存储装置314中的测量数据来确定与给定客户端相关联的IP地址。

在某些情况下,由客户端引导系统308接收的引导请求不包括客户端的IP地址,但替代地包括与客户端通过其来访问互联网的ISP相关联的解析器的IP地址。为了在这种情况下客户端引导系统308能够使用网关映射,密钥-网关配对中的密钥应该是与一组客户端相关联的解析器IP,该组客户端通过与解析器相关联的ISP访问互联网。由于从不同客户端接收到的测量数据指定了客户端IP地址而不是解析器IP地址,因此映射引擎312实现了一种关联技术,以将测量数据和从中计算出的延迟与解析器IP地址相关联。

图4是根据本发明的一个实施例的使用唯一标识符的图3的组件之间的交互的交互图。特别地,客户端304将包括主机名和与客户端304相关联的唯一标识符的解析请求发送402给解析器400。解析器400与客户端304通过其来访问互联网的ISP相关联。解析器400解析主机名,并因此将客户端304重定向404到测量系统306。在重定向过程中,针对测量系统306的请求包括解析器的IP地址。测量系统306在测量存储装置314中记录406解析器IP地址与唯一标识符之间的关系。

客户端304将API调用请求发送412到API边缘网关302。API调用请求包括唯一标识符和与客户端304相关联的不同于解析器IP地址的客户端IP地址。API边缘网关302视情况处理API调用或协助API调用的处理,并将API响应发送414到客户端304。API边缘网关302还在测量存储装置314中记录416与API调用的处理相关联的测量数据。测量数据指定客户端IP地址和唯一ID。

如上所述,测量引擎312处理接收到的测量数据,以计算与处理API调用相关联的延迟。此外,测量引擎312通过将与解析器IP地址相关联地记录的唯一ID与由记录的测量数据指定的唯一ID进行匹配,来确定延迟与解析器ID相关联。以这种方式,即使测量数据不包括客户端IP地址,也可以将基于指定了客户端IP地址的测量数据来确定的延迟与解析器IP地址相关联。

返回图3,对于给定的API调用,客户端引导系统308将客户端304引导至API边缘网关302中的一个(即,嵌入式加速系统320中的一个、IX加速系统322中的一个、或API处理系统102)来处理API调用。为了执行此引导功能,客户端引导系统包括选择引擎316和从测量系统306接收的网关映射318。

选择引擎316从客户端304接收用于API调用处理的引导请求。为了便于讨论,以下描述了选择引擎316如何处理从客户端304接收的并与给定API调用相关联的给定引导请求。在一个实施例中,引导请求包括与客户端设备相关联的互联网协议(IP)地址。在替代实施例中,引导请求包括客户端设备通过其来访问互联网的ISP的解析器的IP地址。

响应于来自客户端304的引导请求,选择引擎316选择API边缘网关302中的一个以用于处理API调用。特别地,选择引擎316将客户端304路由到嵌入式加速系统320中的一个、IX加速系统322中的一个、或API处理系统102。选择引擎316利用网关映射318来从嵌入式加速系统320和IX加速系统322中标识适当的加速系统以用于处理API调用。特别地,选择引擎316将包括在引导请求中的IP地址与网关映射318中的密钥-网关对中的IP地址进行匹配。选择引擎316然后选择在密钥-网关对中标识的网关作为客户端304被引导到的API边缘网关302。在一个实施例中,如果基于选择标准未能标识出适当的加速系统,则选择引擎316将客户端304直接路由到API处理系统102以处理API调用。

在一个实施例中,除了网关映射之外,选择引擎316还监测嵌入式加速系统320和IX加速系统322中的每一个,以确定加速系统上的当前负载。选择引擎316监测加速系统320或322的不同方面以确定其当前负载。这些方面包括但不限于,与客户端的活动会话的数量以及API处理系统正在协助的API调用的数量。此外,选择引擎316还可以监测加速系统320或322正在被使用的处理资源的量、加速系统320或322正在被使用的存储器资源的量、以及加速系统320或322与API处理系统102之间的通信通道上的拥塞水平。

如上所述,加速系统320和322中的每一个作为许多不同客户端与API处理系统102之间的中介进行操作。因此,加速系统320或322上的负载根据在任何给定时间加速系统正在协助的API调用的数量而变化。当所确定的加速系统320或322上的负载超过某个阈值时,选择引擎316可以推迟对用于协助处理任何其他API调用的加速系统的选择,直到负载降至阈值以下。

图5是根据本发明的另一实施例的用于将客户端引导到API边缘网关的方法步骤的流程图。尽管结合图1和图3的系统描述了方法步骤,但是本领域技术人员将理解,被配置为以任何顺序执行这些方法步骤的任何系统都在本发明的范围内。

方法500开始于步骤502,其中客户端引导系统308从客户端304接收用于处理API调用的引导请求。引导请求包括与客户端或解析器相关联的互联网协议地址,其中该解析器与客户端通过其来访问互联网的ISP相关联。

在步骤504,引导系统308标识客户端可访问的加速系统的子集。如上所述,在某些情况下,某些加速系统仅对那些能够访问加速系统所嵌入的互联网交换点或ISP的客户端是可访问的。由于客户端304能够访问加速系统是作为在客户端304和API处理系统102之间的中介进行操作的加速系统的必要方面,因此引导系统308仅选择客户端304可访问的那些加速系统。

在步骤506,引导系统308基于从测量系统306接收的网关映射来确定与客户端304相关联的测量数据。该测量数据表示由该客户端或要与给定客户端一起引导的一个或多个其他客户端做出的先前API调用的API调用往返时间。在步骤508,引导系统308基于测量数据从在步骤506处标识的子集中选择加速系统。引导系统308基于先前测量的延迟来选择加速系统。

在步骤510,引导系统308将客户端304路由到所选择的加速系统以处理API调用。作为响应,客户端304将用于处理API调用的请求发送到所选择的加速系统,并且加速系统协助API处理系统102对API调用的处理。

总之,加速系统作为API处理系统与客户端之间的中介进行操作,以减少API调用往返延迟。加速系统包括互连系统的网络,这些系统分布在全球各地,并且每个系统都作为客户端和API处理系统之间的中介进行操作。给定的客户端与给定的加速系统建立网络连接,并通过该连接发送用于处理API调用的请求。与API调用相关联的编程功能被配置在API处理系统中。加速系统通过与API处理系统先前建立的连接来协助API调用的处理。

有利地,当加速系统作为客户端设备与API处理系统之间的中介进行操作时,用于处理API调用的往返时间被减少。特别地,相对于需要在客户端设备和API处理系统之间建立连接的情况,在客户端设备和加速系统之间建立通信连接所需的任何往返时间都较短。

尽管前述内容针对本发明的实施例,但是在不脱离本发明的基本范围的情况下,可以设计本发明的其他和进一步的实施例。例如,本发明的方面可以以硬件或软件或以硬件和软件的组合来实现。本发明的一个实施例可以被实现为与计算机系统一起使用的程序产品。程序产品的(一个或多个)程序限定实施例的功能(包括本文描述的方法),并且可以被包含在各种计算机可读存储介质上。说明性的计算机可读存储介质包括但不限于:(i)永久性存储信息的不可写存储介质(例如,计算机内的只读存储器设备,例如CD-ROM驱动器可读取的CD-ROM盘、闪存、ROM芯片、或任何类型的固态非易失性半导体存储器);(ii)存储可变信息的可写存储介质(例如,磁盘驱动器或硬盘驱动器内的软盘或任何类型的固态随机存取半导体存储器)。当携带指导本发明的功能的计算机可读指令时,这样的计算机可读存储介质是本发明的实施例。

鉴于前述内容,本发明的范围由所附权利要求确定。

16页详细技术资料下载
上一篇:一种医用注射器针头装配设备
下一篇:通信网络

网友询问留言

已有0条留言

还没有人留言评论。精彩留言会获得点赞!

精彩留言,会给你点赞!

技术分类