服务器负载测试： DevOps 实践中的必备要素 (服务器负载测试方法)

文章编号：36458 / 分类：行业资讯 / 更新时间：2024-12-13 04:37:15 / 浏览：次

在 DevOps 实践中，服务器负载测试已成为确保应用程序在生产环境中正常运行的不可或缺的组成部分。通过模拟大量并发用户和工作负载，负载测试可以帮助我们识别应用程序的性能瓶颈、容量限制和错误处理能力。

负载测试方法

有多种方法可以执行服务器负载测试。最常见的包括：

基于代码的负载测试

使用代码库中包含的测试脚本执行负载测试。这种方法需要开发人员编写脚本，这可能会很耗时。但是，它提供了对测试执行的完全控制。

云负载测试

使用云平台（例如 Amazon Web Services (AWS) 或 Microsoft Azure）提供的负载测试服务执行负载测试。这些服务通常提供易于使用的界面和预配置的测试脚本，使负载测试变得更容易。

第三方负载测试工具

使用专门用于负载测试的第三方工具（例如 JMeter 或 LoadRunner）执行负载测试。这些工具通常提供高级功能，例如可视化结果和与其他应用程序的集成。

选择负载测试方法

选择负载测试方法取决于应用程序的复杂性、所需的可定制性以及预算约束等因素。

负载测试的步骤

服务器负载测试通常遵循以下步骤：

规划和设计：确定测试的范围、目标和指标。
创建测试脚本：编写或获取用于模拟用户工作负载的测试脚本。
配置负载测试工具：

什么是DevOps

什么是DevOps？

DevOps 是一套实践、工具和文化理念，可以实现软件开发团队和 IT 团队之间的流程自动化和集成。它强调团队赋能、跨团队沟通和协作以及技术自动化。

DevOps 运动始于 2007 年左右，当时软件开发和 IT 运营社区开始担忧传统的软件开发模式。在此模式下，编写代码的开发人员与部署和支持代码的运营人员会独立工作。 DevOps 这一术语由“开发”和“运营”两个词构成，它反映了将这些领域整合为一个持续流程的过程。

DevOps 如何运作？

DevOps 团队包括开发人员和 IT 运营人员，他们在整个产品生命周期中进行协作，以提高软件部署的速度和质量。这是一种全新的工作方式，也是一种文化转型，对团队及其工作的组织具有重大影响。

在 DevOps 模式下，开发和运营团队不再是“孤立”的。有时，这两个团队会合并为一个团队，合并后工程师会参与整个应用生命周期中的工作（从开发和测试到部署和运营），并具备多学科的技能。

DevOps 团队使用工具实现流程自动化，并加速流程，这有助于提高可靠性。 DevOps 工具链可帮助团队处理重要的 DevOps 基础事项，包括持续集成、持续交付、自动化和协作。

DevOps 的价值有时也会应用于开发团队以外的团队。当安全团队采用 DevOps 方法时，安全性则成为开发过程中一个活跃的组成部分。这就是所谓的 DevSecOps。

DevOps 生命周期

由于 DevOps 的连续性，从业人员使用无限循环来展示 DevOps 生命周期各个阶段之间的相互关系。尽管看似是按顺序进行的，但此循环实际表示需要在整个生命周期进行持续协作和迭代改进。

DevOps 生命周期由六个阶段组成，它们分别代表开发（循环的左半部分）和运营（循环的右半部分）所需的流程、功能和工具。团队会在每个阶段进行协作和沟通，以保持一致性、速度和质量。

规划

DevOps 团队应采用敏捷开发实践来提高速度和质量。敏捷开发是一种用于项目管理和软件开发的迭代方法，可帮助团队将工作分解成更小的部分，从而提供增量价值。

构建

Git 是一个免费的开源版本控制系统。 Git 可为分支、合并和重写存储库历史记录提供出色的支持，而这已为开发构建流程带来了众多极具创新且功能强大的工作流和工具。

持续集成和交付

