3.2　高可用性和韧性

应用程序宕机是组织不愿意看到的，它会导致业务和用户的信任度受到损失，这使得高可用性成为设计解决方案架构时的主要考虑因素之一。不同应用程序对正常运行时间的要求各不相同。

如果应用程序面向外部并且拥有大量的用户群，例如电子商务网站或社交媒体，那么100%的正常运行时间就变得至关重要。对于内部应用程序（例如面向员工的HR系统或公司内部系统）或者博客系统来说，可以接受一些短时的停机。但实现高可用性与成本直接相关，因此，解决方案架构师始终需要根据应用程序需求来规划高可用性，以避免过度设计。

要实现高可用性（High Availability，HA）架构，最好将工作负载分布在数据中心相互隔离的区域中。这样，即便一个区域发生故障，应用程序副本仍然可以在另一个区域正常工作。

图3-4所示的架构图中，有一个Web服务器机群和一个应用服务器机群，它们分散在两个单独的可用区（数据中心的不同物理区域）中。负载均衡器可以在两个可用区之间分配工作负载，当可用区1因电源或网络中断而停机时，可用区2可以继续处理用户流量，这样应用程序仍然可以正常工作。对于数据库而言，可用区2中有一个备用实例，它将执行故障转移并在可用区1出现问题时切换为主实例。主实例和备用实例都持续同步数据。

图3-4　高可用性和韧性架构

解决方案架构需要考虑的另一个因素是韧性。当应用程序出现故障或者面临断断续续的问题时，应当采取自我修复原则，这意味着应用程序应该能够在没有人工干预的情况下自行恢复。

对于架构而言，可以通过监控工作负载并采取主动干预的措施来获得韧性。如以上架构所示，负载均衡器将监控实例的运行状况。一旦某个实例停止接收请求，负载均衡器就会将它从服务器机群中删除，并通知自动伸缩程序启动新的服务器进行替换。你还可以通过监控所有实例运行状态的方法（例如监控实例的CPU和内存利用率并当它们达到阈值后立即启动新的实例）进行主动干预，例如当CPU利用率高于70%或内存利用率超过80%时。

高可用性和韧性可以通过实现弹性来降低成本，例如，当服务器利用率较低时释放一些实例以节省成本。HA架构与自我修复机制紧密结合，确保应用程序持续正常运行。但是应用程序还需要能够快速恢复，以便维持必要的用户体验。