一种基于服务质量指标的自愈系统.pdf

中国科技信息 2024 年第 2 期CHINA SCIENCE AND TECHNOLOGY INFORMATION Jan.2024-92-三星推荐随着云计算的快速发展和微服务架构的日益普及，Kubernetes 已 成 为 容 器 化 应 用 的 主 要 编 排 平 台。Kubernetes 提供了强大的应用编排功能，用于在动态环境中管理和扩展应用程序。然而在这样的环境下如何确保微服务的可靠性和性能仍然是一大挑战。容器的弹性扩缩容是 Kubernetes 提供的一项关键能力，可以根据应用程序需求自动调整资源分配。但是其自带的弹性扩缩容策略无法适应用户请求量突增或复杂的工作负载场景，使得微服务的服务质量容易出现变差甚至不可用的问题。为了解决这一问题，本文旨在探索和实现一种基于服务质量指标的动态阈值弹性扩缩容策略，通过一种响应及时高效的策略用于 Kubernetes 集群中实现自动扩缩容器。传统故障自愈方案存在着基础数据维护复杂、传递性差的问题，基于此，提出了基于 Kubernetes 环境开发适用于微服务环境下的自动化处理方案。该方案可以结合现有的自动化故障处理方案和 Kubernetes 的优势，利用监控系统及时发现故障并触发报警，在预先配置的故障处理逻辑规则下自动进行故障处理。可以提高故障处理的效率和准确性，有效降低人力成本和误操作风险，并保证整个微服务系统的稳定性和可靠性。研究现状目前主流的 Kubernetes 弹性伸缩策略主要是水平和垂直弹性伸缩策略两种。水平弹性伸缩策略（Horizontal Pod Autoscaler，HPA）通过监测容器集群中各实例资源使用情况（如 CPU 利用率或内存利用率）自动增加或减少集群中资源数量（如：容器个数）来实现弹性扩缩容。当资源利用率高于预设的阈值时，HPA 会自动增加 Pod 数量，反之当资源利用率低于预设的阈值时，HPA 会自动缩减Pod数量，以减少资源的使用。垂直弹性伸缩策略（Vertical Pod Autoscaling，VPA）是对集群中容器自身的配置资源进行调整（增加或减少容器 CPU 核数或内存大小）实现的弹性扩缩容。VPA 通过监测容器 Pod 自身的资源配置（如 CPU 核数或内存大小）自动调整容器的资源配置以提供更合适的资源使用情况。VPA 可以根据容器的实际资源需求进行调整，避免资源浪费或资源不足的情况，通过动态调整容器的资源配置优化微服务应用的性能并提高资源利用效率。行业曲线开放度创新度生态度互交度持续度可替代度影响力可实现度行业关联度真实度一种基于服务质量指标的自愈系统高 栋 刘春磊 翁剑英 贵福胜 冯一帆 王泽琪高 栋 刘春磊 翁剑英 贵福胜 冯一帆 王泽琪中航信移动科技有限公司-93-CHINA SCIENCE AND TECHNOLOGY INFORMATION Jan.2024中国科技信息 2024 年第 2 期三星推荐目前商用的云平台中利用横向扩容的方式实现了简单的弹性扩缩容。AWS（Amazon Web Services）通过监控 CPU 资源使用率，一旦使用率超过预先设置的阈值时就对集群的容器进行扩容，当使用率低于阈值时对集群容器进行缩容操作，需要用户提前设置上下阈值指标。青云提供了多种可选的资源监控指标，包括 CPU 使用率、内存使用率等，采取的措施同样是在监控指标达到阈值时进行扩缩容操作，具有一定的滞后性。两者在面临突发激增的流量时存在响应延迟及扩缩容不足而引起服务质量变差甚至不可用的问题。另外设置正确的阈值不是一件容易的工作，需要对自身的服务负载有深入的了解，使得 Kubernetes 难以判定在何时对容器集群进行扩缩容，也难以确定需要扩容多少数量才能满足不断变化的负载。对于部署在容器集群上的微服务应用，其资源负载通常是不断变动且充满各种不确定性。当用户访问量突然激增时，微服务的性能随之下降，例如常见的Web 应用响应时间变长甚至会导致请求超时错误的情况。显然，要想解决上述问题，需要一套能够基于服务质量指标的自愈系统。自愈系统设计传统的自动扩缩容方案存在一些缺点，特别是在微服务架构下的服务链路故障处理方面。面向资源管理的故障自愈系统需要持续更新的基础数据，在没有有效维护的情况下会变得复杂且低效。为了解决这些问题，提出了基于Kubernetes 环境设计适用于微服务环境下的自动化处理的自愈系统方案。该方案可以结合现有的自动化故障处理方案和 Kubernetes 的优势，利用监控系统发现服务的质量监控指标变化趋势，在预先配置的故障处理逻辑规则下自动进行故障处理。该方案可以降低人力成本和误操作风险，提高故障处理的效率，并有效保证整个微服务系统的稳定性和可靠性。该自愈系统主要由数据指标采集层、自愈层及基于Kubernetes 封装的 PaaS 层三部分构成。其中数据指标采集层负责采集容器服务的状态指标数据，并将采集到的服务质量数据存储至 Prometheus 时序数据库。自愈层轮询Prometheus 获取异常应用信息并通过自愈插件做出决策调用 PaaS 层，最终实现水平扩缩容、删除故障容器 Pod 等操作结果。数据指标采集层传统的基于阈值的扩缩容策略通常采用单一的系统级性能指标，例如 CPU 使用率、内存使用率等。上述指标不足以准确适应应用自动扩缩容需求。本文使用微服务应用的服务质量指标对应用系统实际运行状态进行量化，以实现对应用服务质量的整体评估。本文重点关注以下几个指标：QPS：在一段时间内的服务器每秒所处理的查询量。平均响应时间（AVG）：在一段时间内所有请求响应时间的平均值，平均响应时间越小，服务效率越高。失败率：在一段时间内失败次数与总请求量的比值，失败率越高说明服务可靠性越低。传统的监控数据采集通常由专门的监控系统完成，本文依据实际工作场景中的监控数据采集需求，开发数据采集模块，依赖于 Prometheus 时序数据库完成数据采集和存储，整个流程大致可以分为以下几个步骤：微服务应用的调用链开始时，应用的 Pod 从服务注册中心（如 ZooKeeper）获取服务提供者的列表，包括服务提供应用。服务调用时长计时器启动，应用开始捕获异常。在服务调用完成后，服务调用时长计时器计算本次服务调用的时长，并结束异常捕获，将结果放入缓存中。开发数据采集模块，与监控系统集成，实现对微服务调用链的监控数据采集和处理。选择 Prometheus 时序数据库作为存储，定期从缓存中获取数据，并将其格式化存储到数据库中。自愈层自愈层参考了 Open-Falcon 系统的架构，按功能拆分为数据接入模块、决策模块、回调模块、API，整体架构如图 1 所示。为了应对不同的业务需求和系统环境，提供一个灵活、高效和自适应的系统扩缩容解决方案，以满足不同业务场景下的性能和可用性需求。提供了三种高度灵活和可配置的自动扩缩容策略。这些策略都是基于 Prometheus 的实时监控数据来进行决策的，以确保系统性能和稳定性。基于QPS（每秒请求率）的自动扩缩容策略适用于用户请求量突增或需要处理大量并发请求的场景。基于平均响应时间的自动扩缩容策略适用于高实时性要求、高响应压力、应用调用关系复杂的场景。基于失败率的自动扩缩容策略适用于高稳定性要求、应用调用关系复杂的场景。1.基于 QPS 的自动扩缩容策略该策略基于压测过程中获取的应用极限 QPS 值以及Prometheus计算得到的动态QPS基线值得到扩缩容阈值，分段动态获取应用 QPS 扩缩容标准。对于一段时间内频繁超出标准阈值或逼近极限阈值的应用进行扩容处理，反之对于一段时间内明显低于标准阈值的应用进行缩容处理。该策图 1 自愈层架构图中国科技信息 2024 年第 2 期CHINA SCIENCE AND TECHNOLOGY INFORMATION Jan.2024-94-三星推荐略适用于用户请求量突增、需要同时处理大量并发请求的场景。可以根据业务流量的波动和增长进行灵活的扩容或缩容，以提高系统的吞吐量和并发处理能力。2.基于平均响应时间的自动扩缩容策略该策略基于 Prometheus 计算得到的应用自身、应用调用等动态平均响应时间基线值得出扩缩容阈值，与当前应用一段时间内平均响应时间做对比。对于一段时间内频繁超出标准阈值的应用进行扩容处理。反之对于一段时间内明显低于标准阈值的应用进行缩容处理。该策略适用于高实时性要求、高响应压力、应用调用关系复杂的场景。确保系统的响应能力与负载需求相匹配，具有较强的灵活性。3.基于失败率的自动扩缩容策略该策略基于 Prometheus 计算得到的应用自身、应用调用等动态失败率基线值得出扩缩容阈值，与当前应用一段时间内失败率做对比，对于一段时间内频繁超出标准阈值的应用进行扩容处理，反之对于一段时间内明显低于标准阈值的应用进行缩容处理。该策略适用于高稳定性要求、应用调用关系复杂的场景。可通过自动缩容等摘除问题容器 Pod，提高系统稳定性，具有较强的灵活性。PaaS 层在 PaaS 层，回调方法被固定为向 PaaS 的 API 发送请求，触发回调操作会记录需要变更的应用 Pod 以及操作方式，后续的处理动作将由 PaaS 执行。容器 PaaS 平台接收 SelfHealing 故障自愈模块的请求，并完成自愈操作。PaaS 通过界面化的形式向 Kubernetes 的 API 服务器发送请求，以控制集群资源。通过暴露 HTTP API 的方式，PaaS提供多种处理Pod异常的方法。当某个方法被调用时，会进行一些逻辑转换，将其转换为 api-server 定义的请求格式。api-server 通过与 worker 节点中的 kubelet 组件通信，由 kubelet 执行对 Pod 的实际操作，例如删除某个Pod 或对某个 Deployment 进行扩容等来解决问题。实验与分析基于自愈系统的研究设计与实现，对基于服务质量指标的自愈系统方案进行测试，验证其可行性及有效性，及时有效地根据服务的质量指标进行微服务实例的弹性扩缩容。实验准备定义服务质量指标实验定义以下三个服务质量指标：（1）QPSQPS 衡量的是每秒钟系统能够处理的查询或请求的数量。这是一个衡量系统吞吐量的重要指标，通常用于衡量Web 服务器或数据库服务器的性能。（2）平均响应时间平均响应时间衡量的是系统响应一个请求所需要的平均时间。它包括从接收请求、处理请求到返回响应的完整周期。平均响应时间是用户体验的重要指标，因为它直接影响到用户对系统性能的感知。（3）失败率失败率指的是在一定时间内请求处理失败的比率。失败可以是因为系统错误、超时或任何未能成功处理请求的情况。失败率高意味着用户遇到问题的频率高，这直接影响到系统的可靠性。设定指标阈值为每个服务质量指标设定两组阈值：一组用于定义服务的正常运行状态，另一组用于触发自愈动作，特别是服务实例的弹性伸缩。对于正常运行阈值。评估系统在正常运行条件下的历史性能数据，确定 QPS、平均响应时间和失败率的正常范围。考虑业务需求和用户期望，确定可以接受的最大响应时间和最低的 QPS。根据系统的容错能力，决定失败率的可接受最大值。对于触发伸缩动作的阈值。根据系统的性能目标和服务水平协议（SLA），确定服务性能下降的临界点。通过压力测试来确定服务在何种性能指标下开始出现性能下降或不稳定。同样，确定服务指标低于某一水平时可以安全缩容的阈值。在设定阈值时，考虑到可能发生的意外峰值，为系统留出一定的冗余和安全缓冲。实验环境本文基于 Go 环境设计搭建自愈平台，使用三台服务器作为运行 Web 应用的硬件环境。该平台基于 Go 环境开发，数据库端使用 MySQL 关系型数据库，服务部署在 Linux 服务器上，使用Nginx作为反向代理服务器。服务器配置如表1。表 1 服务器配置项目配置CPU8C内存16G磁盘60G操作系统RedHat Enterprise Linux Server release 7.5 Go1.16准备测试工具和脚本准备测试工具和脚本，这些工具和脚本将用于生成负载并模拟用户行为，以便测试基于服务质量指标的自愈系统方案。首先定义需要模拟的用户行为和测试场景，确定哪些服务质量指标将在每个场景下被测量。使用负载生成工具，如JMeter，Gatling，Locust 等的脚本语言编写测试脚本。确保脚本可以模拟真实用户的行为，包括但不限于登录、数据检索、数据提交等操作。参数化脚本以便可以动态输入数据，如用户凭证、查询参数等，确保可以通过参数调整请求频率和负载大小。根据测试目标创建负载模型，定义负载的大小、持续时间和变化模式。考虑使用“斜坡上升”模式逐渐增加负载，以及突然增加负载的“峰值”测试。与此同时，确保负载生成工具能够与监控工具集成，以实时监控服务质量指标。配置监控工具收集测试期间的性能数据。弹性伸缩功能测试使用测试工具逐步增加用户负载，监控服务质量指标的变化。当服务质量指标达到伸缩阈值时，验证自愈系统能否-95-CHINA SCIENCE AND TECHNOLOGY INFORMATION Jan.2024中国科技信息 2024 年第 2 期三星推荐结语本文探讨了一种基于服务质量指标的自愈方案，旨在解决请求量突增情况下无法及时快速扩缩容容器数量的问题。通过引入多种服务质量指标，本方案可以克服人为设置固定阈值容器扩缩容死板的问题，同时提高系统的灵活性和可用性。方案采用动态阈值的方法，根据实时的服务质量指标来设置容器扩缩容的阈值，更好地适应请求量突增的情况，及时调整容器数量，提高系统的响应速度和吞吐量。采用插件化的决策逻辑模式，系统可以支持用户自定义的扩缩容策略，每个策略对应独立的插件。用户可以根据自己的需求和业务特点来选择和配置不同的扩缩容策略，提高系统的灵活性和可扩展性。采用负载均衡机制，通过在多个容器之间分配请求负载，避免单个容器过载的情况，提高了系统的稳定性和可用性。实验结果表明，本方案能够及时快速地响应请求量的变化，有效地扩缩容容器数量，提高系统的性能和可用性。正确地触发伸缩动作。记录伸缩动作发生的时间点和系统对负载变化的响应时间。在高负载下运行系统，验证系统在高负载下的表现和自愈能力。实验结果分析本文设定微服务应用 A 选取 3 个服务指标并记录每个测试阶段的服务质量指标数据，收集自愈扩缩容动作，分析扩缩容动作前后服务质量指标的变化。经计算得到服务 A 的 QPS 基线值为 800，平稳运行状态下应用的 Pod 数量为 2 个。一段时间内扩缩容情况随QPS 值变化情况如表 2 所示。经计算得到服务 A 的平均相应时间基线值为 200ms，平稳运行状态下应用的 Pod 数量为 2 个。一段时间内扩缩容情况随平均响应时间变化情况如表 3 所示。经计算得到服务 A 的失败率基线值为 3%，平稳运行状态下应用的 Pod 数量为 2 个。一段时间内扩缩容情况随失败率变化情况如表 4 所示。表 2 微服务应用 QPS 的扩缩容测试结果时间Pod 数量3 分钟连续 QPS 值备注01：244909.6，876.13，939.44连续 3 分钟超过基线值，进行扩容02：164939.44，918.2，926.7冷却时间内，不进行扩容02：368804.92，845.69，823.17超出冷却时间，继续扩容03：214382.78，362.71，362.71符合正常范围，进行缩容03：342372.18，462.51，368.24符合正常范围，进行缩容表 3 微服务应用平均响应时间扩缩容测试结果时间Pod 数量5 分钟连续平均响应时间备注07：484187.45ms，200.4ms，5 604.21ms，5 927.3ms，5 468.7ms五分钟内四次超过基线，且最后三分钟连续超过基线，进行扩容07：5245 468.7ms，5 834.57ms，5 725.4ms，5 932.25ms，5 534.92ms冷却时间内，不进行扩容08：5725 216.3ms，177.3ms，198，3ms，184.93ms，181，52ms符合正常范围，进行缩容表 4 微服务应用失败率扩缩容测试结果时间Pod 数量3 分钟连续失败率备注15：2643.24%，15.2%，16.7%失败率超过基线，进行扩容15：36411.2%，14.5%，13.8%冷却时间内，不进行扩容15：5621.2%，0%，0%符合正常范围，进行缩容