CI/CD可让团队频繁且可预测地发布高品质产品，其范围涵盖从源代码存储库到使用自动化工作流的生产环节。团队可以频繁地合并代码变更、部署功能标记以及集成端到端测试。

监控和警报

快速识别并解决影响产品正常运行时间、速度和功能的事务。自动通知您团队有关变更、高风险操作或故障的信息，以便保持服务的运行。

运维

管理面向客户的端到端 IT 服务交付。这包括设计、实施、配置、部署和维护支持组织服务的所有 IT 基础架构过程中涉及的实践。

持续反馈

DevOps 团队应对每个版本进行评估，并生成报告以改进未来版本。通过收集持续反馈，团队可以改进其流程，并采纳客户反馈以改进下一个版本。

DevOps 工具

DevOps 工具可应对 DevOps 生命周期的关键阶段。它们通过帮助改进协作、减少上下文切换、引入自动化以及实现可观察性和监控功能来支持 DevOps 实践。

DevOps 工具链通常遵循两种方法：一体化或开放式工具链。一体化工具链提供完整的解决方案，通常不会与其他第三方工具集成。开放式工具链则允许使用不同工具进行自定义。这两种方法各有优缺点。

DevOps 有哪些优势？

有“2020 年 DevOps 趋势调查”表明，99％的调查对象表示 DevOps 对他们的组织产生了积极影响。 DevOps 的优势包括更快且更轻松的发布、团队效率、更高的安全性、更高品质的产品，以及更高的团队和客户满意度。

速度

更频繁地实践 DevOps 发布可交付成果的团队具有更高的品质和稳定性。事实上，DORA 2019 年 DevOps 状况报告发现，精英团队的部署频率和速度分别比表现不佳的团队高出 208 倍和 106 倍。持续交付使得团队可以使用自动化工具来构建、测试和交付软件。

改进协作

DevOps 的基础是开发人员和运营团队之间的协作文化，他们会分担责任，协调工作。此举可以提高团队的效率，并省去工作交接和编写专为其运行环境而设计的代码的时间。

快速部署

通过提高发布的频率和速度，DevOps 团队可以快速地改进产品。快速发布新功能和修复缺陷有助于获得竞争优势。

质量和可靠性

持续集成和持续交付等实践可确保变更正常运行且安全无误，从而提高软件产品的质量。监控则有助于团队实时了解性能。

安全性

通过将安全性集成到持续集成、持续交付和持续部署管道中，DevSecOps 成为开发过程中一个活跃的组成部分。通过将主动安全审计和安全测试集成到敏捷开发和 DevOps 工作流中，可将安全性植入产品内。

采用 DevOps 会面临哪些挑战？

原有的习惯很难改变。深陷孤立工作方式的团队可能会难以应对，甚至抗拒彻底改变团队结构以采用 DevOps 实践。某些团队可能会错误地认为有了新工具就足以采用 DevOps。但是，DevOps 是人员、工具和文化的结合。 DevOps 团队的每一个人都必须了解整个价值流，从构思、开发到最终用户体验。它要求打破孤岛，以便在整个产品生命周期中进行协作。

Devops 不是任何一个个人的工作，而是每个人的工作。

从传统的基础架构转向使用基础架构即代码 (IaC) 和微服务可以加快开发和创新速度，但增加的运营工作量可能极具挑战性。最好为自动化、配置管理和持续交付实践奠定坚实的基础，以帮助减负。

过度依赖工具会使团队偏离 DevOps 的必要基础：团队和组织结构。一旦建立了结构，就应该建立流程和团队，然后确定工具。

如何采用 DevOps？

首先，采用 DevOps 需要致力于评估且可能更改或删除组织当前所用的所有团队、工具或流程。这表示需要构建必要的基础架构，以便团队能够自主构建、部署和管理其产品，而不必过分依赖于外部团队。

DevOps 文化

DevOps 文化是指团队采用新工作方式（包括加强合作和沟通）的环境。这是人员、流程和工具的协调一致，以实现更加统一的客户导向服务。多学科团队负责产品的整个生命周期。

持续学习

