绝对不要信任单点故障

绝对不要实现且一定要减少单点数障。在架构图上我出单点实例。尽量采用主动/主动配置。通过多个实景大化可用性。尽量采用主动/主动配置，不要用主动被动解决方案。利用均衡器均衡跨服务实例的流量。对于单例模式，使用主动/被动配置的控制。在数学中，单元素集合是只有一个元素的集合，如{A}。在程序设计中，单例模式指的是一种设计模式，它模仿了数学概念，限制了一个类只能实例化一个对象。这种设计模式对协调资源非常有用，但程序员常为了省事而过度使用它，这个话题我们之后再讨论。在系统架构中，单例模式，或者更恰当地说是单例反模式，被称为单点故障(SPOF)也就是说，当系统中的某个组件只有一个实例时，一旦该实例出故障，就会造成系统范围的影响。SPOF在系统中随处可见，从单个的Web服务器到单个的网络设备，但系统中最常见的SPOF是数据库。其原因在于数据库是最难扩展到多个节点上的，因此它只有一个实例。在图9-1中，即使登录、搜索和结账服务器都有冗余，数据库仍是SPOF。更精的是，所有服务池都依赖于这一个数据库。虽然任何SPOF都不好，但数据库SPOF的问题更大，如果数据库速度下降或者期读了，那么对数据库进行同步调用的所有服务池都将受到这一事件影响。我们常说给客户的一句口头禅是“一切都会出故障”。这句话适用于服务器、存储系统、网络设备和数据中心。只要你知道的，都会出故障。虽然很多人认为数据中心是不会出故障的，但多年来，我们自己经历了十几次数据中心运行中断。高可用的存储区域网络也是如此，虽然它们比旧的SCSI硬盘阵列可靠得多，但仍旧会出故障。大多数解决SPOF的方法是申请另一台硬件，如X轴扩展所示的通过克隆服务，让每种服务都有两个或更多个实例在运行。遗憾的是，事实并非总是如此简单。让我们回头再看看编写单例模式的步骤。虽然不是所有的单例类都不允许在多台服务器上运行一个服务，但有些实现绝对会让你免于遭受可怕的后果。较简单的情况是，如果代码中有一个类，用于从用户账户中减去基金，用单例模式实现它就会让用户的余额免于不测，如成为负数。如果把这段代码放在两台独立的服务器上，没有额外的控制措施或联络信号，则很可能会造成两个事务同时在用户账户中记人借额，从而导致错误或不想发生的状况。对于这种情况，我们需要修复代码，或者依赖外部控制来预防。但最令人满满意的解决方案是修复代码，在多个主机上实现服务，通常我们需要快速修复SPOF。作为本原则的最后一个要点，我们接下来将讨论几个快速修复方法。