泳道与虚拟化
当使用虚拟化技术将较大的服务器分割成较小服务器时，尝试沿物理服务器边界保持泳道。在同个物理服务器上混合不同泳道的虚拟服务器抵消了故障隔离泳道的许多好处。
规则2——拒绝单点故障
内容：永远不要实施会带有单点故障的设计，一直要消除单点故障。
场景：在架构审查和新系统设计时。
用法：在架构图上寻找单个实例。尽最大可能配制成主动/主动模式。
原因：通过多实例配置最大化可用性。
要点：努力实施主动/主动而非主动/被动配置。使用负载均衡器在服务的不同实例之间实现流量平衡。对需要单例的情形，可以在主动/被动模式的实例中采用控制服务。
在数学中，单元素集合是只有一个元素{A}的集合。按照编程的说法，单例模式是模拟数学概念的设计模式，把类的实例化限制在只有一个对象。这种设计模式对于资源协调很有用，但经常被研发人员出于便捷的目的而过度使用。在系统架构中，单例模式（或更恰当地说，反模式的单件情况）称为单点故障（SPOF）。这是指系统中仅有一个实例，当它失败时将导致系统范围的事故。
SPOF可以存在于系统的任何地方，包括单个网络服务器或单个网络设备，但最常见的是数据库系统中。原因是数据库往往最难跨越多个节点扩展，因此成为单例。在图9-1中，即使有冗余的登录、搜索和结账服务器，数据库也是SPOF。更糟糕的是，所有的服务池都依赖于那个单个数据库。虽然SPOF不好，但是数据库作为SPOF问题更大，因为如果数据库减慢或崩溃，所有同步调用该数据库的服务池都会遇到问题。
我们有个与客户分享的口头禅：“一切皆可能出故障。”这包括服务器、存储系统、网络设备和数据中心。凡能说出来的，都可能出故障，而且可能我们已经看到了这些故障。虽然大多数人认为数据中心永远不会出故障，但这些年我们亲身经历了十多次数据中心的服务中断。这同样适用于高可用的存储区域网络。尽管它明显比旧的SCSI磁盘阵列更可靠，但它仍然会出故障。
大多数SPOF的解决方案是直接部署一个硬件，通过复制X轴刻度所描述的服务确保每个服务至少运行在两个或者多个实例上。但是，这并不总是那么容易。让我们追溯编程步骤的单例模式。虽然不是所有的单例类都会阻止服务在多个服务器上运行，但是有一些实施绝对会避免可怕的后果。举个简化的例子，如果在处理从用户账户扣减资金的代码中有个类，可能会对此实施一个单例，以防止像用户账户余额为负数这样不愉快的事情发生。如果我们将此代码放在两个独立的服务器上，而不实施额外的控制或设置信号量，两个并发的事务有可能会都从用户账户上扣款，从而导致错误或不希望的情况发生。因此，要么修复代码来处理这种情况，要么依靠外部的控制来防止。最理想的解决方案是修复代码，以便在许多不同主机上实施服务，通常我们需要迅速修复代码以解除SPOF。作为本规则最后的重点，我们下一步将讨论一些快速修复的方法。
第一个和最简单的解决方案是采用主动/被动配置。将服务部署在主动服务器上运行，同时也部署在不处理流量的被动服务器上。热/冷配置通常用在数据库上作为去除SPOF的第一步。下一个选择是使用系统中的另一个组件来控制数据访问。如果数据库是SPOF，可以配置成主／从模式，应用可以控制数据访问，由主数据库完成写入／更新，由从数据库完成阅读/选择。除了消除SPOF，引入具有高读写比的只读数据库副本将减少主数据库的负载，并可以利用更经济实用的硬件，如第3章中规则11所讨论的那样。可以解决SPOF问题的最后一种配置是采用负载均衡器。如果网络或应用服务器上的服务是SPOF而且无法在代码中解决，通常可以采用负载均衡器，来解决用户请求只能由服务池中一台服务器来服务的问题。这可以通过设置在用户浏览器中的会话cookie来完成，利用负载均衡器把用户的每次请求重定向到相同的网络或应用服务器上，从而确保状态的一致性。
我们讨论了当无法及时通过修改代码解决SPOF时，几种可以快速实施的解决方案。尽管最佳而且最终的解决方案应该是修复代码，以允许服务的多个实例运行在不同的物理服务器上，但是首先是要尽早消除SPOF。记住，“一切皆可以出故障”，所以当修复SPOF的方案失败时，不要感到惊讶。
