应用程序的性能决定了您的软件完成预期任务的速度。它回答了关于应用程序的问题，例如
- 峰值负载下的响应时间
- 与替代方案相比，易用性、支持的功能和用例
- 运营成本（CPU 使用率、内存需求、数据吞吐量、带宽等）
这种性能分析的价值不仅限于估计服务负载所需的计算资源或满足峰值需求所需的应用程序实例数量。性能显然与企业成功的根本要素息息相关。它影响整体用户体验，包括识别降低客户预期响应速度的因素、通过设计针对客户带宽优化的内容交付来提高客户粘性、选择最佳设备，并最终帮助企业发展业务。
问题
当然，这只是对业务服务性能工程价值的过度简化。为了理解完成我刚才描述的任务背后的挑战，让我们把它变得真实，并且稍微复杂一点。
现实世界的应用程序很可能托管在云端。应用程序可以使用非常庞大（或概念上无限）的计算资源。其在硬件和软件方面的需求将通过云端得到满足。开发人员将使用云端提供的功能来实现更快的编码和部署。云托管并非免费，但成本开销与应用程序的资源需求成正比。
除了搜索即服务 (SaaS)、平台即服务 (PaaS)、基础设施即服务 (IaaS) 和负载均衡即服务 (LBaaS) 之外（在这种情况下，云端负责托管应用程序的流量管理），开发人员可能还会使用以下一种或多种快速增长的云服务
- 安全即服务 (SECaaS)，满足软件和用户的安全需求
- 数据即服务 (DaaS)，根据应用程序的需求按需提供用户数据
- 日志记录即服务 (LaaS)，DaaS 的近亲，提供关于日志交付和使用情况的分析指标
- 搜索即服务 (SaaS)，用于应用程序的分析和大数据需求
- 网络即服务 (NaaS)，用于通过公共网络发送和接收数据
云驱动的服务也在呈指数级增长，因为它们使开发人员可以更轻松地编写复杂的应用程序。除了软件复杂性之外，所有这些分布式组件之间的相互作用也变得更加复杂。用户群变得更加多样化。软件的需求清单变得更长。对其他服务的依赖性变得更大。由于这些因素，这个生态系统中的缺陷可能会引发多米诺骨牌效应般的性能问题。
例如，假设您有一个编写良好的应用程序，它遵循安全编码实践，旨在满足不同的负载需求，并且经过了彻底的测试。还假设您拥有基础设施和分析协同工作以支持基本性能要求。那么，将性能标准构建到系统的实现、设计和架构中需要什么？软件如何跟上不断变化的市场需求和新兴技术？如何衡量关键参数来调整系统以获得随着时间推移的最佳性能？如何使系统具有弹性和自我恢复能力？如何更快地识别任何潜在的性能问题并尽快解决它们？
容器登场
软件 容器 以 微服务 设计或面向服务的架构 (SoA) 的优点为后盾，可以提高性能，因为由更小的、自给自足的代码块组成的系统更容易编码，并且与其他系统组件具有更清晰、定义明确的依赖关系。它更容易测试，并且资源利用率和内存过度消耗等问题比在庞大的单体架构中更容易识别。
当扩展系统以服务于增加的负载时，容器化的应用程序可以快速轻松地复制。安全漏洞可以更好地隔离。补丁可以独立进行版本控制并快速部署。性能监控更有针对性，测量结果也更可靠。您还可以重写和“整容”资源密集型代码段，以满足不断变化的性能要求。
容器启动和停止速度快。与虚拟机 (VM) 相比，它们可以实现高效的资源利用率和更好的进程隔离。容器没有空闲内存和 CPU 开销。它们允许多个应用程序共享一台机器，而不会损失数据或性能。容器使应用程序具有可移植性，因此开发人员可以构建应用程序并将其运送到任何运行 Linux 且支持容器技术的服务器，而无需担心性能损失。容器在其能力范围内运行，并遵守集群管理器（例如 Cloud Foundry 的 Diego、Kubernetes、Apache Mesos 和 Docker Swarm）施加的配额（示例包括存储、计算和对象计数配额）。
虽然容器在性能方面显示出优势，但即将到来的“无服务器”计算浪潮，也称为函数即服务 (FaaS)，将扩展容器的优势。在 FaaS 时代，这些短暂的或短寿命的容器将把好处扩展到应用程序性能之外，并直接转化为云托管开销成本的节省。如果容器更快地完成其工作，那么它的生命周期就会更短，并且计算过载纯粹是按需的。
4 条评论