实现高可用性需要回答的两个问题

消费者和员工突然转向数字化体验对运营的最大影响可能是可用性。 当然，随着员工从办公室转移到家中，相当一部分组织在远程访问方面遇到了困难。 但最终只有部分员工在家工作，而整个人口突然都依赖于数字化的日常生活。 

看看诺基亚的调查结果，其报告称“2020 年 3 月份的上行流量（美国部分网络）”比“疫情前水平增加了 30%”。 或者此数据显示四月第二周交易量增加了 72%（页面浏览量增加了 29%）。  

对于数字体验的需求不断上升。 对于用户来说，没有什么比应用程序或网站无法加载更令人沮丧的了。 老实说，对于运营商来说，没有什么比应用程序或网站无法加载更令人沮丧的了。

实现高可用性不仅仅是在数据路径中插入负载平衡器的问题。 这是等式的一部分，但它只是确保应用程序或网站保持可用所需步骤之一。

您需要做的第一件事是回答两个不那么简单的问题：

• 如何在服务器之间分配流量以实现高可用性？
• 需要什么级别的健康检查才能正确验证服务器的可用性？

乍一看，这些似乎比实际上要简单。 这是因为要回答这些问题，您需要了解很多有关该应用程序及其基础设施的知识。

我们开始吧，好吗？

如何在服务器之间分配流量以实现高可用性？

这个问题实际上在于探讨使用正确的负载平衡算法，因为算法决定了流量（请求）如何在资源（服务器）之间分配。 答案取决于很多因素，但首先要从应用程序架构和使用模式开始。 

你知道，如果你想让传统应用程序（整体式、客户端-服务器、三层网络）具有高可用性，你必须从完全不同的角度来理解使用模式。

这是因为一个后端“服务器”负责执行所有业务逻辑。 尝试登录？ 订购产品？ 浏览目录？ 全部都是同一个“服务器”。 您可能认为只需使用循环之类的简单算法即可分配流量。 恰恰相反，我的朋友。 每个业务功能都有不同的计算、内存、网络和数据要求。 这意味着每个业务功能都会给“服务器”带来不同的负载。 单个“服务器”实例可能很快就会因为向其发送过多的资源密集型请求而变得不堪重负。

优化请求分配以确保传统应用程序可用性的最佳方法是使用基于最少连接的算法。 这将根据当前打开的连接数将负载分布在“服务器”实例之间。 这种方法之所以有效是因为资源密集型的请求需要更长的时间来处理，从而保持连接处于活动状态。 通过将请求定向到连接数较少的“服务器”，您更有可能保持所有服务器可用。  

对于现代（基于微服务的）应用程序，这个问题更容易回答。 这是因为现代应用程序已经分解为可单独扩展的业务功能。 使用基于最少连接的算法仍然是一个好主意，因为对同一功能的某些请求可能会比其他请求消耗更多的资源，但在现代应用程序架构中，流量自然是平衡的，因此几乎任何算法都可以用来保持所有“服务器”可用。

关于可用性的有趣之处（至少对我来说）在于，知道如何分配请求只是成功的一半。 不幸的是，另一种不是红蓝激光，而是依赖于对应用健康状况的可见性。

需要什么级别的健康检查才能正确验证服务器的可用性？

这就是我关于可观察性的论文*应该插入的地方，但为了简洁和您的理智，我仅总结如下： 

如果您使用“应用可用性”以外的任何因素来确定应用程序的状态，则会危及高可用性。 这是因为其他可观察的指标都无法告诉你有关应用程序的任何信息。虽然你需要网络、传输和平台可用性，但除非你确信应用程序已准备好接收请求，否则如果你向其发送流量，那你就是在自找麻烦。

可观察性的四个组成部分都很重要。 如果失去网络连接，那么其余的事情就真的不重要了。 因此，您需要关注所有四个措施，这意味着检查它们全部。 应用程序架构是什么并不重要。 所有应用程序都依赖于网络、传输和平台层。 架构的不同之处在于应用程序层，因为架构可能会限制您确定应用程序是否正常运行的方式。

在开发过程中，您应该始终询问对应用程序进行“健康检查”的方法。 无论是通过 API 还是 HTTP 请求，专用的“健康检查”的存在为开发人员和操作人员提供了一种简单的方法来验证应用程序是否正常运行。 这可以包括验证与外部资源（如数据或合作伙伴 API）的连接的功能。 由于任何一个组件出现故障都可能导致应用程序对消费者不可用或无响应，因此验证所有必需组件的可用性非常重要。

高可用性比想象的要难

营销文献常常会让你相信高可用性就像克隆服务器并在其前面安装负载平衡器一样简单。 但实际情况是，需要认真考虑、测量和准备，才能确保应用程序的高可用性。 这不仅仅是确保实例可用的问题；这还需要确保所有依赖应用程序都可用，并以不会压垮任何给定实例的方式分配请求。

您为确保应用程序高可用性而投入的所有额外工作的好处是，可以获得积极的客户体验，并且减少深夜因应用程序宕机而拨打的紧急电话。

_{* 我实际上并没有关于可观测性的论文。 但如果我这样做了，它就会被插入到这里。}