技术领域
[0001] 本申请涉及网络服务技术领域，特别是涉及一种基于业务特性感知的确定性网络服务方法及相关装置。
相关背景技术
[0002] 近年来，智慧交通、环境监控以及电网巡检等新兴业务迅速发展，对网络的需求不断增长，传统地面网络难以满足广域覆盖和高性能的需求。新兴业务场景对网络提出了更高的要求，包括更高的数据传输效率、更低的延迟以及更广的覆盖范围。除此之外，不同的行业应用对网络有着不同的需求。例如，电力网络需要高可靠和低时延的网络来满足电力系统对实时性和稳定性的需求。相比之下，远程船舶则需要广覆盖的网络来保证在海洋环境条件下可靠且连续的网络支持。
[0003] 目前提供服务的网络主要由地面蜂窝通信系统和卫星通信系统组成，这些系统技术和市场等原因独立发展，协同保障业务网络服务质量难以实现。造成上述原因主要有两点：首先是对网络的实时状态获取难度大。不同厂商虽然都提出不同的网络监测协议，但各协议难以兼容，增加对整体网络性能感知的难度大。同时传统路由协议通常以最短路径为主要选择标准，在地面固定网络中表现优异，但难以适用于天空地异构网络。这些协议通常基于静态的网络状态信息进行路由选择，无法及时适应动态变化的网络环境，缺乏灵活性，难以满足不同应用对服务质量（QoS）的多样化需求。因此，网络设计和优化必须与具体行业应用相结合，以满足各自独特的需求。
[0004] 当前的网络感知实现主要依赖于网络设备制造商自行提供的网络监测方案和协议。这些方案和协议针对特定设备，能够从不同维度获取网络性能数据。例如，由InMon公司创立的sFlow是一种基于流量采样的网络监控技术，能够实时监控高性能网络中的大量流量。它通过在交换机和路由器上采集数据包的样本，提供对网络流量的全面视图。sFlow的优点在于其高效性和低开销，适用于监控大规模、高速率的网络环境，常用于流量分析、安全监控和网络性能优化。由Cisco开发的NetFlow是一种流量监控技术，用于详细记录网络中的流量信息。NetFlow通过捕获并分析流记录，提供有关流量来源、目的地、协议和应用等详细信息，在网络流量监控、性能分析、带宽规划和安全检测等方面有广泛应用。NetFlow的详细数据记录能力使其成为许多网络管理和分析工具的基础。华为开发的NetStream是一种类似于NetFlow的流量监控技术，用于收集和分析网络流量数据，提供有关流量模式和行为的详细信息。华为的NetStream支持精细的流量监控和分析，有助于网络性能优化、流量工程和安全管理，在功能和应用上与NetFlow相似，但更贴合华为设备和解决方案的特点。
[0005] 为满足业务对网络的个性化需求，在同构网络中进行了大量研究。刘思放为优化电力通信网的传输效率和可靠性，提出了基于业务优先级的信用量整形传输机制。该机制通过分配信用量确保高优先级业务的传输优先权，同时合理调度低优先级业务。具体而言，信用量代表了业务在网络中的传输权重，高优先级业务获得更多信用量，在资源紧张时仍能得到保障。机制引入流量整形技术，通过控制流量速率避免网络过载。传输过程中，网络节点根据信用量进行队列管理，优先处理高信用量业务，确保其传输的及时性和可靠性。在卫星网络中，杜嘉楠将三种业务分成三种QoS需求类型，即高时延需求（A类）、高带宽需求（B类）、低时延带宽需求（C类），提出基于业务调度的星间路由算法，A、B类优先级高，采用轨道内优先转发的低复杂度路由策略，C类业务采用基于链路状态的星间路由策略，结合后拥塞率、丢包率随业务流量数增长程度比常见算法有所放缓。
[0006] 当前针对协同利用星地网络资源进行业务传输优化也进行了部分研究。Ma提出了一种基于计算依赖路由的低延迟分布式协同计算策略，用于卫星‑地面综合网络（STIN）。该策略通过一个名为定向扩散增强任务调度的算法，实现了在考虑计算和通信资源的情况下，分布式地进行计算和传输。刘金琳根据STIN的动态特性和链路状态的复杂变化，提出采用深度强化学习方法，通过智能体与环境的交互学习，动态调整路由策略以优化网络性能。在算法设计中，智能体通过观察包含链路质量的状态空间，将下一跳的备选传输节点作为动作空间，逐步学习到能够自适应感知链路状态并动态调整的路由策略。智能体利用历史数据学习规律，并根据环境的反馈进行策略调整，从而优化端到端时延，避开干扰和拥塞。
[0007] 然而，现有技术存在以下缺点。
[0008] 1.网络实时状态监控困难：传统网络中不同管理机构与设备厂商都提出了各自网网络性能监测技术，但各方案难以兼容。除此之外，上述方案网络感知实时性较差，同时难以保证监测精度，获取网络状态的效果以及质量难以保证。
[0009] 2.动态资源管理效率低下：工业互联网等网络应用场景复杂多变，对网络资源的管理提出了动态调度和高效利用的要求。现有技术在实时感知网络状态、用户需求变化和动态调度资源方面尚未达到理想的水平。
[0010] 3.个性化网络服务支持不足：工业互联网的通信设备种类多样，对网络服务的个性化需求高。现有网络技术在为不同的工业应用提供定制化解决方案方面，仍然面临诸多挑战。
[0011] 因此，如何设计一种能够满足工业互联网等特定业务对网络低时延、高可靠、广覆盖以及大数据率的个性化需求的网络服务机制，成为本领域亟需解决的技术问题。
具体实施方式
[0044] 下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
[0045] 为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。
[0046] 基于上述背景，本申请提出一种基于业务特性感知的确定性网络服务机制，旨在满足工业互联网等特定业务对网络低时延、高可靠、广覆盖以及大数据率的个性化需求。通过对一体化网络的多维资源实时感知、统一资源协同管控适配和高可靠自适应路由技术，实现为特定需求业务提供符合其需求的网络传输服务。
[0047] 缩略语和关键术语定义如表1所示。
[0048] 表1 缩略语和关键术语定义
[0049] 在一个示例性的实施例中，如图1所示，提供了一种基于业务特性感知的确定性网络服务方法，该方法包括以下步骤S1至步骤S5。
[0050] S1：获取网络的全局状态信息；所述全局状态信息包括：丢包率、延迟、抖动以及可用带宽。
[0051] S2：当新的数据包需要在网络中传输时，确定新的数据包的业务类型和对应的业务需求。
[0052] S3：根据所述新的数据包的业务类型和对应的业务需求，进行资源动态匹配。
[0053] S4当当前网络具备足够的能力支持新的数据包的业务需求时，根据所述网络的全局状态信息，计算得到最优传输路径。
[0054] S5：根据所述新的数据包的业务类型和所述最优传输路径，将所述新的数据包分配到相应的转发队列。
[0055] 自动驾驶和远程控制等系统正在全球范围内广泛部署和应用，这些系统工作极度依赖于稳定且高效的网络服务。因此，根据业务需求进行网络优化对保障此类系统的实时性与稳定性至关重要。本申请提出一种基于网络感知与业务感知相结合的新方法来优化网络服务质量，如图2所示。深度网络感知用于实时感知网络中的状态变化，业务精确感知用于识别所承载业务流的类型，资源动态调度以及路由优化机制则从不同层级保证网络的高效服务。
[0056] 在整个过程中，深度网络感知模块通过构建探测数据包，并在全网范围内进行转发，以获取网络的全局状态信息。随后，全局状态信息经过处理并存储在数据库中。当新的数据包需要在网络中传输时，业务精确感知模块通过端口解析数据包，识别其承载的业务类型，并基于业务类型确定其特定需求。在数据包传输启动时，资源动态调度模块首先进行资源的动态匹配。如果当前网络具备足够的能力支持该业务的传输需求，路由优化机制将利用深度网络感知模块提供的实时网络状态数据，从全网范围内计算出满足业务需求的端到端传输路径，并最终选择最优路径进行数据传输。在数据包沿指定路径通过交换机转发时，交换机会根据业务类型将数据包分配到相应的转发队列，以确保优先级处理，保障高效传输。
[0057] 1、深度网络感知。
[0058] 由于不同网络对于网络资源的监控手段不同，为了简化感知的复杂性，以主动测量的方式对网络进行感知。具体来说，通过向网络中主动发送探测数据包，并根据探测数据包受网络影响而发生的特性变化来分析网络行为。采集方式如图3所示，采集流程图如图4所示。
[0059] 步骤1：普通数据报文达到系统的第一个交换节点时，状态获取模块通过在交换机上设置的采样方式匹配并镜像出该报文，根据遥测任务的需要对该报文的载荷字段前插入探测头部，将探测头部所指定的遥测信息封装成元数据MD插入到探测头部之后。
[0060] 步骤2：报文转发到中间节点时，设备匹配探测头部后插入MD。
[0061] 步骤3：报文转发到带内网络遥测系统最后一跳时，交换设备匹配探测头部插入本设备MD，此后提取探测数据包中全部MD，并在外部封装一个IP头形成遥测数据包，外层IP为遥测服务器地址，这样遥测数据包便转发到遥测服务器。遥测服务器解析遥测数据包内的遥测信息，上报给上层遥测应用程序。
[0062] 网络节点对探测数据包的处理需要通过对数据包包头的可编程实现，但部分已投入使用的设备不支持可编程，需要通用数据包格式来兼容传统现网设备，兼容包头如图5所示。
[0063] 当探测包经过的网络中存在节点不支持可编程时，进行网络状态感知的步骤如图6所示。
[0064] 步骤1：普通数据报文达到的第一个交换节点。
[0065] 步骤2：判断该节点是否支持可编程。
[0066] 步骤3：如果支持可编程，则利用图4中的步骤1所示流程进行处理。
[0067] 步骤4：若不支持，则进行传统IP转发，利用IP地址进行转发。
[0068] 步骤5：报文转发到中间节点时，重复步骤2，3，4。
[0069] 步骤6：当到达最后一跳交换机时，判断设备是否支持可编程。
[0070] 步骤7：若支持，插入所需状态信息，封装IP头。
[0071] 步骤8：若不支持，直接封装IP头。
[0072] 步骤9：遥测服务器解析遥测报文内的遥测信息，上报给上层遥测应用程序。
[0073] 在一个示例性的实施例中，在步骤S1中，具体包括。
[0074] S11：构建探测数据包。
[0075] S12：将所述探测数据包在全网范围内进行转发，得到网络的全局状态信息。
[0076] 在步骤S12中，具体包括。
[0077] S121：当探测数据包达到第一交换机时，判断所述第一交换机是否支持可编程，得到第一判断结果。
[0078] S122：若所述第一判断结果为是，则将探测数据包进行镜像，得到镜像原始报文。
[0079] S123：对所述镜像原始报文插入所需网络信息，并转发至下一跳交换机；所述所需网络信息为探测头部所指定的遥测信息封装成的元数据。
[0080] S124：当所述下一跳交换机匹配探测头部后，插入所述所需网络信息，并判断是否到达最后一跳交换机，得到第二判断结果。
[0081] S125：若所述第二判断结果为否，则返回“转发至下一跳交换机”步骤。
[0082] S126：若所述第二判断结果为是，则判断最后一跳交换机是否支持可编程，得到第三判断结果。
[0083] S127：若所述第三判断结果为是，则所述最后一跳交换机匹配探测头部后，插入所述所需网络信息，并封装一个IP头；所述IP为遥测服务器地址。
[0084] S128：若所述第三判断结果为否，则直接封装IP头。
[0085] S129：若所述第一判断结果为否，则采用传统IP转发，并返回“转发至下一跳交换机”步骤。
[0086] S1210：根据所述IP头解析遥测信息，得到网络的全局状态信息，并上报给上层遥测应用程序。
[0087] 2、业务精确感知。
[0088] 针对当前远程医疗、智能工厂以及个性化流媒体等新型业务，本申请整体将网络需求划分为三类：低时延、大带宽以及尽最大努力交付。以工业物联网控制为例，其中涉及工业控制信息低时延传输、实时监控数据大带宽传输以及工业互联网管理信息传输。其中当远程控制中心对特定设备下发控制指令，使用502端口的Modbus TCP向可编程逻辑控制器下发指令；实时监控数据传输实现控制中心管理员对现场的实时画面监控，通过与摄像机录像机的554端口建立RSTP流以获得实时画面；工业互联网管理信息传输主要实现控制中心对特定控制设备状态的访问，使用80端口的HTTP协议，对应的网络传输需求如表2所示。
[0089] 表2 网络需求映射关系
[0090] 通过P4的包头解析，可以识别传输层中的端口字段数值，按照上述映射关系了解数据包传输的业务种类及其网络传输需求。
[0091] 在一个示例性的实施例中，在步骤S2中，具体包括。
[0092] S21：根据端口解析新的数据包，得到新的数据包的业务类型。
[0093] S22：根据所述新的数据包的业务类型，确定对应的特定需求。
[0094] 3、资源动态调度。
[0095] 针对当前异构网络进行统一资源管控复杂，难以支撑复杂业务对资源的协同高效适配与应用。针对上述问题，本申请设计了一种实现对不同行业对特定业务的网络需求，设计能够根据业务重要性指标的调度机制。整体将架构能力资源划分为四层，第一层为管理层，维护一个处理队列，有具体业务到达后会临时入队；第二层为协调层，其中包含多个协调器，可以根据业务类型协调不同的子执行器，根据不同业务对不同资源的敏感性不同调用不同的子执行器；第三层为计划层，根据协调层的调度策略调度资源层资源；第四层为资源层，管理异构网络资源，如图7所示。
[0096] 架构内部实际构建了一个生产者消费者模型，将执行器和业务解耦，并不直接关联，从而可以根据业务类型选择不同的执行策略，有三种执行策略：（1）缓冲执行，缓冲执行用来执行对时间不敏感的业务，这类场景任务量巨大，并不需要瞬时的完成，而是关注如何使用有限的资源，尽可能在单位时间内处理更多的任务，也就是吞吐量优先的问题；（2）立即执行，这类业务往往需要尽快执行，优先级较高需要立即执行；（3）拒绝执行，拒绝执行是架构的保护策略。拒绝策略也可根据业务不同分为以下三种：（1）直接抛弃，（2）丢弃队列最前面的业务，然后重复提交被拒绝业务，（3）由调用者去执行本业务。
[0097] 在系统资源分配方面，将业务优先级 表示为多个业务特征的函数，包括业务的紧急程度 、资源需求 和预期执行时间 。优先级的计算公式如下。
[0098] 。
[0099] 其中， 表示业务 的紧急程度，紧急程度越高，意味着业务需要更快地得到处理。因而 对优先级有正面影响。资源需求 采用了 的形式，这意味着资源需求越大的业务，其优先级贡献越小。这种处理方式避免了资源消耗过大的业务占用系统中有限的资源，从而在有限的网络资源下保证整体资源的合理分配。此外，预期执行时间 使用了 的形式，表示预期执行时间越长，其对优先级的正面贡献越小，避免长周期业务阻塞系统，确保紧急短期任务能够优先处理。系数 、和 分别表示各个因素的权重，用以灵活调整不同业务属性对优先级的影响。这些系数可以根据具体的业务场景进行调节，以确保优先级计算的灵活性和适应性。
[0100] 在计算出业务优先级 后，下一步是根据优先级和资源需求量进行资源的分配。本申请提出了一个资源分配函数 ，该函数用于描述协调器如何根据业务的优先级和实际资源需求 为子执行器 分配资源。
[0101] 。
[0102] 在该公式中，分子 表示业务 根据其优先级调整后的实际资源需求总量。优先级越高的业务，其资源需求被放大，使其能够在分配过程中获得更多的资源。这确保了高优先级业务能够及时得到满足，满足系统对紧急业务的响应要求。分母
表示协调器管理的所有子执行器的资源需求总和，其中 是协调器 所
承担的全部业务集合， 与 为 中某一业务的优先级和实际资源需求。这一设计保证了在整体资源池中，各个业务按需求分配资源，确保资源分配的公平性和系统资源的高效利用。
[0103] 在前述的资源分配模型中，通过计算每个业务的优先级 并结合实际资源需求实现了资源的动态分配。而资源分配的效率是整个系统性能的关键，资源利用率作为衡量这一效率的重要指标，可以通过实际使用资源量与总可用资源量的比率来定义。资源利用率 的计算公式如下。
[0104] 。
[0105] 其中， 表示子执行器 实际使用的资源量，而 是系统的总资源量。通过资源利用率，可以评估系统中资源分配的合理性，确保资源在不同业务间分配的高效性。
[0106] 为了避免资源过度占用导致系统性能下降，设定队列长度限制和业务拒绝策略。设定阈值 ，当队列长度 达到 时，采取拒绝策略 ，防止任务积压过多。当业务执行需要进行等待时，需要计算业务执行等待时间 ，该值可以通过队列中任务的数量和系统的处理能力来估算。业务 的等待时间可以根据在其之前的所有任务的处理时间进行累积计算。
[0107] 。
[0108] 上述公式中，为业务 的之前某一需要处理的业务， 表示业务 的处理时间， 为业务的优先级。处理时间 则取决于系统分配给业务的资源量 ，可以通过函数 动态调整。
[0109] 。
[0110] 该函数 反映了资源量对任务执行时间的影响，资源分配越多，任务处理的速度越快，从而缩短 。
[0111] 在算法实现方面，整体处理流程如图8所示。
[0112] 步骤1：当业务到达时，首先判断执行池是否为空，若为空，则判断业务队列是否已满，否则进行任务类型划分。
[0113] 步骤2：如果业务队列已满，则采取拒绝策略，否则该业务入队。
[0114] 步骤3：协调器进行业务类型划分，若划分失败，则抛出处理，否则进行下一步骤。
[0115] 步骤4：将具体业务分发给子执行器，并判断对应子执行器是否已满。
[0116] 步骤5：若子执行器已满，则进行等待，若等待超出预定时间，则进行抛出处理。
[0117] 步骤6：若子执行器未满，则将具体业务分配给子执行器，等待完成后释放资源。
[0118] 对于网络传输的数据包，通过分析数据包头的字段来对不同的业务进行分类，从而实现对业务的精准感知，帮助明确不同业务对网络的特定需求。在此基础上，通过对网络节点内部的队列调度测量与业务需求数据包传输需求进行匹配，从网络设备方面实现对特定业务传输的优化。图9展示了P4交换机中的数据包控制的过程，其中4条队列对应三个不同的优先级，描述如下。
[0119] A队列：服务低时延传输业务转发。
[0120] B队列：服务实时大带宽传输业务转发。
[0121] C队列：用于提供管理信息传输业务转发。
[0122] D队列：速度受限，用于未被分类的业务进行转发。
[0123] 数据包具体调度的算法如下所示，在该算法中不同的优先级队列是相互独立的，高优先级队列能够优先接收服务，只有在高优先级队列中不存在数据时，才会进行低优先级队列的处理，否则进行等待，整体处理流程如图10。
[0124] 在一个示例性的实施例中，在步骤S3中，具体包括。
[0125] S31：根据所述新的数据包的业务类型和对应的业务需求，判断执行器池是否为空，得到第四判断结果。
[0126] S32：若所述第四判断结果为是，则判断业务队列是否已满，得到第五判断结果。
[0127] S33：若所述第五判断结果为是，则采取拒绝策略；所述拒绝策略包括：直接抛弃、丢弃队列最前面的业务，然后重复提交被拒绝业务以及由调用者去执行本业务。
[0128] S34：若所述第五判断结果为否，则将新的数据包入列。
[0129] S35：若所述第四判断结果为否，则进行业务类型划分。
[0130] S36：当业务类型划分完成后，将类型划分完成的业务分发给对应子执行器，并判断所述对应子执行器是否已满，得到第六判断结果。
[0131] S37：若所述第六判断结果为是，则进行等待，若等待超出预定时间，则进行抛出处理。
[0132] S38：若所述第六判断结果为否，则将类型划分完成的业务分配给对应子执行器，等待完成后释放资源，实现资源动态匹配。
[0133] 4、基于状态的优化路由机制。
[0134] 在异构网络路由方面，主要是通过网络资源感知数据以及业务感知数据，通过运行在控制器中的算法进行全网路由规划，保证数据端到端传输路径优化。在应用服务模块中，主要是应用核心业务模块中提供的功能，实现对工业互联网中的业务需求实施感知、网络需求精准匹配以及远程控制指令的高可靠低时延传输任务。
[0135] 首先，控制器根据网络拓扑以及网络状态感知信息，建立链路状态数据库，包括每条链路的两端点、链路的时延、最大容量、已用带宽和剩余带宽。具体来说，对于每条链路，记录以下信息 ，其中 和 分别表示链路的起点和终点，是链路的时延， 是链路的最大容量， 是链路的已用带宽， 是链路的剩余
带宽。
[0136] 假设业务流 对链路的时延要求为 ，对带宽的要求为 。控制器需要计算满足其时延需求的链路集合，定义满足 的链路集合为 ，即
。然后，判断是否存在满足时延需求的链路集合。如果
为空，则返回无路径错误。如果 不为空，则继续判断该业务对带宽是否有需求。若对带宽无需求，则选择跳数最短路径，否则计算满足带宽需求的链路集合。定义满足带宽需求的链路集合为 ，即 。进一步地，判断是否存在满足带宽需求的
链路集合。如果 为空，则返回无路径错误。如果 不为空，则选择满足时延最小的链路为最优链路，完成选路任务。
[0137] 在优化模型中，定义变量 表示如果选择链路 ，则 ，否则 。优化目标是最小化路径的时延总和，即 。约束条件包括每条选定的链路必须满足带宽需求，即： 。
[0138] 其中每条选定的链路必须满足时延需求，即： 。
[0139] 上述内容保证路径的连续性，即从源节点 到目标节点 的路径上所有节点都是连通的。整体处理流程如图11所示。
[0140] 步骤1：控制器根据网络拓扑以及全局状态信息，建立链路状态数据库，包括每条链路的两端点、链路的时延、最大容量、已用带宽和剩余带宽。
[0141] 步骤2：通过截取业务流，获取其端口信息以明确该业务对特定网络指标的时延需求。
[0142] 步骤3：控制器计算满足其时延需求的链路集合。
[0143] 步骤4：判断是否时延需求的链路集合是否为空。
[0144] 步骤5：若为空，则返回无路径Error，否则继续判断该业务对带宽是否需求。
[0145] 步骤6：若对带宽无需求，则安排跳数最短路径，否则计算满足带宽链路集合。
[0146] 步骤7：若集合为空，则返回无路径Error，则选择时延最小链路为最优链路。
[0147] 步骤8：完成选路任务。
[0148] 作为一种可选的实施方式，在步骤S4中，具体包括。
[0149] S41：根据网络拓扑以及网络的全局状态信息，建立链路状态数据库；所述链路状态数据库包括：每条链路的两端点、链路的时延、最大容量、已用带宽和剩余带宽。
[0150] S42：通过端口感知新的数据包的业务需求。
[0151] S43：根据所述链路状态数据库和所述新的数据包的业务需求，计算满足时延需求的链路集合。
[0152] S44：判断所述满足时延需求的链路集合是否为空，得到第七判断结果。
[0153] S45：若所述第七判断结果为是，则返回无路径Error。
[0154] S46：若所述第七判断结果为否，则判断对带宽是否需求，得到第八判断结果。
[0155] S47：若所述第八判断结果为否，则将跳数最小链路确定为最优传输路径。
[0156] S48：若所述第八判断结果为是，则判断是否有满足带宽需求的路径，得到第九判断结果。
[0157] S49：若所述第九判断结果为否，则返回无路径Error。
[0158] S410：若所述第九判断结果为是，则将时延最小链路确定为最优传输路径。
[0159] 本申请提出了一种基于业务特性感知的确定性网络服务方法，与现有网络感知与服务提供方法相比具有如下优势。
[0160] 1.向网络中主动发送探测数据包，保证探测数据包与业务流路径相同，并根据探测数据包受一体化网络影响而发生的特性变化来灵活分析网络行为。指标包含丢包率、延迟、抖动以及可用带宽等网络状态信息。
[0161] 2.任务需求驱动的调度机制通过识别任务重要性指标，结合节点资源和业务请求进行调度，从而满足行业对特定任务的网络需求，提高业务差异化服务水平。
[0162] 3.基于对行业网络需求感知和网络时延等信号测量信息，通过确定性路由等机制，确保各业务端到端的时延和其他性能指标，从而满足工业控制等特定网络传输业务的确定性传输质量要求。
[0163] 基于同样的发明构思，本申请实施例还提供了一种用于实现上述所涉及的基于业务特性感知的确定性网络服务装置。该装置所提供的解决问题的实现方案与上述方法中所记载的实现方案相似，故下面所提供的一个或多个基于业务特性感知的确定性网络服务装置实施例中的具体限定可以参见上文中对于基于业务特性感知的确定性网络服务方法的限定，在此不再赘述。
[0164] 在一个示例性的实施例中，如图12所示，提供了一种基于业务特性感知的确定性网络服务装置包括。
[0165] 信息获取模块M1，用于获取网络的全局状态信息；所述全局状态信息包括：丢包率、延迟、抖动以及可用带宽。
[0166] 业务类型和业务需求确定模块M2，用于当新的数据包需要在网络中传输时，确定新的数据包的业务类型和对应的业务需求。
[0167] 资源动态匹配模块M3，用于根据所述新的数据包的业务类型和对应的业务需求，进行资源动态匹配。
[0168] 最优传输路径确定模块M4，用于当当前网络具备足够的能力支持新的数据包的业务需求时，根据所述网络的全局状态信息，计算得到最优传输路径。
[0169] 分配模块M5，用于根据所述新的数据包的业务类型和所述最优传输路径，将所述新的数据包分配到相应的转发队列。
[0170] 本申请能够在可编程交换设备区域，使网络状态随业务流数据包同路径传输，保证网络状态获取的实时性以及精准性。而且设计兼容传统网络设备的网络实时感知方案，保护现有投资支持网络感知。同时能够对网络节点内部的队列调度测量与数据包传输需求进行匹配，从网络设备方面实现对特点业务传输的优化。另外多维异构网络路由优化保证了最佳的传输路径和资源分配，满足特定网络使用场景对时延与带宽的要求。
[0171] 在一示例性的实施例中，提供了一种计算机设备，该计算机设备可以是服务器或者终端，其内部结构图可以如图13所示。该计算机设备包括处理器、存储器、输入/输出接口(Input/Output，简称I/O）和通信接口。其中，处理器、存储器和输入/输出接口通过系统总线连接，通信接口通过输入/输出接口连接到系统总线。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质和内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储网络的全局状态信息。该计算机设备的输入/输出接口用于处理器与外部设备之间交换信息。该计算机设备的通信接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种基于业务特性感知的确定性网络服务方法。
[0172] 本领域技术人员可以理解，图13中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
[0173] 在一个示例性的实施例中，还提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现上述各方法实施例。
[0174] 在一个示例性的实施例中，提供了一种计算机可读存储介质，存储有计算机程序，该计算机程序被处理器执行时实现上述各方法实施例。
[0175] 在一个示例性的实施例中，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述各方法实施例。
[0176] 以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
[0177] 本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。
