自己扩展你的系统，不要依靠供应商的解决方案实现扩展。了解如何扩展，如何用最简单的方式使用供应商提供的产品和服务。遵循该原则的原因有三点:主宰自己的命运、保持架构简单、减少在所有权方面的成本。不要依赖供应商的产品、服务或功能来扩展系统。保持架构简单，把命运掌控在自己手中，自己控制成本。而如果使用供应商的专有扩展方案，可能就做不到这三点了。...
让总线流量仅限于价值高于处理成本的数据。价值和成本是调整消息流量的标准。要减少低价值高成本的流量。对低价值/低成本和高价值/高成本的流量进行采样，以减少成本。消息流量并非“免费的”，对系统是有成本需求的。不要所有东西都发布。对流量进行采样可以在成本和价值之间取得平衡。...
尽可能使用异步通信，而不是同步通信。服务和各个层之间的所有调用。使用程序设计语言专有的调用，确保发出了请求，且没有在等待。同步词用会使整个程序执行停止来等待一个响应，从而把所有的展务和各个层维系在一起，造成级联性的故障。使用异步通信技术可以确保每个服务和层是独立的，这样系统的可扩展程度比所有部件都掲合在一起的系统大得多。...
在系统中存储会话数据时，使用分布式缓存。适用于任何需要存储会话数据但又不能将其存放在用户浏览器中的情况。小心一些常见的错误，如会话管理系统要求关联用户和Web服务器。...
尽量完全避免会话数据，必要时，可以考虑把数据放在用户的浏览器中。适用于任何需要会话数据来实现最佳用户体验的情形。采用cookie在用户的浏览器中存放会话数据。把会话数据存放在用户的浏览器中，可以使服务器池中的 任何一个Web服务器都能为该用户的请求提供服务，而且你的系统也不必再为它提供存储空间了。用cookie存放会话数据是种常见的方法，而且具有易于扩展的优点，但也有一些缺点。最关键的缺点就是未加密的cookie可以被轻易捕获，用于登录用户的账户。...
设计和实现无状态系统。适用于设计新系统或重新设计已有系统时。尽可能选择无状态实现。如果出于业务需求，合理地实了状态。实现状态会限制可扩展性，增大成本。在任何系统中，都要抵制对状态的需要。使用业务指标和多元(或AB)测试，判断应用中的状态是否真的实现了用户预期的行为和业务价值。...
减少以串联方式连接的组件数。无论何时要添加组件都适用。删除不必要的组件或添加它们的多个版本，将影响最小化。串联组件会使故障成倍增加。避免给系统添加串联组件。如果一定需要，则添加该组件的多个版本，这样一个版本出故障了，其他的版本还可以代替它。...
绝对不要实现且一定要减少单点数障。在架构图上我出单点实例。尽量采用主动/主动配置。通过多个实景大化可用性。尽量采用主动/主动配置，不要用主动被动解决方案。利用均衡器均衡跨服务实例的流量。对于单例模式，使用主动/被动配置的控制。...
在SELECT语句中声明游标时，不要使用 FOR UPDATE从句。适用情形:无论何时都适用。审查关于游标的代码，质疑每个 SEL ECT FOR UPDATE语向。使用 FOR UPDATE从句会锁定行，从而降低事务处理速度。要点:游标是一种强大的结构，使用得当，能够使编程更快更容易，同时还能加速事务处理。但 FOR UPDATE游标可能会长期锁定数据，降低事务处理速度。参考数据库文档，看是否需要使用 FOR READ ONIY从句，最小化锁的数量。 ...
不要使用多阶段提交协议存储或处理事务。不要使用它。用Y轴或Z轴划分分割数据存储和处理系统。应用理由:多阶段提交协议是一种阻断提议，在它完成之前，其他事务不能执行。不要将多阶段提交协议作为廷长整体数据库生命的简单方式。它很可能降低扩展性，甚至更早地终止系统的寿命。...
