这七个系列的文章现在完成:

  1. 微服务介绍
  2. 构建微服务:使用API​​网关
  3. 构建微服务:微服务架构中的进程间通信
  4. 微服务架构中的服务发现(本文)
  5. 事件驱动的数据管理微服务
  6. 选择微服务部署策略
  7. 将重组重构为微服务

您还可以下载完整的文章集,以及使用NGINX Plus实现微服务的信息,作为电子书 -微服务:从设计到部署

这是我们关于使用微服务构建应用程序的第四篇文章。在第一篇文章介绍了微服务架构模式和讨论的好处和使用微服务的缺点。的第二第三系列中的文章描述了一个微服务架构内的通信的不同方面。在本文中,我们探讨密切相关的服务发现问题。

为什么使用服务发现?

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

然而,在现代的基于云的微服务应用程序中,这是一个更难解决的问题,如下图所示。

服务实例具有动态分配的网络位置。此外,服务实例集合由于自动缩放,故障和升级而动态地改变。因此,您的客户端代码需要使用更精细的服务发现机制。

有两种主要的服务发现模式:客户端发现服务器端发现。让我们先来看看客户端发现。

客户端发现模式

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

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

服务实例的网络位置在启动时向服务注册表注册。当实例终止时,它将从服务注册表中删除。通常使用心跳机制周期性地刷新服务实例的注册。

Netflix OSS提供了客户端发现模式的一个很好的例子。Netflix Eureka是一个服务注册表。它提供了一个用于管理服务实例注册和查询可用实例的REST API。Netflix功能区是一个IPC客户端,与Eureka一起工作,在可用的服务实例之间进行负载均衡请求。我们将在本文后面更深入地讨论Eureka。

客户端发现模式具有各种好处和缺点。这种模式相对直接,除了服务注册表,没有其他移动部分。此外,由于客户端知道可用的服务实例,它可以做出智能的,特定于应用程序的负载平衡决策,例如一致地使用哈希。这种模式的一个显着缺点是它将客户端与服务注册表耦合。您必须为服务客户端使用的每种编程语言和框架实现客户端服务发现逻辑。

现在我们已经研究了客户端发现,让我们来看看服务器端发现。

服务器端发现模式

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

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

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

HTTP服务器和负载均衡器(如NGINXPlus和NGINX)也可用作服务器端发现负载均衡器。例如,本博客文章描述了使用Consul Template来动态重新配置NGINX反向代理。Consul模板是一种工具,它定期从存储在Consul服务注册表中的配置数据重新生成任意配置文件。每当文件更改时,它运行一个任意的shell命令。在博客文章描述的示例中,Consul Template生成一个nginx.conf文件,该文件配置反向代理,然后运行一个命令,告诉NGINX重新加载配置。

一些部署环境(如KubernetesMarathon)在集群中的每个主机上运行代理。代理扮演服务器端发现负载均衡器的角色。为了对服务进行请求,客户机使用主机的IP地址和服务的分配端口经由代理路由请求。然后,代理将该请求透明地转发到在集群中某处运行的可用服务实例。

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

服务注册表

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

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

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

Eureka客户端 - 服务和服务客户​​端 - 查询DNS以发现Eureka服务器的网络位置。客户端更喜欢在同一可用区域中使用Eureka服务器。但是,如果没有可用区域,则客户端在另一个可用区域中使用Eureka服务器。

服务注册管理机构的其他示例包括:

  • etcd
    • 用于共享配置和服务发现的高可用性,分布式,一致的键值存储。 使用etcd的两个值得注意的项目是Kubernetes和 Cloud Foundry
  • 领事 -一种用于发现和配置服务的工具。 它提供了一个API,允许客户端注册和发现服务。 领事可以执行健康检查以确定服务可用性。
  • Apache Zookeeper
    • 用于 分布式 应用程序的广泛使用的高性能协调服务。 Apache Zookeeper最初是Hadoop的子项目,但现在是一个顶级项目。

此外,如前所述,一些系统(如Kubernetes,Marathon和AWS)没有明确的服务注册表。相反,服务注册表只是基础结构的内置部分。

现在我们已经看了服务注册表的概念,让我们看看服务实例如何注册到服务注册表。

服务注册选项

如前所述,服务实例必须向服务注册表注册和注销。有两种不同的方式来处理注册和注销。一个选项是服务实例注册自己,注册模式。另一个选项是对于某些其他系统组件来管理服务实例的注册,第三方注册模式。让我们先来看看自我注册模式。

