关于微服务架构下的服务注册与发现

服务发现

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

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

Service discovery is difficult in a modern, cloud-based microservices application because the set of instances, and their IP addresses, are subject to constant change

 

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

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

The Client‑Side Discovery Pattern客户端服务发现

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

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

With client-side service discovery, the client determines the network locations of available service instances and load balances requests across them

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

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

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

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

The Server‑Side Discovery Pattern服务端发现模式

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

With the server-side service discovery, the load balancer queries a service registry about service locations; clients interact only with the load balancer

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

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

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

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

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

The Service Registry服务注册

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

如前所述,Netflix Eureka是服务注册表的一个很好的例子。它提供了一个REST API,用于注册和查询服务实例。服务实例使用POST请求注册其网络位置。它必须每30秒使用PU

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值