互联网技术架构——有备无患

不可能构建出永远不会故障的系统，所以需要考虑对故障隔离和故障控制的需求。下面是几种限制故障影响的方法，减少故障的频率，提高产品的整体可用性。

---

用泳道隔离故障

在设计中实现故障隔离区或泳道，需要拆分数据库和服务，并且禁止故障隔离的服务和数据间同步通信或访问。

因为泳道把用户或者跨用户共享的功能做了拆分，当出现故障时，可以更快地定位问题来源。

实现故障隔离的原则：

• 不共享：泳道不共享服务。但可以接受共享一些诸如边界路由器和负载均衡器的网络设备。如有必要，可共享存储区域网络。数据库和服务器永远不应共享。
• 在泳道之间不进行同步调用：不允许跨越泳道边界进行同步调用。因为同步调用会捆绑服务，所以被调用服务的失败会蔓延到所有其他以同步和阻塞方式方式调用的系统。这样，部署在一条泳道里的服务失败可能会导致部署在另一条泳道里的服务失败。
• 限制泳道之间的异步调用：尽管允许，但应该限制泳道之间的异步调用。因为调用越多，故障蔓延的机会就越大。
• 异步调用设置超时和开关控制：异步调用应设置超时，只是通知另一条泳道，但并不在乎是否得到回应。必要时应该有能力关闭通信。

当使用虚拟化技术将较大的服务器分隔成较小服务器时，尝试沿物理服务器边界保持泳道。而不要把来自于不同泳道的虚拟服务器放在同一物理设备上。

---

拒绝单点故障

永远不要实施带有单点故障的设计，一直要消除单点故障。在架构审查和新系统设计时，寻找单个实例，尽最大可能配置成主动/主动模式。努力实施主动/主动而非主动/被动配置。使用负载均衡器在服务的不同实例之间实现流量均衡。对需要单例的情形，可以在主动/被动模式的实例中采用控制服务。

在系统架构中，单例模式称为单点故障（SPOF）。这是指系统中仅有一个实例，当它失败时将导致系统范围的事故。

SPOF可以存在于系统的任何地方，包括单个网络服务器或单个网络设备，但最常见的是数据库系统中。因为数据库往往最难跨越多个节点扩展，因此成为单例。

大多数SPOF的解决方案是直接部署一个硬件，通过复制X轴所描述的服务确保每个服务至少运行在两个或者多个实例上。

如果数据库是SPOF，可以配置成主/从模式，应用可以控制数据访问，由主数据库完成写入/更新，由从数据库完成阅读/选择。

如果网络或应用服务器是SPOF而无法在代码中解决，通常可以采用负载均衡器，来解决用户请求只能由服务池中一台服务器来服务的问题。这可以通过设置在用户浏览器中的会话cookie来完成，利用负载均衡器把用户的每次请求重定向到相同的网络或应用服务器上，从而确保状态的一致性。

---

避免系统串联

减少以串联方式连接的组件数量。由于串联组件受多重失败乘法效应的影响，我们应删除不必要的组件、收起组件或添加多个并行组件以减少影响。

多台Web服务器可以分散流量负载并避免系统故障，但是对于数据层和网络层，往往会忽视这个问题，尤其是数据库和防火墙。

---

启用与禁用功能

搭建一个框架来启用与禁用产品的功能。为了保护对最终用户很重要的关键功能，有时需要关闭有问题或非关键性的功能。所以要考虑使用上线和下线框架控制新研发的、非关键的或者依赖第三方的功能。但是只有当实施成本低于风险损失时，实现上线和下线框架，开发可以复用的共享库才可以降低未来实施的成本。

一些控制功能启用和禁用的方法：

• 基于超时的自动关闭：当调用第三方服务变慢时，应用会在一定时间内将该功能标记为“关闭”，直至人为干预重新启动它。
• 替代该服务：当某个服务出问题时，取代该服务，用一个自动应答器发出假的响应以表示服务不可用或者使用缓存发出“像正常数据”一样的响应。
• 人工关闭：管理员人工发出信号或命令来停止某个响应缓慢的功能。
• 利用配置文件：改变配置文件中的参数以指示关闭服务。
• 利用文件关闭：凭借一个文件的存在与否标识某个功能是否可用。
• 运行时的变量：在启动时作为入口参数读入程序，然后像守护线程一样运行。
• 数据库：在启动时从数据库中读取参数或者文件，以控制应用代码显示或不显示某组功能。

实施上线/下线框架的重要原因：

1. 新功能或正在积极开发的功能很可能有缺陷有能力关闭有问题的功能非常有价值。
2. 如果功能对所提供的服务不重要，有可能想要关闭非关键功能。当计算资源称为瓶颈时，关闭非关键功能以保护更多关键功能是个很好的选择。
3. 调用第三方服务经常要以同步方式进行。当供应商的API开始响应缓慢时，能够关闭功能可以防止它减缓整个应用或服务。

---

想了解更多关于互联网技术架构：互联网技术架构专栏