在 DevOps 方面表现良好的组织鼓励进行实验和一定程度的冒险。在这些组织中，跳出固有思维模式是常态，而失败则被理解为学习和进步的自然组成部分。

敏捷

敏捷开发方法在软件行业中非常受欢迎，因为它们赋予了团队内在的灵活性、出色的有序性以及响应变化的能力。 DevOps 是一种文化转型，可促进软件构建和维护人员之间的协作。搭配使用敏捷开发和 DevOps 时，可提高效率和可靠性。

DevOps 实践

持续集成

持续集成是将代码更改自动集成到软件项目中的实践。它允许开发人员频繁地将代码更改合并到执行构建和测试的中央存储库中。这有助于 DevOps 团队更快速地修复缺陷、提高软件质量以及缩短验证和发布新软件更新所需的时间。

持续交付

持续交付通过自动将代码更改部署到测试/生产环境中来扩展持续集成。它会沿着持续交付管道推进。而在此管道内，自动化构建、测试和部署会被编排为一个发布工作流。

情境意识

对于组织中的每个成员来说，能够访问他们需要的数据以尽可能高效和快速地完成他们的工作可谓至关重要。团队成员需收到部署管道中的故障警报（无论是系统性故障还是由于测试失败引起的故障），并及时收到在生产中所运行应用的运行状况和性能的最新信息。指标、日志、跟踪、监控和警报都是团队了解其工作进展所需的重要反馈来源。

自动化

自动化是其中一个最重要的 DevOps 实践，因为它能让团队更快速地完成高品质软件的开发和部署流程。利用自动化，将代码变更推送到源代码存储库的一个简单操作便可触发构建、测试和部署流程，从而大大减少这些步骤所花的时间。

基础架构即代码

无论您的组织是拥有本地数据中心，还是完全托管在云中，能快速、一致地调配、配置和管理基础架构是成功采用 DevOps 的关键。基础架构即代码 (IaC) 不仅仅是编写基础架构配置脚本，它还将基础架构定义视为实际代码：使用源控制、代码审查、测试等。

微服务

微服务是一种架构技术。在此技术中，应用被构建为一系列可以相互独立部署和运行的小型服务。每个服务都有其自己的流程，并通过接口与其他服务通信。这种关注点分离和剥离的独立功能支持 DevOps 实践，例如：持续交付和持续集成。

监控

DevOps 团队监控从规划、开发、集成和测试、部署到运营的整个开发生命周期。如此一来，团队就能迅速、自动地对客户体验中的任何降级做出响应。更重要的是，它允许团队“左移”至开发的早期阶段，并最大程度地减少具有破坏性的生产变更。

开始使用 DevOps

开始使用 DevOps 的最简方法就是识别小型价值流（例如：小型支持应用或服务），然后开始尝试一些 DevOps 实践。与软件开发一样，与一小群利益相关者一起转换单个数据流比尝试在组织内一次性过渡至全新的工作方式要容易得多。

开发自动化运维架构六要素

