应用程序的性能决定了您的软件完成预期任务的速度。它回答了有关应用程序的问题，例如
- 峰值负载下的响应时间
- 与替代方案相比，易用性、支持的功能和用例
- 运营成本（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 条评论