绝对不要实现且必定要削减单点数障。在架构图上我出单点实例。尽量采取自动/自动设置装备摆设。经由过程多个实景年夜化可用性。尽量采取自动/自动设置装备摆设，不要用自动被动解决计划。应用平衡器平衡跨办事实例的流量。对于单例模式，应用自动/被动设置装备摆设的掌握。

在数学中，单位素聚集是只有一个元素的聚集，如{A}。在法式设计中，单例模式指的是一种设计模式，它模拟了数学概念，限制了一个类只能实例化一个对象。这种设计模式对调和资本异常有效，但法式员常为了省事而过度应用它，这个话题我们之后再评论辩论。在体系架构中，单例模式，或者更适当地说是单例反模式，被称为单点故障(SPOF)也就是说，当体系中的某个组件只有一个实例时，一旦该实例出故障，就会造成体系规模的影响。

SPOF在体系中到处可见，从单个的Web办事器到单个的收集装备，但体系中最常见的SPOF是数据库。其原因在于数据库是最难扩大到多个节点上的，是以它只有一个实例。在图9-1中，即使登录、搜刮和结账办事器都有冗余，数据库仍是SPOF。更精的是，所有办事池都依附于这一个数据库。固然任何SPOF都欠好，但数据库SPOF的问题更年夜，假如数据库速度降低或者期读了，那么对数据库进行同步骤用的所有办事池都将受到这一事宜影响。

我们常说给客户的一句口头禅是“一切都邑出故障”。这句话实用于办事器、存储体系、收集装备和数据中间。只要你知道的，都邑出故障。

固然许多人以为数据中间是不会出故障的，但多年来，我们本身阅历了十几回数据中间运行中止。高可用的存储区域收集也是如斯，固然它们比旧的SCSI硬盘阵列靠得住得多，但仍然会出故障。

年夜多半解决SPOF的办法是申请另一台硬件，如X轴扩大所示的经由过程克隆办事，让每种办事都有两个或更多个实例在运行。遗憾的是，事实并非老是如斯简略。让我们回头再看看编写单例模式的步调。固然不是所有的单例类都不许可在多台办事器上运行一个办事，但有些实现绝对会让你免于遭遇恐怖的效果。较简略的情形是，假如代码中有一个类，用于从用户账户中减去基金，用单例模式实现它就会让用户的余额免于意外，如成为负数。假如把这段代码放在两台自力的办事器上，没有额外的掌握办法或联络旌旗灯号，则很可能会造成两个事务同时在用户账户中记人借额，从而导致毛病或不想产生的状态。对于这种情形，我们须要修复代码，或者依附外部掌握来预防。但最令人满满足的解决计划是修复代码，在多个主机上实现办事，平日我们须要快速修复SPOF。作为来源根基则的最后一个要点，我们接下来将评论辩论几个快速修复办法。

第一个办法最简略，是应用自动/被动设置装备摆设。一个办事在一台办事器上自动运行，在别的一台办事器上被动运行(不吸收流量)。这种热/冷设置装备摆设，常被用作删除数据库SPOF的第一步。接下来的办法是用体系中的另一个组件掌握数据拜访。假如SPOF是办事，那么用数据库锁可以掌握数据的拜访。假如SPOF是数据库，那么可以设置主一从设置装备摆设，由运用掌握数据拜访，写更新操作由主数据库完成，读选择操作由从数据库完成。最后一个用于修复SPOF的设置装备摆设是负载平衡器。假如Web办事器或运用办事器的一个办事是SPOF，且在代码中不克不及清除，那么可以应用负载平衡器把一个用户的要求只发送给池中的一台办事器。这是经由过程会话cookie实现的，即设置用户的阅读器，且许可负载平衡器每次都把该用户的要求重定向到统一个Web或运用办事器，从而形成一种一致状况。

我们介绍了几种清除SPOF的办法，在不克不及实时修正代码的情形下可以轻松地实现它们。然则最后的办法最好，即修复代码，许可网站设计办事的多个实例在分歧的物理办事器上运行，从而尽可能清除SPOF。记住，“一切都邑出故障”，所以当SPOF出故障时，请不要受惊。