Question

每当应用程序调用分布在多个服务器上的资源时，这个应用程序就需要定位这些资源的物理位置。在非云的世界中，这种服务位置解析通常由 DNS 和网络负载均衡器的组合来解决。图 4-1 展示了这个模型。

图 4-1 使用 DNS 和负载均衡器的传统服务位置解析模型

应用程序需要调用位于组织其他部分的服务。它尝试通过使用通用 DNS 名称以及唯一表示需要调用的服务的路径来调用该服务。DNS 名称会被解析到一个商用负载均衡器（如流行的 F5 负载均衡器）或开源负载均衡器（如 HAProxy）。

负载均衡器在接收到来自服务消费者的请求时，会根据服务消费者尝试访问的路径，在路由表中定位物理地址条目。此路由表条目包含托管该服务的一个或多个服务器的列表。接着，负载均衡器选择列表中的一个服务器，并将请求转发到该服务器上。

服务的每个实例被部署到一个或多个应用服务器。这些应用程序服务器的数量往往是静态的（例如，托管服务的应用程序服务器的数量并没有增加和减少）和持久的（例如，如果运行应用程序的服务器崩溃，它将恢复到崩溃时的状态，并将具有与之前相同的 IP 和配置）。

为了实现高可用性，辅助负载均衡器会处于空闲状态，并 ping 主负载均衡器以查看它是否处于存活（alive）状态。如果主负载均衡器未处于存活状态，那么辅助负载均衡器将变为存活状态，接管主负载均衡器的 IP 地址并开始提供请求。

这种模型适用于在企业数据中心内部运行的应用程序，以及在一组静态服务器上运行少量服务的情况，但对基于云的微服务应用程序来说，这种模型并不适用。原因有以下几个。

• 单点故障 ——虽然负载均衡器可以实现高可用，但这是整个基础设施的单点故障。如果负载均衡器出现故障，那么依赖它的每个应用程序都会出现故障。尽管可以使负载平衡器高度可用，但负载均衡器往往是应用程序基础设施中的集中式阻塞点。
• 有限的水平可伸缩性 ——在服务集中到单个负载均衡器集群的情况下，跨多个服务器水平伸缩负载均衡基础设施的能力有限。许多商业负载均衡器受两件事情的限制：冗余模型和许可证成本。第一，大多数商业负载均衡器使用热插拔模型实现冗余，因此只能使用单个服务器来处理负载，而辅助负载均衡器仅在主负载均衡器中断的情况下，才能进行故障切换。这种架构本质上受到硬件的限制。第二，商业负载均衡器具有有限数量的许可证，它面向固定容量模型而不是更可变的模型。
• 静态管理 ——大多数传统的负载均衡器不是为快速注册和注销服务设计的。它们使用集中式数据库来存储规则的路由，添加新路由的唯一方法通常是通过供应商的专有 API（Application Programming Interface，应用程序编程接口）来进行添加。
• 复杂 ——由于负载均衡器充当服务的代理，它必须将服务消费者的请求映射到物理服务。这个翻译层通常会为服务基础设施增加一层复杂度，因为开发人员必须手动定义和部署服务的映射规则。在传统的负载均衡器方案中，新服务实例的注册是手动完成的，而不是在新服务实例启动时完成的。

这 4 个原因并不是对负载均衡器的刻意指摘。负载均衡器在企业级环境中工作良好，在这种环境中，大多数应用程序的大小和规模可以通过集中式网络基础设施来处理。此外，负载均衡器仍然可以在集中化 SSL 终端和管理服务端口安全性方面发挥作用。负载均衡器可以锁定位于它后面的所有服务器的入站（入口）端口和出站（出口）端口访问。在需要满足行业标准的认证要求，如 PCI（Payment Card Industry，支付卡行业）合规时，这种最小网络访问概念经常是关键组成部分。

然而，在需要处理大量事务和冗余的云环境中，集中的网络基础设施并不能最终发挥作用，因为它不能有效地伸缩，并且成本效益也不高。现在我们来看一下，如何为基于云的应用程序实现一个健壮的服务发现机制。