scalability - 将可扩展性工程化到应用程序中

Question

这意味着什么 - 将可扩展性工程化到应用程序中。是否存在可以使应用程序更具可扩展性的设计模式？这个问题主要是在 Web 应用程序或基于 SOA 中间件的应用程序的上下文中。

Answer 1

当我想到“大规模应用程序”时，我会想到三件非常不同的事情:

将跨大型横向扩展集群(远大于 1024 个内核)运行的应用程序。

将处理比物理内存大得多的数据集的应用程序。

具有非常大的代码源库的应用程序。

每种“可扩展性”都会引入不同类型的复杂性，并需要一组不同的折衷方案。

横向扩展应用程序通常依赖于使用 MPI 来协调各种进程的库。一些应用程序是“令人尴尬的并行”，并且在不同进程之间需要很少(甚至不需要)通信来完成任务(例如渲染动画电影的不同帧)。这种类型的应用程序往往会受到基于 CPU 时钟速率或内存带宽的性能限制。在大多数情况下，添加更多内核几乎总是会增加应用程序的“可扩展性”。其他应用程序需要不同进程之间的大量消息流量，以确保解决方案的进展。这种应用风格往往会受到节点之间互连的整体性能的限制。这些消息密集型应用程序可能受益于非常高的带宽、低延迟的互连(例如 InfiniBand)。将可扩展性工程化到这种类型的应用程序中，首先要最大限度地减少所有进程对共享文件或资源的使用。

第二种可扩展性是在少量服务器(包括单个 SMP 风格服务器)上运行的应用程序，但它们处理非常大的数据集或非常多的事务。向系统添加物理内存通常可以增加应用程序的可扩展性。但是，在某些时候物理内存将耗尽。在大多数情况下，性能瓶颈会与系统的磁盘 I/O 的性能有关。在这些情况下，添加高性能持久存储(例如剥离的硬盘驱动器阵列)，甚至向某种 SAN 添加高性能互连都有助于提高应用程序的可扩展性。为这种应用程序设计可扩展性始于算法决策，该决策将最大限度地减少重复接触相同数据(或设置相同基础架构)的需要，而不是完成任务所需的次数(例如，打开到数据库的持久连接，而不是打开每个事务的新连接)。

最后，还有与源代码库的整体大小相关的可伸缩性的情况。在这些情况下，良好的软件工程实践有助于最大限度地减少冲突，并保持代码库干净。书 Large Scale C++ Software Design是我遇到的第一个真正接受为大型源代码基础软件开发提供最佳实践的挑战。本书侧重于将 C++ 作为实现语言，但指南和实践可以应用于任何项目或语言。将可扩展性工程设计到这种类型的应用程序中涉及对代码结构做出高层决策，以最大限度地减少代码库中的依赖关系(例如，不要有一个 .h，当更改时将强制重建整个代码库，使用构建将尽可能重用 .o 的系统)。