可伸缩性的设计模式(或技术)

Question

您使用了哪些设计模式、或技术，这些技术专门针对可伸缩性？

在我看来，像飞重模式这样的模式是工厂模式的一个专门版本，以促进高可伸缩性或在内存或存储约束中工作。

你还用过其他什么？(数据库非正态化等)当高可用性或可伸缩性是您的主要目标时，您是否发现规则会发生变化？

可能的情况是：

• 移动设备比桌面或膝上型计算机具有更有限的内存、处理能力和连接性。
• 有限硬件上的高用户(缓存策略等)
• 优化数据库模式以提高效率以取代规范化设计(例如，SharePoint列包装用于存储)

Answer 1

脑海中浮现的几种模式：

• 无状态应用
• 松耦合
• 非同步
• 懒惰加载
• 缓存
• 平行性
• 分区
• 路由

一些资源：

• 可伸缩性最佳实践:来自eBay的经验教训
• 亚马逊首席技术官沃纳·沃格尔博士的可用性与一致性演示
• Microsoft PDC 08演示文稿
• 构建基于可伸缩云服务的最佳实践

Answer 2

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

Answer 3

没有什么是免费的-它归结为什么是可接受的妥协，以满足您的业务目标。主要变量是：

• 成本
• 可用性
• 一致性
• 可生存性(例如，分区容限)

一个很好的关于这个主题的纸。

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

设计模式确实起到了一定的作用，但最重要的是总体架构。在模块级别，您可能会非常彻底，但是忽略了网络级别的约束和可伸缩性。

在一天结束时，我相信一个人必须问自己(她自己)：对于失败类型X，有多少“用户”会受到影响，持续多长时间？

总有一个SPOF (单点故障)某处，但人们可以设计一个系统，使这个SPOF被移动更接近终点(例如，用户)。然而，在许多情况下，SPOF超出了应用程序的控制范围，例如网络POP不可用。

总之，我可以花几个小时在这个问题上.