运维自动化是我们所渴望获得的，但是我们在一味强调自动化能力时，却忽略了影响自动化落地的一个关键因素。那便是跟运维朝夕相处，让人又爱又恨的业务架构。要点一：架构独立任何架构的产生都是为了满足特定的业务诉求，如果我们在满足业务要求的同时，能够兼顾运维对架构管理的非功能性要求。那么我们有理由认为这样的架构是对运维友好的。站在运维的角度，所诉求的架构独立包含四个方面：独立部署，独立测试，组件化和技术解耦。独立部署指的是一份源代码，可以按照便于运维的管理要求去部署、升级、伸缩等，可通过配置来区分地域分布。服务间相互调用通过接口请求实现，部署独立性也是运维独立性的前提。独立测试运维能够通过一些便捷的测试用例或者工具，验证该业务架构或服务的可用性。具备该能力的业务架构或服务让运维具备了独立上线的能力，而不需要每次发布或变更都需要开发或测试人员的参与。组件规范指的是在同一个公司内对相关的技术能有很好的框架支持，从而避免不同的开发团队使用不同的技术栈或者组件，造成公司内部的技术架构失控。这种做法能够限制运维对象的无序增加，让运维对生产环境始终保持着掌控。同时也能够让运维保持更多的精力投入，来围绕着标准组件做更多的效率与质量的建设工作。技术解耦指的是降低服务和服务之间相互依赖的关系，也包含了降低代码对配置文件的依赖。这也是实现微服务的基础，实现独立部署、独立测试、组件化的基础。要点二：部署友好DevOps 中有大量的篇幅讲述持续交付的技术实践，希望从端到端打通开发、测试、运维的所有技术环节，以实现快速部署和交付价值的目标。可见，部署是运维日常工作很重要的组成部分，是属于计划内的工作，重复度高，必须提升效率。实现高效可靠的部署能力，要做好全局规划，以保证部署以及运营阶段的全方位运维掌控。有五个纬度的内容是与部署友好相关的：CMDB配置在每次部署操作前，运维需要清晰的掌握该应用与架构、与业务的关系，为了更好的全局理解和评估工作量和潜在风险。在织云自动化运维平台中，我们习惯于将业务关系、集群管理、运营状态、重要级别、架构层等配置信息作为运维的管理对象纳管于CMDB配置管理数据库中。这种管理办法的好处很明显，集中存储运维对象的配置信息，对日后涉及的运维操作、监控和告警等自动化能力建设，将提供大量的配置数据支撑和决策辅助的功效。环境配置在运维标准化程度不高的企业中，阻碍部署交付效率的原罪之一便是环境配置，这也是容器化技术主要希望解决的运维痛点之一。腾讯的运维实践中，对开发、测试、生产三大主要环境的标准化管理，通过枚举纳管与环境相关的资源集合与运维操作，结合自动初始化工具以实现标准环境管理的落地。依赖管理解决应用软件对库、运营环境等依赖关系的管理。在织云实践经验中，我们利用包管理，将依赖的库文件或环境的配置，通过整体打包和前后置执行脚本的方案，解决应用软件在不同环境部署的难题。业界还有更轻量的容器化交付方法，也是不错的选择。部署方式持续交付原则提到要打造可靠可重复的交付流水线，对应用软件的部署操作，我们也强烈按此目标来规划。业界有很多案例可以参考，如Docker的Build、Ship、Run，如织云的通过配置描述、标准化流程的一键部署等等。发布自测发布自测包含两部分：应用的轻量级测试；发布/变更内容的校对。建设这两种能力以应对不同的运维场景需求，如在增量发布时，使用发布内容的校对能力，运维人员可快速的获取变更文件md5，或对相关的进程和端口的配置信息进行检查比对，确保每次发布变更的可靠。同理，轻量级测试则是满足发布时对服务可用性检测的需求，此步骤可以检测服务的连通性，也可以跑些主干的测试用例。灰度上线在《日常运维三十六计》中有这么一句话：对不可逆的删除或修改操作，尽量延迟或慢速执行。这便是灰度的思想，无论是从用户、时间、服务器等纬度的灰度上线，都是希望尽量降低上线操作的风险，业务架构支持灰度发布的能力，让应用部署过程的风险降低，对运维更友好。要点三：可运维性运维脑海中最理想的微服务架构，首当其冲的肯定是可运维性强的那类。不具可运维性的应用或架构，对运维团队带来的不仅仅是黑锅，还有对他们职业发展的深深的伤害，因为维护一个没有可运维性的架构，简直就是在浪费运维人员的生命。可运维性按操作规范和管理规范可以被归纳为以下七点：配置管理在微服务架构管理中，我们提议将应用的二进制文件与配置分离管理，以便于实现独立部署的目的。被分离出来的应用配置，有三种管理办法：文件模式；配置项模式；分布式配置中心模式。限于篇幅不就以上三种方式的优劣展开讨论。不同的企业可选用最适用的配置管理办法，关键是要求各业务使用一致的方案，运维便可以有针对性的建设工具和系统来做好配置管理。版本管理DevOps持续交付八大原则之一“把所有的东西都纳入版本控制”。就运维对象而言，想要管理好它，就必须能够清晰的描述它。和源代码管理的要求类似，运维也需要对日常操作的对象，如包、配置、脚本等都进行脚本化管理，以备在运维系统在完成自动化操作时，能够准确无误的选定被操作的对象和版本。标准操作运维日常有大量重复度高的工作需要被执行，从精益思想的视角看，这里存在极大的浪费：学习成本、无价值操作、重复建设的脚本/工具、人肉执行的风险等等。倘若能在企业内形成统一的运维操作规范，如文件传输、远程执行、应用启动停止等等操作都被规范化、集中化、一键化的操作，运维的效率和质量将得以极大的提升。进程管理包括应用安装路径、目录结构、规范进程名、规范端口号、启停方式、监控方案等等，被收纳在进程管理的范畴。做好进程管理的全局规划，能够极大的提升自动化运维程度，减少计划外任务的发生。空间管理做好磁盘空间使用的管理，是为了保证业务数据的有序存放，也是降低计划外任务发生的有效手段。要求提前做好的规划：备份策略、存储方案、容量预警、清理策略等，辅以行之有效的工具，让这些任务不再困扰运维。日志管理日志规范的推行和贯彻需要研发密切配合，在实践中得出的经验，运维理想中的日志规范要包含这些要求：业务数据与日志分离日志与业务逻辑解耦日志格式统一返回码及注释清晰可获取业务指标（请求量/成功率/延时）定义关键事件输出级别管理方案（存放时长、压缩备份等）当具体上述条件的日志规范得以落地，开发、运维和业务都能相应的获得较好的监控分析能力。集中管控运维的工作先天就容易被切割成不同的部分，发布变更、监控分析、故障处理、项目支持、多云管理等等，我们诉求一站式的运维管理平台，使得所有的工作信息能够衔接起来和传承经验，杜绝因为信息孤岛或人工传递信息而造成的运营风险，提升整体运维管控的效率和质量。要点四：容错容灾在腾讯技术运营（运维）的四大职责：质量、效率、成本、安全。质量是首要保障的阵地，转换成架构的视角，运维眼中理想的高可用架构架构设计应该包含以下几点：负载均衡无论是软件或硬件的负责均衡的方案，从运维的角度出发，我们总希望业务架构是无状态的，路由寻址是智能化的，集群容错是自动实现的。在腾讯多年的路由软件实践中，软件的负载均衡方案被广泛应用，为业务架构实现高可用立下汗马功劳。可调度性在移动互联网盛行的年代，可调度性是容灾容错的一项极其重要的运维手段。在业务遭遇无法立刻解决的故障时，将用户或服务调离异常区域，是海量运营实践中屡试不爽的技巧，也是腾讯QQ和微信保障平台业务质量的核心运维能力之一。结合域名、VIP、接入网关等技术，让架构支持调度的能力，丰富运维管理手段，有能力更从容的应对各种故障场景。异地多活异地多活是数据高可用的诉求，是可调度性的前提。针对不同的业务场景，技术实现的手段不限。腾讯社交的实践可以参考周小军老师的文章“2亿QQ用户大调度背后的架构设计和高效运营”。主从切换在数据库的高可用方案中，主从切换是最常见的容灾容错方案。通过在业务逻辑中实现读写分离，再结合智能路由选择实现无人职守的主从切换自动化，无疑是架构设计对DBA最好的馈赠。柔性可用“先扛住再优化”是腾讯海量运营思想之一，也为我们在做业务架构的高可用设计点明了方向。如何在业务量突增的情况下，最大程度的保障业务可用？是做架构规划和设计时不可回避的问题。巧妙的设置柔性开关，或者在架构中内置自动拒绝超额请求的逻辑，能够在关键时刻保证后端服务不雪崩，确保业务架构的高可用。要点五：质量监控保障和提高业务质量是运维努力追逐的目标，而监控能力是我们实现目标的重要技术手段。运维希望架构为质量监控提供便利和数据支持，要求实现以下几点：指标度量每个架构都必须能被指标度量，同时，我们希望的是最好只有唯一的指标度量。对于业务日趋完善的立体化监控，监控指标的数量随之会成倍增长。因此，架构的指标度量，我们希望的是最好只有唯一的指标度量。基础监控指的是网络、专线、主机、系统等低层次的指标能力，这类监控点大多属于非侵入式，很容易实现数据的采集。在自动化运维能力健全的企业，基础监控产生的告警数据绝大部分会被收敛掉。同时，这部分监控数据将为高层次的业务监控提供数据支撑和决策依据，或者被包装成更贴近上层应用场景的业务监控数据使用，如容量、多维指标等。组件监控腾讯习惯把开发框架、路由服务、中间件等都统称为组件，这类监控介于基础监控和业务监控之间，运维常寄希望于在组件中内嵌监控逻辑，通过组件的推广，让组件监控的覆盖度提高，获取数据的成本属中等。如利用路由组件的监控，运维可以获得每个路由服务的请求量、延时等状态和质量指标。业务监控业务监控的实现方法分主动和被动的监控，即可侵入式实现，又能以旁路的方式达到目的。这类监控方案要求开发的配合，与编码和架构相关。通常业务监控的指标都能归纳为请求量、成功率、延时3种指标。实现手段很多，有日志监控、流数据监控、波测等等，业务监控属于高层次的监控，往往能直接反馈业务问题，但倘若要深入分析出问题的根源，就必须结合必要的运维监控管理规范，如返回码定义、日志协议等。需要业务架构在设计时，前置考虑运维监控管理的诉求，全局规划好的范畴。全链路监控基础、组件、业务的监控手段更多的是聚焦于点的监控，在分布式架构的业务场景中，要做好监控，我们必须要考虑到服务请求链路的监控。基于唯一的交易ID或RPC的调用关系，通过技术手段还原调用关系链，再通过模型或事件触发监控告警，来反馈服务链路的状态和质量。该监控手段属于监控的高阶应用，同样需要业务架构规划时做好前置规划和代码埋点。。质量考核任何监控能力的推进，质量的优化，都需要有管理的闭环，考核是一个不错的手段，从监控覆盖率、指标全面性、事件管理机制到报表考核打分，运维和开发可以携手打造一个持续反馈的质量管理闭环，让业务架构能够不断进化提升。要点六：性能成本在腾讯，所有的技术运营人员都肩负着一个重要的职能，就是要确保业务运营成本的合理。为此，我们必须对应用吞吐性能、业务容量规划和运营成本都要有相应的管理办法。吞吐性能DevOps持续交付方法论中，在测试阶段进行的非功能需求测试，其中很重要一点便是对架构吞吐性能的压测，并以此确保应用上线后业务容量的健康。在腾讯的实践中，不仅限于测试阶段会做性能压测，我们会结合路由组件的功能，对业务模块、业务SET进行真实请求的压测，以此建立业务容量模型的基准。也从侧面提供数据论证该业务架构的吞吐性能是否达到成本考核的要求，利用不同业务间性能数据的对比，来推动架构性能的不断提高。容量规划英文capacity一词可以翻译成：应用性能、服务容量、业务总请求量，运维的容量规划是指在应用性能达标的前提下，基于业务总请求量的合理的服务容量规划。运营成本减少运营成本，是为公司减少现金流的投入，对企业的价值丝毫不弱于质量与效率的提升。腾讯以社交、UGC、云计算、游戏、视频等富媒体业务为主，每年消耗在带宽、设备等运营成本的金额十分巨大。运维想要优化运营成本，常常会涉及到产品功能和业务架构的优化。因此，运维理想的业务架构设计需要有足够的成本意识，小结本文纯属个人以运维视角整理的对微服务架构设计的一些愚见，要实现运维价值最大化，要确保业务质量、效率、成本的全面提高，业务架构这块硬骨头是不得不啃的。运维人需要有架构意识，能站在不同角度对业务架构提出建议或需求，这也是DevOps 精神所提倡的，开发和运维联手，持续优化出最好的业务架构。