qos框架_应用程序的QoS：运行时的资源管理框架

最新推荐文章于 2023-04-12 00:03:10 发布

cunfu6353

最新推荐文章于 2023-04-12 00:03:10 发布

阅读量516

点赞数

文章标签：网络队列大数据 python java

原文链接：https://www.infoq.com/articles/QoS-for-Applications/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

版权

qos框架

介绍

为了（监督）控制和服务质量（QoS）的目的，已经进行了许多尝试将某种资源管理方式（特别是基于预留的方式）引入企业Java应用程序。不幸的是，大多数都没有取得很大的成功，部分原因是它们通常需要完全重写运行时库和应用程序库。另外，这种提出的解决方案不能有效地解决如何将资源消耗活动与当前的执行线程（被视为主要使用者）区分开的问题。同样，缺少服务分类（使用类别）和细粒度资源使用情况分析，以及如何将此类提议的资源管理框架集成到更广泛的QoS解决方案中，而QoS解决方案可以感知应用程序（上下文，活动）和成本（仪表）。

此类方法无法实现吸引力的主要原因是，它们实际上忽略了网络领域进行资源管理的多年经验，而如今，网络领域已成为该领域的主要采用者和创新者。

本文提出了这样一种观点，即应用程序应被视为更像基础网络层，并采用许多流量工程和服务质量优化技术。它提供了从一个域到另一个域的映射指南，然后说明了如何在一个解决方案中实现该指南，该解决方案为使用Java，Scala，JRuby / Ruby和Jython / Python以及所有其他JVM语言开发的应用程序提供了生产QoS解决方案，并且最终其他运行时/平台包括Microsoft的.NET / Azure。

网络的QoS

首先让我们从QoS的标准定义开始：

“网络为一组数据包/数据流提供更好或“特殊”服务而损害其他数据包/数据流的能力”。

更正式地说，服务质量（QoS）是网络在传输数据流时要满足的一组服务级别要求。此合同承诺基于诸如带宽（吞吐量），延迟，延迟变化（抖动），数据包丢失和可用性之类的质量度量标准，这些度量标准是通过为满足该要求而进行的控制（分类，调度，策略/整形和排队）间接管理的。其他指标。

从资源的角度来看，QoS是指以不相等的方式对网络资源进行划分，从而对某些资源提供了更多的资源，而对其他资源则提供了较少的资源。

交通特征

在网络环境中，QoS着眼于四个流量特征：

带宽：每秒可以传输的位数。
延迟：从首次发送数据包到到达目的地之间的时间间隔。
抖动：以均匀速率发送的数据包到达率或引入的延迟的变化。
数据包丢失：由于多种原因，所有路由器都会丢失，丢弃数据包，包括拥塞，损坏，拒绝，衰落，错误和故障。

交通规划

在网络层上实现QoS包含3个基本步骤：

根据服务水平确定流量及其要求
将流量分为服务等级类别
为每种服务级别定义QoS策略，这些策略会导致前面提到的流量特性发生某些变化。

流量QoS服务分类

QoS服务分类涉及通过检查数据包头中的字段来区分一个数据包与另一个数据包。在某些情况下，此分类是根据流量模式和资源消耗行为自动且自适应地执行的。

QoS服务分类对于提供间接级别和对服务级别策略以及此类策略使用的流量控制机制的映射非常重要。

流量QoS拥塞管理

通常使用队列和调度程序来管理拥塞，该队列和调度程序基于与分组或流相关联的服务分类在队列和调度程序之间划分流量。当存在拥塞和/或需要保护，保留和管理资源容量时，通常会进行排队和调度。

队列管理和队列调度建立在传统的先进先出（FIFO）队列的基础上，通过在具有不同缓冲区大小，队列长度和传输速率的不同队列之间进行排队和调度，不会提供服务差异。

流量QoS监管和整形

流量管理控制点的策略基于流量合同，该合同定义可以发送多少数据。当管制组件进行的测量超过定义的阈值时，将丢弃数据包。

整形类似于管制，但不是丢弃数据包，而是尝试使数据速率符合服务类的流量合同。整形通过平滑数据传输的波峰和波谷来工作，以优化或保证性能和带宽。

管制和整形都可以测量数据发送的速率。当发生溢出时，流量速率不符合要求，在这种情况下，策略器将丢弃数据包，而整形器将延迟数据包的发送。监管丢弃并调整发送延迟。两者都有责任确保数据速率不超过合同中定义的指定阈值。

应用服务质量

现在，让我们在应用程序运行时的上下文中重写用于网络的QoS的标准定义：

“运行时为一组调用/线程提供更好或“特殊”服务的能力，从而损害了其他调用/线程。”

通话特征

在应用程序运行时的上下文中，QoS着眼于以下请求/调用特征：

