你好,

我正在阅读该项目 量化 在《每个软件架构师应该知道的 97 件事》一书中(已清理的亚马逊链接)这让我想知道如何量化可扩展性。

我为英国一家大型广播公司设计了两个系统,用于:

  1. 检测传入 HTTP 请求的来源国家/地区,或者
  2. 确定适合手机屏幕几何形状和当前连接类型的视频格式。

这两种设计都需要提供可扩展性。

我对这两个系统的设计都可以在缓存负载平衡层后面水平扩展,这些负载平衡层用于处理这两个服务的传入请求,并将它们分发到实际提供服务本身的多个服务器上。服务容量的初始增加是通过在负载平衡层后面添加更多服务器来实现的,因此称为水平可扩展性。

但是,如果负载平衡层开始难以处理传入请求流量,则该架构的可扩展性会受到限制。

那么,是否可以量化可扩展性?是否可以估计您可以添加多少额外服务器来水平扩展解决方案?

有帮助吗?

解决方案

我认为在某些情况下这是可能的——例如,Web 应用程序的可扩展性可以用用户数量、并发请求数量、响应时间的平均值和标准偏差等来量化。您还可以了解带宽和存储、每秒事务数以及恢复时间(用于备份和灾难恢复)的一般数据。

您还可以经常给出应用程序域内的数字 - 假设系统支持评论,您可以量化它需要能够存储的评论数量的数量级。

然而,值得记住的是,并不是所有重要的事情都可以衡量,也不是所有可以衡量的事情都很重要。:-)

其他提示

我认为这取决于可扩展性在给定上下文中的含义,因此答案是 这取决于.

我已经看到了一些尚不存在的需求的可扩展性。例如,一款新的贷款申请工具专门要求将来需要在 iPhone 和其他移动设备上工作。

我还看到可扩展性用于描述在世界不同地区扩展更多数据中心和 Web 服务器以提高性能的潜力。

如果有一个已知的未来目标,上面的两个例子都是可以量化的。但是,如果确实没有已知的目标或计划使其成为移动目标,那么可扩展性可能无法量化。

可扩展性的正确衡量标准(不是最简单的衡量标准;-)是一组定义所需资源(CPU、内存、存储、本地带宽等)和性能(例如,性能)的曲线。随着负载的增加(例如,延迟)交付就每秒查询而言,但其他衡量标准(例如所需的总数据吞吐量)也可能适合某些应用程序)。决策者通常会要求将这种准确但复杂的衡量标准归结为几个关键数字(几条曲线中某些曲线上的特定点),但我总是尝试协商更准确的衡量标准,而不是更容易理解的衡量标准关键指标!-)

当我想到可扩展性时,我想到的是:

  • 性能 - 应用程序对于给定的负载需要如何响应
  • 应用程序可以增长到多大的负载以及单位成本是多少(如果每台服务器包括软件、支持等)
  • 您可以以多快的速度扩展应用程序,以及在高峰使用期间需要多少缓冲(我们可以在 2-3 小时内增加 50% 的带宽,并要求比计划高峰使用 30% 的缓冲)

冗余是另一回事,但也应该包括在内并考虑在内。

“系统应进行扩展以维持成本/用户的 X 线性关系”。

这是一种方法:

“假设单个处理器每秒可以处理 100 个工作单元......”

http://www.information-management.com/issues/19971101/972-1.html

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top