可扩展性的设计模式（或技术）答案

【问题标题】：Design Patterns (or techniques) for Scalability可扩展性的设计模式（或技术）
【发布时间】：2010-11-29 04:39:02
【问题描述】：

您使用过哪些设计模式或技术专门针对可扩展性？

在我看来，Flyweight 等模式是Factory Pattern 的专用版本，用于提高可扩展性或在内存或存储限制下工作。

你还用过什么？（Denormalization of Databases 等）当您的主要目标是高可用性或可扩展性时，您是否发现规则会发生变化？

可能的情况有：

【问题讨论】：

您能否在您的问题中定义可扩展性。在哪些方面可扩展，并且可能扩展多少。
恐怕你的问题没有意义，模式解决问题（充其量）而且你没有在你的帖子中提到任何问题。您甚至没有提到您正在谈论的那种应用程序 - 它是基于网络的吗？
@kragen2uk 怎么办没有意义并引起反对票？目前正在研究用于处理以可扩展性为主要关注点的编程问题的模式。
@NomeN 感谢推荐，我添加了一些可能的情况
@Chris 我的意思是模式只为解决问题提供指导——没有“减少网络场上的 CPU 使用”模式。例如，flywight 模式有助于解决在使用大量相似对象时性能不佳的问题，但我看不出是什么让这种模式比调整性能不佳的数据库的索引或从 Asp 中修剪不必要的 ViewState 更高的状态.Net 应用程序。所有这三个都是可以在特定情况下使用的简单技术。（我不喜欢设计模式：-p）

【解决方案1】：

使应用程序尽可能无状态。将更容易适应服务器场。

【讨论】：

【解决方案2】：

没有什么是免费的 - 归根结底，为了满足您的业务目标，可以接受哪些折衷方案。主要变量是：

一个很好的 paper 阅读主题。

我相信一个很好的衡量标准是检查“成本/用户”曲线并尝试将其保持为线性进展（假设每个用户可接受的成本是一个已知参数:-)

设计模式确实发挥了作用，但最重要的是总体架构。一个人可能在模块级别上已经非常彻底，但错过了网络级别的约束和可扩展性因此受到影响。

说到底，我相信一个人一定要问自己（她自己）：对于 X 型故障，有多少“用户”会受到影响，会影响多长时间？

在某处总会有一个 SPOF（单点故障），但可以设计一个系统，使这个 SPOF 更靠近端点（例如用户）。但在许多情况下，SPOF 不受应用程序的控制，例如网络 POP 不可用。

无论如何，我可以花几个小时在这个主题上......

【讨论】：

【解决方案3】：

想到的几个模式：

一些资源：

【讨论】：

【解决方案4】：

POSA（面向模式的软件架构）书籍是此类模式的重要来源。

POSA 4 尤其关注分布式计算，但所有卷都充满了可扩展性模式。

【讨论】：

【解决方案5】：

我对无状态应用程序逻辑的观察是，它引入了许多其他要求，例如锁定 DB，最终会影响可伸缩性。

假设部署的应用程序逻辑在服务器场中是无状态的，那么对于同时到达集群的两个节点的请求，我们必须引入数据库锁定等概念，以确保只处理一个请求。

我现在正在处理这种情况，想知道其他人是如何处理这种无状态行为的。

【讨论】：