吞吐量：每秒可以预期收到有效和完整响应的请求/呼叫数。
响应时间：发送（或接收）请求/呼叫到接收（或发送）响应之间的时间。
响应时间变化：请求/呼叫的响应时间变化。在具有延迟组件（例如线程调度，垃圾回收和并发控制）的非确定性运行时中，总会有变化。
异常和错误：在运行时中可能会发生故障，例如由于争用以及本地和远程资源上繁重的工作负载并发导致的超时。

呼叫QoS规划

现在可以将应用程序运行时的QoS计划步骤声明为：

根据服务级别确定请求/呼叫模式及其要求。
将请求/呼叫模式划分并关联到服务级别类别中。
为每种服务级别定义QoS策略，这些策略会导致前面提到的请求/呼叫特性发生某些变化。

呼叫QoS服务分类

对于QoS服务分类，通常通过检查与请求/调用关联的执行上下文来完成区分。通常在请求/调用入口点-“请求”调用堆栈或方法的顶部完成此操作。

如何通过与线程相关联的执行上下文来区分一个线程与另一个线程。这种情况的示例包括：

线程组和线程
HTTP请求和/或用户/会话
执行代码和/或呼叫者链

应用程序运行时中的QoS服务分类将服务类与线程关联。可以多次执行此关联，以删除先前的类别并在执行过程中添加其他服务类别，并且与典型的联网环境不同，线程可以在其处理的特定执行点与一个或多个服务关联。

呼叫QoS竞争管理

使用并发和控制结构（例如信号量/锁存/锁）来管理争用（拥塞），这些结构通常由争用期间由驻留线程组成的隐式或显式队列支持。排队和调度仅在存在争用和/或需要保护，保留和管理资源容量时才起作用。后备队列可以是公平的也可以是不公平的，两者都可以支持插入。在每个受管方法调用或执行点，当前或最适用的服务分类将用于定位（选择）在进行调用处理之前需要访问哪些信号量并获取许可。对于基于预留的队列，还需要确定所需的许可数量。

呼叫QoS监管和整形

警务基于请求/呼叫合同，该合同定义可以发送多少请求/呼叫。当管制组件进行的测量超出定义的阈值时，将通过异常或错误代码拒绝请求/调用。

整形类似于管制，但不是拒绝请求/呼叫，而是尝试使用某种形式的延迟机制（例如等待和停车）使请求/呼叫速率与请求/呼叫合同一致。

管制和整形都可以测量请求/呼叫的速率。当发生溢出时，请求/呼叫速率不符合要求，策略器将拒绝（引发异常或返回错误代码）请求/呼叫，而整形器将延迟/挂起/驻留请求/呼叫的处理。两者都有责任确保请求/呼叫率不超过合同中定义的指定阈值。两者通常都称为请求/呼叫限制或请求/呼叫速率限制。

在执行策略和成形时，基于桶的类比，将泄漏桶算法应用于仪表，该桶的底部有一个Kong，通过该桶，其中包含的所有水将以恒定的速率泄漏出去，直到或除非它是空的。可以间歇地添加水，即以突发方式添加水，但是如果一次添加太多，或者以太高的平均速度添加水，水将超过水桶的容量，水桶会溢出。

网络和运行时之间的映射

下表是一个有用的表，提供了网络组件和概念到应用程序运行时组件和概念的有用但有些松散的映射。

qos_mapping_table

应用实施的QoS

应用程序是网络的概念是JXInsight / OpenCore的“ Apps QoS”技术的基础。 QoS位于基于OpenCore基于活动的计量和成本计算运行时之上，从而将应用程序代码库中的所有计量代码执行点（方法，动态语言调用站点）建模为可以执行服务（重新）分类的虚拟网络流量管理设备。，（重新）优先级，资源保留，沿每个（预测的）代码执行路径以及跨线程和保留通道的流量/吞吐量速率限制。

JXInsight / OpenCore允许将QoS透明地注入到应用程序中，而无需更改任何代码。仪表代理将首次调用放入方法或调用站点的入口和出口点。表示的插入开始和结束的命名活动的调用在OpenCore中称为探针。当计量引擎创建探针的基础实现时，可以通过已安装的探针提供程序添加基本计量支持之外的其他功能，这些提供程序可以看起来像装饰器。 QoS是一种这样的功能，可以通过一些系统属性来安装，而无需更改代理执行的工具。

instrumentation

JXInsight / OpenCore的QoS实现主要基于资源预留和池。 QoS“资源”是使用以下系统属性模式定义的：

jxinsight.server.probes.qos.resources=${resource},${resource},..

对于定义的每个资源，可以定义容量。

jxinsight.server.probes.qos.resource.${resource}.capacity=...

QoS资源可以看作是全局命名的信号量，其容量为允许的数量。

QoS服务是使用以下系统属性模式定义的：

jxinsight.server.probes.qos.services=${service},${service},..

然后，将QoS“服务”与探针（即方法）或部分探针名称（包，类）相关联。

jxinsight.server.probes.qos.service.${service}.name.groups=...

默认情况下，服务将与每个全局资源相关联，尽管可以定义哪些资源适用并创建特定于服务类的新本地资源。

jxinsight.server.probes.qos.service.#{service}.resources=...