自注册模式

当使用自注册模式时,服务实例负责向服务注册表注册和注销自身。此外,如果需要,服务实例发送心跳请求以防止其注册到期。下图显示了此模式的结构。

这种方法的一个很好的例子是Netflix OSS Eureka客户端。Eureka客户端处理服务实例注册和注销的所有方面。在春天的云项目,它实现了多种模式,包括服务发现,可以很容易地与尤里卡自动注册服务实例。您只需用注释注释您的Java配置类@EnableEurekaClient

自注册模式具有各种益处和缺点。一个好处是它相对简单,并且不需要任何其他系统组件。然而,主要的缺点是它将服务实例耦合到服务注册表。您必须在您的服务使用的每种编程语言和框架中实现注册码。

将服务与服务注册表分离的替代方法是第三方注册模式。

第三方注册模式

当使用第三方注册模式时,服务实例不负责向服务注册表注册自己。相反,被称为服务注册器的另一个系统组件处理注册。服务注册器通过轮询部署环境或订阅事件来跟踪对运行实例集的更改。当它注意到新的可用服务实例时,它向服务注册表注册该实例。服务注册器还注销终止的服务实例。下图显示了此模式的结构。

服务注册器的一个示例是开源注册器项目。它自动注册和注销部署为Docker容器的服务实例。注册器支持多个服务注册表,包括etcd和Consul。

服务注册商的另一个例子是NetflixOSS Prana。主要用于以非JVM语言编写的服务,它是与服务实例并行运行的边路应用程序。Prana使用Netflix Eureka注册和注销服务实例。

服务注册器是部署环境的内置组件。由Autoscaling组创建的EC2实例可以自动注册到ELB。Kubernetes服务自动注册并可用于发现。

第三方注册模式具有各种好处和缺点。主要优点是服务与服务注册表断开连接。您不需要为开发人员使用的每种编程语言和框架实现服务注册逻辑。相反,在专用服务内以集中方式处理服务实例注册。

这种模式的一个缺点是,除非它内置在部署环境中,它是另一个高度可用的系统组件,您需要设置和管理。

概要

在微服务应用程序中,运行服务实例集会动态更改。实例具有动态分配的网络位置。因此,为了使客户机向服务发出请求,它必须使用服务发现机制。

服务发现的关键部分是服务注册表。服务注册表是可用服务实例的数据库。服务注册表提供了管理API和查询API。服务实例使用管理API从服务注册表注册和注销。系统组件使用查询API来发现可用的服务实例。

有两种主要的服务发现模式:客户端发现和服务端发现。在使用客户端服务发现的系统中,客户端查询服务注册表,选择可用实例,并发出请求。在使用服务器端发现的系统中,客户端通过路由器进行请求,路由器查询服务注册表并将请求转发到可用实例。

服务实例有两种主要方式向服务注册表注册和注销。一个选项是服务实例向服务注册表注册自己的自注册模式。另一个选项是用于一些其他系统组件代表服务处理注册和注销,第三方注册模式

在某些部署环境中,您需要使用服务注册表(如Netflix EurekaetcdApache Zookeeper)设置自己的服务发现基础结构。在其他部署环境中,内置了服务发现。例如,KubernetesMarathon处理服务实例注册和注销。他们还在担任服务器端发现路由器角色的每个群集主机上运行代理。

HTTP反向代理和负载平衡器(如NGINX)也可以用作服务器端发现负载平衡器。服务注册表可以将路由信息推送到NGINX并调用优雅的配置更新;例如,您可以使用领事模板NGINXPlus支持附加的动态重新配置机制 - 它可以使用DNS从注册表中提取有关服务实例的信息,并为远程重新配置提供API。

在将来的博客文章中,我们将继续深入了解微服务的其他方面。注册NGINX邮件列表(表格如下),以通知系列中未来的文章的发布。

这七个系列的文章现在完成:

  1. 微服务介绍
  2. 构建微服务:使用API​​网关
  3. 构建微服务:微服务架构中的进程间通信
  4. 微服务架构中的服务发现(本文)
  5. 事件驱动的数据管理微服务
  6. 选择微服务部署策略
  7. 将重组重构为微服务

您还可以下载完整的文章集,以及使用NGINX Plus实现微服务的信息,作为电子书 -微服务:从设计到部署

results matching ""

    No results matching ""