提高应用程序可用性：基础知识

在一个始终要在线的生产环境中，如何确保当问题发生时，应用程序仍然可用？

解决这个问题远非简单，需要在做出选择时明确表达，同时兼顾公司的资源限制。

这是系列文章的第一篇，涵盖了从定义您需要提供的保证，到可以利用的模式，再到设计解决方案时所做选择的后果。

在本系列文章中，您可以期待以下内容：

•可用性基础知识（本文）•冗余与持久性•优雅降级与异步处理•灾难恢复•Active-Active 模式

让我们从建立对可用性水平的共同理解开始这段旅程。

五个九

当我们谈论可用性时，"高可用性" 这个术语就会浮现出来。但“高”对你和对我可能意味着不同的东西。

在行业中，通常用应用程序在预期水平下运行的时间百分比来衡量可用性 —— 稍后我们会详细解释这一点。

图 1. 定义可用性

根据这个定义，讨论的重点变成了这个百分比是多少。在你直接回答 100% 之前，让我们先看一下不同的可用性级别意味着什么：

图 2. 可用性尺度

因此，五个九的可用性意味着一年中您只能承受大约 5 分钟的无响应时间。

当你把这些数字放在上下文中，再加上你的应用程序与其最弱的环节一样强时，你会意识到要实现这一点并不容易，尤其是当你考虑到故障可能以更高的频率发生时。

图 3. 一些可能出问题的物理组件

在这个系列文章中，我们将展示使这一看似不可能的壮举可实现的策略。但不要忘记，这些策略并非免费。

成本

为了理解成本和复杂性是如何受影响的，让我们考虑一个简单的电子商务应用程序。为了简化起见，我不考虑由于代码更改（错误）导致的应用程序错误，而是考虑代码以外的任何问题。

图 4. 示例应用程序背景

我们强调了一些更可能导致问题的因素：

•连接性 —— 你的互联网连接中断，客户无法访问你的应用程序。•计算能力 —— 服务器宕机，客户无法执行应用程序。•持久性 —— 持久性服务宕机，应用程序无法检索/保存所需的信息来服务客户。

应对这种情况的第一个策略，是在下一篇文章中将详细讨论的：增加 一些 冗余。

图 5. 添加一些冗余有助于提高可用性

现在，您拥有两个不同的网络连接，使用两个不同的提供商连接到您的数据中心。如果一个宕机，客户可以通过备用连接路由。

您还拥有两台服务器，因此如果第一台服务器宕机（电源故障、CPU 故障等），客户可以由备用服务器提供服务。

最后，您还拥有双重持久性，因此数据可以在备用持久性服务中检索/保存。

在这个简单的场景中，你可以说问题已经解决，我们达到了我们的可用性目标。然而，忽视所有其他尚未解决的问题，实施这种策略并不是没有成本的。

如果考虑到大多数时间系统是正常工作的，那么我们将运营成本翻倍来服务相同数量的客户。请注意，我们并没有为了扩展性而增加额外的基础设施。

复杂性

随着我们所做的更改，我们还引入了复杂性，增加了我们解决方案需要采用的额外组件，更不用说我们的员工需要接受的培训了。

例如，我们的解决方案现在需要检测故障并更新 DNS 条目以指向备用服务器的 IP 地址。

图 6. 检测故障是我现在必须做的另一项任务

或者，在持久性问题的情况下，我们的应用程序服务器需要从一个持久性服务切换到另一个。

当然，市场上已经有解决方案可以帮助实现这些，例如带有健康检查的负载均衡器/代理，可以为你做这个切换，但这些都是带有自身可用性问题、成本和特定功能的额外组件。

突然之间，我们的简单应用程序变得不再那么简单，理解、开发和调试都变得复杂起来。

那我们该如何处理呢？您可以将这部分复杂性外包给您的提供商，并采用基于云的解决方案。尽管您无法完全逃避所有复杂性及其相关成本，但关键在于要识别出并非所有应用程序（或应用程序的部分）都是一样的。

优先级

*"如果一切都是优先级，那么没有任何事情是优先级。"*

实际上，我们的应用程序很少像我们提供的例子那样简单。一个更现实的电子商务解决方案可以如下图所示：

图 7. 扩展版应用程序示例

当我们讨论可用性时，第一个面临的问题是倾向于为整个系统选择一个级别。

在我们的虚构电子商务应用程序中，我们可以将这些应用程序分为四个层次：

•T1 网站、支付

如果这两者不可用，客户无法浏览目录或支付下单。

•T2 订单管理

如果不可用，客户无法查看订单历史或修改订单。

•T3 履行

如果不可用，已下的订单无法履行（物理挑选、打包、发货）。

•T4 ERP

如果不可用，内部团队无法访问应付账款和财务报告。

如我们所见，每一层都可以有不同的可用性目标。例如，在许多企业中，履行订单的过程是以小时为单位测量的，因为它涉及手动操作并为效率而合并。

在这种情况下，虽然不理想，但履行系统的停机时间比网站的停机时间可以忍受得更久，因为客户几乎会立即感受到网站的影响。

因此，当您解决可用性问题时，了解每个组件对操作的影响非常重要。第一个反应可能是认为一切都是优先级，任何事情都不能失败。但实际上，总是有讨论的空间，您的目标是进行影响分析，并根据其关键性和对客户的影响为每个组件划分优先级。

那些不太关键的部分可以“享受”较低的可用性百分比，这有助于降低成本和复杂性。

接下来

正如我们所见，通向高可用性的道路并非没有风险，第一个风险就是低估期望的 4 或 5 个九意味着什么。

在 99.9% 的情况下，我们讨论的停机时间仅为每天 1.44 分钟，这意味着检测并纠正问题的时间非常短，以至于需要考虑某种程度的自动化。

随着我们在这一系列文章中深入讨论提高可用性的策略，我们将看到它们都伴随着权衡，而成本和/或复杂性将是熟悉的面孔。

为了将两者保持在合理的水平，必须根据其关键性划分业务功能的优先级。根据您的业务类型，找到能够承受较长停机时间的应用程序可能更容易，也可能更困难。不要误解我的意思，没有人会说停机时间是一件好事，但这就是您可以讨论影响并确定可以接受的程度的地方。