服务的实例已在运行中_[译文]微服务架构中的服务发现

最新推荐文章于 2022-07-06 18:48:58 发布

weixin_39877050

最新推荐文章于 2022-07-06 18:48:58 发布

阅读量783

点赞数

文章标签：服务的实例已在运行中

系列目录1、[译文]什么是微服务架构 MicroService Architecture2、[译文]利用 API Gateway 构建微服务3、[译文]构建微服务：微服务架构中的进程间通信4、[译文]微服务架构中的服务发现 -- 本篇5、[译文]微服务的事件驱动数据管理

为什么要使用服务发现

假设您正在编写一些代码，这些代码将调用具有 REST API 或 Thrift API 的服务。为了发出请求，您的代码需要知道服务实例的网络位置(IP 地址和端口)。在运行于物理硬件上的传统应用程序中，服务实例的网络位置是相对静态的。例如，您的代码可以从偶尔更新的配置文件中读取网络位置。

但是，在现代的基于云的微服务应用程序中，这是一个要解决的难题，如下图所示。

img

服务实例具有动态分配的网络位置。而且，服务实例集会由于自动缩放，故障和升级而动态更改。因此，您的客户端代码需要使用更复杂的服务发现机制。

有两种主要的服务发现模式：客户端发现和服务器端发现。让我们首先看一下客户端发现。

客户端发现模式

使用客户端发现时，客户端负责确定可用服务实例的网络位置，并在它们之间进行负载平衡请求。客户端查询服务注册表，该服务注册表是可用服务实例的数据库。然后，客户端使用负载平衡算法选择可用的服务实例之一并发出请求。

下图显示了此模式的结构。

服务实例的网络位置在启动时会在服务注册表中注册。实例终止时，将从服务注册表中将其删除。通常使用心跳机制定期刷新服务实例的注册。

Netflix OSS 提供了一个很好的客户端发现模式示例。Netflix Eureka 是一个服务注册表。它提供了一个 REST API，用于管理服务实例注册和查询可用实例。Netflix Ribbon 是 IPC 客户端，可与 Eureka 一起在可用服务实例之间负载均衡请求。

客户端发现模式具有多种优点和缺点。这种模式相对简单，除服务注册表外，没有其他活动部分。另外，由于客户端知道可用的服务实例，因此它可以做出智能的，特定于应用程序的负载平衡决策，例如一致地使用哈希。

这种模式的一个重大缺陷是它将客户端与服务注册表耦合在一起。您必须为服务客户端使用的每种编程语言和框架实现客户端服务发现逻辑。

简单理解就是：client 从一个地方查询到注册存活的服务地址列表，然后 client 通过负载算法选择其中一个服务地址进行请求。

但是，有一个潜在问题：如果后端服务在心跳期间死掉了，client 有可能会选到一个已死的服务地址。--- 这种一般可以通过缩短心跳时间间隔解决

现在我们已经研究了客户端发现，让我们看一下服务器端发现。

服务器端发现模式

服务发现的另一种方法是服务器端发现模式。下图显示了此模式的结构。

客户端通过负载平衡器向服务发出请求。负载平衡器查询服务注册表，并将每个请求路由到可用的服务实例。与客户端发现一样，服务实例是通过服务注册表注册和注销的。

简单理解就是：client 请求负载均衡(比如 NGINX 等)，然后由负载均衡器去查询服务列表，选中其中一个地址后，再进行请求。

其实这类也存在与客户端发现类似问题，心跳期间服务死掉了，没有来得及注销而被 client 请求选择到的情况。--- 这种一般可以通过缩短心跳时间间隔解决

AWS 弹性负载均衡(ELB)是一个服务器端发现路由器的一个例子。ELB 通常用于平衡来自 Internet 的外部流量。但是，您也可以使用 ELB 负载均衡虚拟私有云(VPC)内部的流量。客户端使用其 DNS 名称通过 ELB 发出请求(HTTP 或 TCP)。ELB 在一组已注册的弹性计算云(EC2)实例或 EC2 容器服务(ECS)容器之间平衡流量。没有单独的服务注册表。而是将 EC2 实例和 ECS 容器注册到 ELB 本身。

