如何架构和开发高性能，高伸缩性WEB 应用系统IB.pptVIP

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 可伸缩性最佳实践准则 避免分布式事务：看到这里，你可能在疑惑按功能划分数据和水平划分数据的实践如何满足事务要求。毕竟，几乎任何有意义的操作都要更新一个以上的实体——立即就可以举 出用户和商品的例子。正统的广为人知的答案是：建立跨资源的分布式事务，用两段式提交来保证要么所有资源全都更新，要么全都不更新。很不幸，这种悲观方案 的成本很可观。伸缩、性能和响应延迟都受到协调成本的反面影响，随着依赖的资源数量和客户数量的上升，这些指标都会以几何级数恶化。可用性亦受到限制，因 为所有依赖的资源都必须就位。实用主义的答案 是，对于不相关的系统，放宽对它们的跨系统事务的保证。 左右逢源是办不到的。保证跨多个系统或分区之间的即时的一致性，通常既无必要，也不现实。Inktomi的Eric Brewer十年前提出的CAP公理是这样说的：分布式系统的三项重要指标——一致性（Consistency）、可用性（Availability）和 分区耐受性（Partition-tolerance） ——在任意时刻，只有两项能同时成立。对于高负载量的应用例如互联网应用来说，我们必须选择分区耐受性，因为它是实 现可伸缩的根本。对于24x7运行的应用，选择可用性也是理所当然的。于是只好放弃即时一致性（immediate consistency）。 可伸缩性最佳实践准则 避免分布式事务：对于高负载量和高可用性的应用，我们应该绝对不允许任何形式的客户端或者分布式事务——因此绝不需要两段式提交。在某些经过仔细定义的情形下，我们会将作用于同一个数据库 的若干语句捆绑成单个事务性的操作。而对于绝大部分操作，单条语句是自动提交的。虽然我们故意放宽正统的ACID属性，以致不能在所有地方保证即时一致 性，但现实的结果是大部分系统在绝大部分时间都是可用的。当然我们需要采用了一些技术来帮助系统达到最终的一致性（eventual consistency）：周密调整数据库操作的次序、异步恢复事件，以及数据核对（reconciliation）或者集中决算（settlement batches）。具体选择哪种技术要根据特定用例对一致性的需求来决定。 对于架构师和系统的设计者来说，关键是要明白一致性并非“有”和“没有”的单选题。现实中大多数的用例都不要求即时一致性。正如我们经常根据成本和其他压力因素来权衡可用性的高低，一致性也同样可以量体裁衣，根据特定操作的需要而保证适当程度的一致性 。 。 可伸缩性最佳实践准则 用异步策略解耦程序：提高可伸缩性的另一项关键措施是积极地采取异步策略。如果组件A同步调用组件B，那么A和B就是紧密耦合的，而紧耦合的系统其可伸缩性特征是各部分 必须共同进退——要伸缩A必须同时伸缩B。同步调用的组件在可用性方面也面临着同样的问题。我们回到最基本的逻辑：如果A推出B，那么非B推出非A。也就 是说，若B不可用，则A也不可用。如果反过来A和B的联系是异步的，不管是通过队列、多播消息、批处理还是什么其他手段，它们就可以分别地伸缩。而且，此 时A和B的可用性特征是相互独立的——即使B受困或者死掉，A仍然能够继续前进。 整个基础设施从上到下都应该贯彻这项原则。即使在单个组件内部也可通过SEDA（分阶段的事件驱动架构，Staged Event-Driven Architecture）等技术实现异步性，同时保持一个易于理解的编程模型。组件之间也遵守同样的原则——尽可能避免同步带来的耦合。在多数情况下， 两个组件在任何事件中都不会有直接的业务联系。在所有的层次，把过程分解为阶段（stages or phases），然后将它们异步地连接起来，这是伸缩的关键。 可伸缩性最佳实践准则 将过程转变为异步的流：用异步的原则解耦程序，尽可能将过程变为异步的。对于要求快速响应的系统，这样做可以从根本上减少请求者所经历的响应延迟。对于网站或者交易系统， 牺牲数据或执行的延迟时间（完成全部工作的实践）来换取用户的延迟时间（用户得到响应的时间）是值得的。活动跟踪、单据开付、决算和报表等处理过程显然都 应该属于后台活动。主要用例过程中常常有很多步骤可以进一部分解成异步运行。任何可以晚点再做的事情都应该晚点再做。 还有一个同等重要的方面认识到的人不多：异步性可以从根本上降低基础设施的成本。同步地执行操作迫使你必须按照负载的峰值来配备基础设施——即使在 任务最重的那一天里任务最重的那一秒，设施也必须有能力立即完成处理。而将昂贵的处理过程转变为异步的流，基础设施