可以在预留期间将QoS“队列”定义为前端资源。

jxinsight.server.probes.qos.resource.{resource}.queue.fifo.enabled=true 
jxinsight.server.probes.qos.resource.${resource}.queue.queue.priority.enabled=true

甚至可以使用“通道”定义多个队列，这些通道可以为特定服务类别的资源设置额外的容量限制，或者在启用优先级排队时提升或降低所需的预留请求的优先级。

jxinsight.server.probes.qos.resource.${resource}.lanes=${lane},${lane},... 
jxinsight.server.probes.qos.resource.${resource}.lane.${lane}.capacity=
jxinsight.server.probes.qos.resource.${resource}.lane.${lane}.priority.level.promotion=0..7
jxinsight.server.probes.qos.resource.${resource}.lane.${lane}.priority.level.demotion=0..7

当服务进行保留时，它会根据为每个通道定义的“较低”和“较高”保留阈值映射到通道。

jxinsight.server.probes.qos.resource.${resource}.lane.${lane}.lower=

jxinsight.server.probes.qos.resource.${resource}.lane.${lane}.upper=

QoS整形在JXInsight / OpenCore中被称为速率限制，同时还为资源和预留通道提供了支持，并带有“限制”和“间隔”的规范。

jxinsight.server.probes.qos.resource.${resource}.rate.limit=
jxinsight.server.probes.qos.resource.${resource}.rate.interval=
jxinsight.server.probes.qos.resource.${resource}.lane.${lane}.rate.limit=
jxinsight.server.probes.qos.resource.${resource}.lane.${lane}.rate.interval=

qos_laneslanes

当输入方法（或开始探测）时，直到分组到达时，在网络层中，直到现在定义的QoS模型的要素才起作用。首先，计量运行时检查QoS服务是否已与该方法（或探针）相关联。如果映射了服务，则针对与该服务关联的每个QoS资源进行预留。保留可以在最终到达资源之前通过成形器，通道和队列。一旦所有保留都完成，则该方法的执行继续。该方法完成后，将在进入阶段保留的容量返回给每个资源。

服务如何确定在预留阶段从每个资源请求多少容量是由资源本身的“预留”属性定义的，然后由也已经对该资源进行预留的呼叫者已经预留的容量量来进行调整。可能的值包括“ one”，“ meter”，“ inc”和“ lease”。

jxinsight.server.probes.qos.resource.${resource}.reservation=

对于“一个”，仅从资源池中保留一个容量（或许可）单位。 “ inc”保留方法与“ one”相似，因为仅保留一个单元，但不同之处在于它不针对其调用方已保留的单元进行调整。

“计量器”和“租赁”都要求计量器与资源相关联，可以将其指定如下：

jxinsight.server.probes.qos.resource.${resource}.meter=

对于“计量”，资源使用方法（或探针）的计量配置文件来确定容量单位。如果资源是基于时钟的仪表，则执行速度较慢的方法将从资源池中请求更多容量。对于“租赁”，资源使用从某个外部调用者点开始到请求点为止的计量使用情况作为要保留的容量单位。

应用就是网络

当今的应用程序运行时的运行与网络非常相似，在网络中，数据包是呼叫，而路由器是方法和呼叫站点。

call.network

在很大程度上受当今的开发人员运动推动的工程弹性和对应用程序运行时的自我调节中，开发人员应寻求将经过验证的服务质量技术应用于其请求处理管道，路径和流。

call.qos.network

进一步阅读

云和企业中应用程序的QoS

关于作者

William Louth是JINSPIRED BV的CTO，并且是其创新的应用程序性能管理和资源计量解决方案-JXInsight / OpenCore的产品架构师。 JXInsight / OpenCore是第一个基于低延迟智能活动的成本核算（ABC / M）解决方案，为企业，网格和云计算软件和服务提供统一的模型和运行时解决方案，以管理性能，成本，容量和服务质量。他之前曾在Inprise / Borland从事JavaEE / CORBA技术方面的工作，并在性能管理，软件运行时可视化，应用程序部署建模和联合CMDB设计领域为许多领先的JVM和IT管理供应商提供了技术咨询顾问。 William在电信行业度过了他的早期工程学生涯，他在AT＆T开发了GSM计费引擎软件以及用于欧洲交通的最低成本路由（LCR）系统。

翻译自: https://www.infoq.com/articles/QoS-for-Applications/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

qos框架

cunfu6353

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
qos框架_应用程序的QoS：运行时的资源管理框架

qos框架介绍为了（监督）控制和服务质量（QoS）的目的，已经进行了许多尝试将某种资源管理方式（特别是基于预留的方式）引入企业Java应用程序。不幸的是，大多数都没有取得很大的成功，部分原因是它们通常需要完全重写运行时库和应用程序库。另外，这种提出的解决方案不能有效地解决如何将资源消耗活动与当前的执行线程（被视为主要使用者）区分开的问题。同样，缺少服务分类（使用类别）和细粒度资源使...
复制链接

扫一扫