一种过滤抖动的渐进式流量调度方法和系统

暂无

一种过滤抖动的渐进式流量调度方法和系统\n技术领域\n[0001] 本申请涉及互联网的技术领域，特别是涉及一种过滤抖动的渐进式流量调度方法和系统。\n背景技术\n[0002] 随着，在互联网上的数据传输量的与日俱增，为了能够避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输得更快、更稳定，已经提供了一种CDN(Content Delivery Network，内容分发网络)技术。在所述技术中，通过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络，来提高网络的响应速度。常见的智能虚拟网络的网络结构有中心-边缘层次这种两层的结构，第一层是边缘服务节点，部署在尽量靠近用户的网络中，第二层是中心节点，部署在网络质量好的主干网络中，此类型节点访问源站通常会比较快。边缘服务节点和中心节点是多对多的关系。在所述中心-边缘层次网络结构中选择最优路径是内容分发系统中的一个重要功能，其目的是使用户可就近取得所需内容，解决Internet网络拥挤的状况，提高用户访问网站的响应速度以加速用户请求的应答。\n[0003] 在使用传统的CDN技术的过程中，一个请求到边缘服务节点后，接着会选择通过哪个中心节点去回源，而选择的依据是通过边缘服务节点定期探测到各个中心节点之间的RTT(Round-Trip Time往返时延)值，选择值最小的中心节点作为下一目的地。\n[0004] 但实际的过程中，会存在如下问题：由于各个中心节点的资源配置不同，能承受的最大负载会有差异。如果只通过RTT来判断，由于RTT并不能真实反映中心节点的处理能力，可能会使得边缘服务节点把过多的流量引导到性能差的中心节点，从而造成中心节点过载，请求应答延迟大，甚至压垮机器而宕机。例如，一些邻近的老旧中心节点的硬件配置可能已经落伍，因此，尽管其RTT值目前可能看上去很小，但一旦将大量任务分发给该中心节点，就会占据该中心内节点的几乎所有资源，因而很容易造成该中心节点过载并导致应答迟缓。相反，某些中心节点可能距离较远，但由于其硬件配置较新，如果将这些任务分配给这些中心节点也仅仅是占用其一部分资源并不会影响其正常工作，因此，来自这些具有较大RTT值的中心节点的应答反而会快于来自较近的老旧中心节点的应答。显然，这种基于RTT的判断提供的并不是最优的路径。\n[0005] 另一方面，一旦某个中心节点的RTT由好变差，传统的CDN技术就会对路径选择进行一刀切，即把所有的请求都引导到其他中心节点。等这些流量都被引导到别的中心节点之后，随着请求任务的减少，这个中心节点的RTT变好。此后，传统技术会重新把后续请求都导入这个中心节点。如果流量过多则这个中心节点的RTT又会重新变差……。如此不断反复此过程，最终导致CDN的服务质量发生较大抖动，性能很不稳定，影响产品口碑。\n[0006] 因此，存在一种对能够过滤抖动的流量调度方法和系统，以解决上述传统技术中的问题。\n发明内容\n[0007] 鉴于以上所述现有技术的缺点，本申请的目的在于提供一种过滤抖动的渐进式流量调度方法和系统，以在中心-边缘层次网络结构中选择最优路径，同时消除传统CDN技术中的抖动问题。\n[0008] 为了实现上述目的及其他相关目的，本申请提供一种过滤抖动的渐进式流量调度方法，包括以下步骤：步骤S1、边缘服务节点定期发送探测请求到各个中心节点，每个中心节点把当前机器的综合负载信息响应给边缘服务节点；步骤S2、边缘服务节点根据收到的中心节点综合负载信息后，先按RTT进行从小到大进行排序，再按照综合负载信息判断每个中心节点的负载情况，从而得出每个中心节点的流量调度策略，并更新每个中心节点的负载阈值；步骤S3、边缘服务节点收到用户发过来的请求后，根据每个中心节点的负载阈值，查询出最终要发送的中心节点的ip，把这个请求转发到相应的中心节点。\n[0009] 根据本申请的另一方面，提供了一种过滤抖动的渐进式流量调度系统，其特征在于，包括：\n[0010] 源站(150)；\n[0011] 用户设备(140)，用户使用所述用户设备向内容分发网络发送请求；\n[0012] 用于根据来自所述用户的请求访问所述源站的内容分发网络(110)，包括被部署在尽量靠近用户的网络边缘上所述内容分发网络的一个或多个边缘服务节点(120)和被部署在网络质量好的主干网络中的一个或多个中心节点(130)；\n[0013] 其中所述边缘服务节点被配置为：\n[0014] 定期发送探测请求到各个中心节点，每个所述中心节点把当前设备的综合负载信息作为响应返回给所述边缘服务节点；\n[0015] 在接收到所述中心节点的综合负载信息之后，先按所述中心节点的RTT从小到大进行排序，再按照所述中心节点的综合负载信息判断每个所述中心节点的负载情况，从而确定每个所述中心节点的流量调度策略，并更新每个所述中心节点的负载阈值；以及[0016] 在接收到用户发过来的请求之后，根据所述中心节点的所述负载阈值，查询出最终要发送所述请求的所述中心节点的IP并把所述请求转发到相应的中心节点。\n[0017] 根据上述的一种过滤抖动的渐进式流量调度方法和系统，其中：所述步骤S2中：如果实际负载值还未达到机器的负载低水平线(CPU、内存、IO、流量等均处在一个比较低的阈值)，则此中心节点的调度策略是可以继续增加负载，同时按一个相对低的比例阈值进行增加；如果已经超过负载高水平线，则此中心节点的调度策略是下调负载，同时按一个相对高的比例阈值进行下调；如果在负载低水平线和负载高水平线之间，则保持当前的负载值。\n[0018] 根据上述的一种过滤抖动的渐进式流量调度方法和系统，其中：所述步骤S3中：边缘服务节点收到用户发过来的请求后，按照RTT值从小到大的顺序，遍历中心节点，如果当前中心节点的负载还未达到限定的负载值，则选中此中心节点，否则跳过此中心节点，继续往下一个中心节点判断，直到最后一个中心节点，如果还未选中，则说明所有的中心节点已经达到负载上限，如果再接受请求就可能导致某个中心节点超负荷的情况的发生，因此，此请求直接从边缘服务节点回源，不再经过中心节点回源。在另外一个实施例中，为了防止由于流量大幅上升带来的大幅波动将某个中心节点压垮，即使存在负载还未达到限定的负载值的中心节点，也可将此请求直接从边缘服务节点回源，不再经过中心节点回源以避免造成服务质量发生大幅抖动。\n[0019] 如上所述，本申请的过滤抖动的渐进式流量调度方法和系统，具有以下有益效果：\n[0020] (1)按照全局即时流量情况进行调度：参照RTT和各个中心节点具体的负载信息，能更准确的进行流量调度。\n[0021] (2)慢增长及快回落的渐进式流量控制：能让中心节点的流量不会大起大落，因而不会造成服务的大幅抖动。\n附图说明\n[0022] 图1是在其中执行根据本申请的实施例的用于过滤抖动的渐进式流量调度方法的示例系统环境。\n[0023] 图2是根据本申请的实施例的用于过滤抖动的渐进式流量调度方法的流程图。\n[0024] 图3是根据本申请的实施例的流量调度策略流程图。\n具体实施方式\n[0025] 下面结合附图和实施例对本申请作进一步的描述。\n[0026] 本申请的实施例描述一种在CDN环境中用于过滤抖动的渐进式流量调度方法和系统。CDN(内容分发网络)是一种新型网络构建方式，它是为能在传统的IP网发布宽带丰富媒体内容而特别优化的网络覆盖层，以确保内容以一种极为高效的方式为用户的请求提供服务。在CDN中所分发的媒体内容可以包括web对象(例如，文本、图形、URL、脚本)、可下载对象(例如，媒体文件、软件、文档等)、web应用、流媒体(例如，音频和视频内容)等。简单地说，CDN是一个经策略性部署的整体系统，包括分布式存储、负载均衡、网络请求的重定向和内容管理4个要件。而本申请的主要着眼于对CDN技术中的负载均衡进行改进。\n[0027] 首先，在图1中示出了在其中执行根据本申请的实施例的用于过滤抖动的渐进式流量调度方法的示例系统环境100。在所述环境中，首先提供了基于Internet的CDN 110。在所述CDN 110具有中心-边缘层次这种两层的网络结构。在所述网络结构的第一层是一个或多个边缘服务节点120，它们被部署在尽量靠近用户的网络边缘上，而网络结构的第二层则是一个或多个中心节点130，它们被部署在网络质量好的主干网络中，因此，此类型节点访问源站150通常会比较快。需要指出的是所述CDN技术还可以用于其它网络类型中，诸如广域网、局域网等网络中，并不局限于Internet网络。用户通过用户设备140向所述CDN 110发出对数据的请求。其中所述用户设备140可以包括各种计算设备，例如智能手机、个人计算机、服务器、笔记本电脑、PDA等等设备。在所述CDN 110中的边缘服务节点120接收到该请求之后，所述边缘服务节点120根据其存储的与各个中心节点130相关联的RTT值将其从小到大的顺序，随后按照所述排序遍历对应的中心节点130的综合负载信息。如果所述综合负载信息显示当前中心节点的负载还未达到限定的负载值，则选中此中心节点。如果选中了一个中心节点130，则将所述请求转发给该中心节点，由该中心节点进行回源。\n[0028] 在描述了图1的示例环境之后，开始参考图2来描述根据本申请的实施例的用于过滤抖动的渐进式流量调度方法的流程图。\n[0029] 首先，在步骤S1，边缘服务节点定期发送探测请求到各个中心节点，每个中心节点把当前计算设备的综合负载信息作为响应返回给发出请求的边缘服务节点。所述综合负载信息包括反映计算设备资源的使用情况的各种信息，包括但不局限于CPU、内存、I/O、网卡流量的使用率等能反映系统负载情况的信息。所述每个信息作为一个影响计算设备资源的使用情况的因素，都可以具有一个对应的权重，通过综合考虑这些信息来计算出一个值，对这个值进行判断，如果达到事先设定好的高负载值或低负载值，就可以确定所述计算设备已经达到比较高的负载或比较低的负载。在接收到来自所述中心节点的综合负载信息之后，在步骤S2，所述边缘服务节点根据收到的中心节点的综合负载信息，先按每个中心节点的RTT大小以从小到大的顺序对所述中心节点进行排序，然后，再以此顺序按照与每个经排序的中心节点相关联的综合负载信息判断每个中心节点的负载情况，从而得出每个中心节点的流量调度策略。随后，基于所述流量调度策略更新每个中心节点的负载阈值。在完成以上处理之后，在步骤S3，边缘服务节点接收到用户通过用户设备发过来的请求后，根据在步骤S2中更新后的每个中心节点的负载阈值，查询出最终要发送的中心节点的ip，并把这个请求转发到相应的中心节点。具体而言，在所述步骤S3中：边缘服务节点收到用户发过来的请求后，按照每个中心节点的RTT值从小到大的顺序，逐个遍历中心节点，如果当前中心节点的负载还未达到限定的负载水平，则选中此中心节点，否则跳过此中心节点，继续前往下一个中心节点进行判断。一旦，选中一个中心节点，边缘服务节点就查询与该中心节点相关联的ip地址，并将所述请求转发给相应的中心节点以由其执行回源处理。\n[0030] 在另一个实施例中，如果直到遍历到最后一个中心节点时还未选中中心节点，则说明所有的中心节点已经达到负载上限，如果再将用户请求分配给任何一个中心节点都有可能产生例如大幅波动而导致性能的不稳定。因此，所有的中心节点已经都不能胜任回源工作，所以，此请求将直接从边缘服务节点回源，不再经过中心节点回源。\n[0031] 在其它实施例中，为了防止由于流量大幅上升带来的大幅波动将某个中心节点压垮，即使存在负载还未达到限定的负载值的中心节点，也可将此请求直接从边缘服务节点回源，而不是经过中心节点回源以避免造成服务质量发生大幅抖动。\n[0032] 在又一个实施例中，除了边缘服务节点向各个中心节点定期发送探测请求之外，还可以设定一个触发条件来触发所述探测请求的发送。例如在当前这个周期内某个域名访问量达到一定的量(例如接近饱和)，就可能需要马上发送探测请求来调整流量调度策略，以确认当前的路径是否需要变更。\n[0033] 在还有一个实施例中，尽管在先前的示例中描述的是按照每个中心节点的RTT值从小到大的顺序来逐个遍历中心节点，但也可以考虑采用或结合其他网络因素(例如数据掉包率等)来进行选择哪个中心节点的决策。\n[0034] 根据上述方案，通过同时参考中心节点的RTT和综合负载信息，本申请能够按照全局即时流量情况更合理准确地进行流量调度，从而能够提供最优的回源路径。\n[0035] 接下来参考图3来描述根据本申请的实施例的流量调度策略流程图。在图3中，对图2中步骤S2中的流量调度策略进行了如下进一步的说明。在步骤S21，在边缘服务节点接收到中心节点的综合负载信息之后，所述边缘服务节点根据所述综合负载信息计算出该中心节点的实际负载值。在步骤S22，进行如下判断：如果该中心节点的实际负载值小于负载低水平线(步骤S22)，则该中心节点的调度策略为上调(步骤S23)，并且上调的幅度为一个相对低的阈值，以实现在上调负载的过程中不造成服务质量大幅抖动；如果该中心节点的实际负载值大于负载高水平线(步骤S24)，则此中心节点的调度策略为下降(步骤S25)，并且下降的幅度为一个相对高的阈值，以实现快速下降该中心节点的负载，使该中心节点能快速恢复到正常负载水平；如果该中心节点的实际负载值在负载低水平线和负载高水平线之间，则说明该中心节点目前处理合理的负载中，保持这个实际负载值不变(步骤S26)。\n[0036] 下面，将例举一个具体的示例来进一步说明上述流量调度策略的具体实现。需要理解得是，所述示例仅仅是出于说明性目的，而非要将本申请的流量调度策略局限于此。假设，某边缘服务节点X，有两个中心节点A和B与之相关联，用户通过此边缘服务节点访问某个域名www.test.com下的源站的内容，根据慢上升、快下调的原则，把上调策略的阈值设置成10％，下降策略的阈值设置成20％。基于上述设定，结合表1来描述所述流量调度策略的改变过程。\n[0037]\n[0038] 表1边缘服务节点X的负载调度情况\n[0039] 基于上述表1，陈述如下：\n[0040] 1.在某个探测周期N的时候，通过中心节点A、B回源的请求各是50％，并且中心节点A、B的负载都小于负载低水平线(例如80％，所述百分比仅仅是作为示例，其数值可以根据实际需要来设定)，即调度策略为上调；\n[0041] 2.在下个周期N+1的时候，根据边缘服务节点接收到的中心节点的探测数据，由于中心节点A的RTT较小，之前的请求被分配给它，因此通过中心节点A回源的请求变成60％，而通过中心节点B回源的请求变成40％，即把流量慢慢导入最优的中心节点；\n[0042] 3.在此时，另一个边缘服务节点Y往中心节点A转发大量请求，造成中心节点A的负载超过了负载高水平线(例如95％，所述百分比仅仅是作为示例，其数值可以根据实际需要来设定)。同时，这也导致中心节点A的RTT增大到“20”。边缘服务节点X通过探测请求，得知中心节点A已经过载了，因此，它更新中心节点A的调度策略为下调，并把其负载阈值改成\n40％。所以，在N+2周期，通过中心节点A回源的请求会下降20％，变成40％，而通过中心节点B回源的请求由40％上升到50％，同时，有10％的请求是直接回源；\n[0043] 4.在接下来的几个周期内，中心节点A的回源请求会继续下降，直到0％，而中心节点B的回源请求则会慢慢上升，直到100％。在此期间，有部分请求是直接回源(例如先前所述的N+2周期的情况)，这是为了能把流量慢慢导入到中心节点B，避免由于流量大幅上升，把中心节点B给压垮，造成服务质量发生大幅抖动。\n[0044] 根据上述示例，通过使用智能流量调度及慢上升、快下调原则，原本通过中心节点A回源的流量，会慢慢被引导到中心节点B上，在此期间，可以最大限度地通过最优路径进行流量调度。在中心节点A快速恢复服务质量的同时，中心节点B的服务质量也可以保持平稳，不会发生大幅抖动。因此，所述流量调度策略和采用这种策略的来过滤抖动的渐进式流量调度方法充分考虑各个中心节点的综合负载信息和RTT值，将流量最大限度地通过最优路径进行分发，并提前感知全局流量抖动，进行流量控制：RTT最优的中心节点如果负载偏高，则停止递增流量，以防止流量过载；如果流量到达过载线，则将线性削减流量到其他中心节点上。因此，解决了现有CDN技术中的技术难题。\n[0045] 尽管用结构特征和/或方法动作专用的语言描述了本主题，但可以理解，所附权利要求书中定义的主题不必限于上述特征或动作或上述动作的次序。更具体而言，所描述的特征和动作是作为实现权利要求书的示例形式而公开的。\n[0046] 本申请的各实施例可包括或利用专用或通用计算机系统，该专用或通用计算机系统包括诸如举例而言一个或多个处理器和系统存储器的计算机硬件，如以下更详细讨论的。本申请范围内的各实施例还包括用于承载或存储计算机可执行指令和/或数据结构的物理和其它计算机可读介质。这样的计算机可读介质可以是可由通用或专用计算机系统访问的任何可用介质。存储计算机可执行指令和/或数据结构的计算机可读介质是计算机存储介质。承载计算机可执行指令和/或数据结构的计算机可读介质是传输介质。由此，作为示例而非限制，本申请的各实施例可包括至少两种显著不同种类的计算机可读介质：计算机存储介质和传输介质。\n[0047] 存储计算机可执行指令和/或数据结构的计算机存储介质是物理存储介质。物理存储介质包括可记录型存储设备，诸如RAM、ROM、EEPROM、固态驱动器(“SSD”)、闪存、相变存储器(“PCM”)、光盘存储、磁盘存储或其他磁存储设备、或可用于存储计算机可执行指令或数据结构形式的程序代码装置且可由通用或专用计算机系统访问的任何其他物理存储介质。\n[0048] 传输介质可包括可用于携带计算机可执行指令或数据结构形式的程序代码并可由通用或专用计算机系统访问的网络和/或数据链路。“网络”被定义为允许在计算机系统和/或模块和/或其他电子设备之间传输电子数据的一个或多个数据链路。当信息通过网络或另一个通信连接(硬连线、无线、或者硬连线或无线的组合)传输或提供给计算机系统时，该计算机系统将该连接视为传输介质。以上介质的组合也应被包括在计算机可读介质的范围内。\n[0049] 此外，在到达各种计算机系统组件之后，计算机可执行指令或数据结构形式的程序代码可从传输介质自动传输到计算机存储介质(或反之亦然)。例如，通过网络或数据链路接收到的计算机可执行指令或数据结构可被缓存在网络接口模块(例如，“NIC”)内的RAM中，然后最终被传输到计算机系统RAM和/或计算机系统处的较不易失性的计算机存储介质。因而，应当理解，计算机存储介质可被包括在还利用(甚至主要利用)传输介质的计算机系统组件中。\n[0050] 计算机可执行指令例如包括，当在一个或多个处理器处执行时使通用计算机系统、专用计算机系统、或专用处理设备执行某一功能或某组功能的指令和数据。计算机可执行指令可以是例如二进制代码、诸如汇编语言之类的中间格式指令、或甚至源代码。\n[0051] 本领域的技术人员将理解，本申请可以在具有许多类型的计算机系统配置的网络计算环境中实践，这些计算机系统配置包括个人计算机、个式计算机、膝上型计算机、消息处理器、手持式设备、多处理器系统、基于微处理器的或可编程消费电子设备、网络PC、小型计算机、大型计算机、移动电话、PDA、平板、寻呼机、路由器、交换机等等。本申请也可以在通过网络链接(或者通过硬连线数据链路、无线数据链路，或者通过硬连线和无线数据链路的组合)的本地和远程计算机系统两者都执行任务的分布式系统环境中实践。如此，在分布式系统环境中，计算机系统可包括多个组成部分计算机系统。在分布式系统环境中，程序模块可位于本地和远程存储器存储设备两者中。\n[0052] 本领域技术人员还将理解本申请可在云计算环境中实践。云计算环境可以是分布式的，但这不是必须的。在分布时，云计算环境可以国际性地分布在一个组织内，和/或具有跨多个组织拥有的组件。在该描述和下面的权利要求书中，“云计算”被定义为用于允许对可配置计算资源(例如，网络、服务器、存储、应用和服务)的共享池的按需网络访问的模型。\n“云计算”的定义不限于可从这样的模型(在被合适地部署时)中获得的任何其他多个优点。\n[0053] 云计算模型可由各种特性组成，诸如按需自服务、广泛网络访问、资源池、快速灵活性、和所测定的服务等。云计算模型还可以以各种服务模型的形式出现，诸如例如软件即服务(“SaaS”)、平个即服务(“PaaS”)以及基础结构即服务(“IaaS)。”云计算模型还可以使用不同的部署模型来部署，诸如私有云、社区云、公共云、混合云等。\n[0054] 一些实施例，诸如云计算环境，可包括一系统，该系统包括一个或多个主机，每个主机能够运行一个或多个虚拟机。在操作期间，虚拟机模拟可操作的计算系统，支持一个操作系统并且也许还支持一个或多个其他应用。在一些实施例中，每个主机包括管理程序，该管理程序使用从虚拟机的视角抽象出的物理资源来模拟虚拟机的虚拟资源。管理程序还提供各虚拟机之间的适当的隔离。因此，从任何给定的虚拟机的角度来看，管理程序提供该虚拟机正与物理资源对接的错觉，即便该虚拟机仅仅与物理资源的表象(例如，虚拟资源)对接。物理资源的示例包括处理容量、存储器、盘空间、网络带宽、媒体驱动器等等。\n[0055] 本申请可具体化为其它具体形式而不背离其精神或本质特征。所描述的实施例在所有方面都应被认为仅是说明性而非限制性的。因此，本发明的范围由所附权利要求书而非前述描述指示。落入权利要求书的等效方案的含义和范围内的所有改变都被权利要求书的范围所涵盖。