诸如 Kubernetes 和 Marathon 之类的某些部署环境在集群中的每个主机上运行一个代理。代理充当服务器端发现负载平衡器的角色。为了向服务发出请求，客户端使用主机的 IP 地址和服务的分配端口通过代理路由请求。然后，代理透明地将请求转发到在群集中某处运行的可用服务实例。

服务器端发现模式具有多个优点和缺点。这种模式的一大好处是发现细节从客户端被抽象出来了。客户只需向负载均衡器发出请求。这样就无需为服务客户端使用的每种编程语言和框架实现发现逻辑。另外，如上所述，某些部署环境免费提供此功能。但是，这种模式也有一些缺点。除非负载平衡器是由部署环境提供的，否则它是您需要设置和管理的又一个高度可用的系统组件。

服务注册表

服务注册表是服务发现的一个关键部分。它是一个数据库，其中包含服务实例的网络位置。服务注册表需要高度可用且最新。客户端可以缓存从服务注册表获得的网络位置。但是，该信息最终会过时，并且客户端将无法发现服务实例。因此，服务注册表由使用复制协议维护一致性的服务器群集组成。

如前所述，Netflix Eureka 是服务注册表的一个很好的例子。它提供了 REST API，用于注册和查询服务实例。服务实例使用 POST 请求注册其网络位置。每隔 30 秒，它必须使用PUT 请求刷新其注册。通过使用 HTTP DELETE请求或实例注册超时来删除注册。如您所料，客户端可以使用 HTTP GET 请求来检索注册的服务实例。

Netflix 通过在每个 Amazon EC2 可用性区域中运行一台或多台 Eureka 服务器来实现高可用性。每个 Eureka 服务器都在具有弹性 IP 地址的 EC2 实例上运行。DNS TEXT 记录用于存储 Eureka 群集配置，该配置是从可用区到 Eureka 服务器网络位置列表的映射。当 Eureka 服务器启动时，它将查询 DNS 以检索 Eureka 群集配置，找到其对等方，并为其分配一个未使用的弹性 IP 地址。

Eureka clients –> services and service clients –> query DNS 以发现 Eureka 服务器的网络位置。客户端更喜欢在相同的可用性区域中使用 Eureka 服务器。但是，如果没有可用的客户端，则客户端将在另一个可用性区域中使用 Eureka 服务器。

服务注册表的其他示例包括：

etcd –高可用性，分布式，一致的键值存储，用于共享配置和服务发现。使用 etcd 的两个著名项目是 Kubernetes 和 Cloud Foundry。
consul –用于发现和配置服务的工具。它提供了一个 API，允许客户端注册和发现服务。领事可以执行运行状况检查以确定服务可用性。
Apache Zookeeper –广泛用于分布式应用程序的高性能协调服务。Apache Zookeeper 最初是 Hadoop 的子项目，但现在是顶级项目。另外，如前所述，某些系统(例如 Kubernetes，Marathon 和 AWS)没有明确的服务注册表。相反，服务注册表只是基础结构的内置部分。

现在，我们已经了解了服务注册表的概念，让我们看一下如何在服务注册表中注册服务实例。

服务注册选项

如前所述，服务实例必须在服务注册表中注册或注销。有两种不同的方式来处理注册和注销。一种选择是服务实例进行自我注册，即自我注册模式。另一个选项是由其他一些系统组件来管理服务实例的注册，即第三方注册模式。首先让我们看一下自我注册模式。

自我注册模式

使用自我注册模式时，服务实例负责在服务注册表中进行自身注册和注销。另外，如果需要，服务实例会发送心跳请求以防止其注册过期。下图显示了此模式的结构。

img

Netflix OSS Eureka 客户端就是这种方法的一个很好的例子。Eureka 客户端处理服务实例注册和注销的所有方面。在春天的云项目，它实现了各种图案，包括服务发现，可以很容易地自动注册尤里卡服务实例。您只需使用注释对 Java Configuration 类进行@EnableEurekaClient 注释。

自注册模式具有各种优点和缺点。好处之一是它相对简单，不需要任何其他系统组件。但是，主要缺点是它将服务实例耦合到服务注册表。您必须以服务使用的每种编程语言和框架来实现注册码。

将服务与服务注册表分离的另一种方法是第三方注册模式。