服务发现的可行方案以及实践案例-4(转)

「Chris Richardson 微服务系列」服务发现的可行方案以及实践案例

Posted on 2016年5月25日

编者的话|本文来自 Nginx 官方博客,是微服务系列的第四篇文章。第一篇介绍了微服务架构的模式,讨论了使用微服务架构的优缺点;第二篇和第三篇描述了微服务架构内部的通讯机制。这篇文章中,我们将会探讨服务发现。

转自http://blog.daocloud.io/microservices-4/

作者介绍:Chris Richardson,是世界著名的软件大师,经典技术著作《POJOS IN ACTION》一书的作者,也是 cloudfoundry.com 最初的创始人,Chris Richardson 与 Martin Fowler、Sam Newman、Adrian Cockcroft 等并称为世界十大软件架构师。

Chris Richardson 微服务系列全 7 篇:

1. 微服务架构的优势与不足

2. 使用 API 网关构建微服务

3. 微服务架构中的进程间通信

4. 服务发现的可行方案以及实践案例

5. 微服务的事件驱动数据管理

6. 选择微服务部署策略

7. 将单体应用改造为微服务

Chris Richardson 所著所有文章已独家授权 DaoCloud 翻译并刊载。

本期内容:

为什么要使用服务发现?

假设我们写的代码会调用 REST API 或者 Thrift API 的服务。为了完成一次请求,代码需要知道服务实例的网络位置(IP 地址和端口)。运行在物理硬件上的传统应用中,服务实例的网络位置是相对固定的;代码能从一个偶尔更新的配置文件中读取网络位置。

对于基于云端的、现代化的微服务应用而言,这却是一大难题,正如下图所示。

服务实例的网络位置都是动态分配的。由于扩展、失败和升级,服务实例会经常动态改变,因此,客户端代码需要使用更加复杂的服务发现机制。

服务发现有两大模式:客户端发现模式和服务端发现模式。我们先来了解客客户端发现模式。

客户端发现模式

使用客户端发现模式时,客户端决定相应服务实例的网络位置,并且对请求实现负载均衡。客户端查询服务注册表,后者是一个可用服务实例的数据库;然后使用负载均衡算法从中选择一个实例,并发出请求。

客户端从服务注册服务中查询,其中是所有可用服务实例的库。客户端使用负载均衡算法从多个服务实例中选择出一个,然后发出请求。

下图显示了这种模式的架构:

服务实例的网络位置在启动时被记录到服务注册表,等实例终止时被删除。服务实例的注册信息通常使用心跳机制来定期刷新。

Netflix OSS 是客户端发现模式的绝佳范例。Netflix Eureka 是一个服务注册表,为服务实例注册管理和查询可用实例提供了 REST API 接口。Netflix Ribbon 是 IPC 客户端,与 Eureka 一起实现对请求的负载均衡。我们会在后面深入讨论 Eureka。

客户端发现模式优缺点兼有。这一模式相对直接,除了服务注册外,其它部分无需变动。此外,由于客户端知晓可用的服务实例,能针对特定应用实现智能负载均衡,比如使用哈希一致性。这种模式的一大缺点就是客户端与服务注册绑定,要针对服务端用到的每个编程语言和框架,实现客户端的服务发现逻辑。

分析过客户端发现后,我们来了解服务端发现。

服务端发现模式

另外一种服务发现的模式是服务端发现模式,下图展现了这种模式的架构:

客户端通过负载均衡器向某个服务提出请求,负载均衡器查询服务注册表,并将请求转发到可用的服务实例。如同客户端发现,服务实例在服务注册表中注册或注销。

AWS Elastic Load Balancer(ELB)是服务端发现路由的例子,ELB 通常均衡来自互联网的外部流量,也可用来负载均衡 VPC(Virtual private cloud)的内部流量。客户端使用 DNS 通过 ELB 发出请求(HTTP 或 TCP),ELB 在已注册的 EC2 实例或 ECS 容器之间负载均衡。这里并没有单独的服务注册表,相反,EC2 实例和 ECS 容器注册在 ELB。

HTTP 服务器与类似 NGINX PLUS 和 NGINX 这样的负载均衡起也能用作服务端的发现均衡器。Graham Jenson 的 Scalable Architecture DR CoN: Docker, Registrator, Consul, Consul Template and Nginx 一文就描述如何使用 Consul Template 来动态配置 NGINX 反向代理。Consul Template 定期从 Consul Template 注册表中的配置数据中生成配置文件;文件发生更改即运行任意命令。在这篇文章中,Consul Template 生成 nginx.conf 文件,用于配置反向代理,然后运行命令,告诉 NGINX 重新加载配置文件。在更复杂的实现中,需要使用 HTTP API 或 DNS 来动态配置 NGINX Plus。

Kubernetes 和 Marathon 这样的部署环境会在每个集群上运行一个代理,将代理用作服务端发现的负载均衡器。客户端使用主机 IP 地址和分配的端口通过代理将请求路由出去,向服务发送请求。代理将请求透明地转发到集群中可用的服务实例。

服务端发现模式兼具优缺点。它最大的优点是客户端无需关注发现的细节,只需要简单地向负载均衡器发送请求,这减少了编程语言框架需要完成的发现逻辑。并且如上文所述,某些部署环境免费提供这一功能。这种模式也有缺点。除非负载均衡器由部署环境提供,否则会成为一个需要配置和管理的高可用系统组件。

服务注册表

服务注册表是服务发现的核心部分,是包含服务实例的网络地址的数据库。服务注册表需要高可用而且随时更新。客户端能够缓存从服务注册表中获取的网络地址,然而,这些信息最终会过时,客户端也就无法发现服务实例。因此,服务注册表会包含若干服务端,使用复制协议保持一致性。

如前所述,Netflix Eureka 是服务注册表的上好案例,为注册和请求服务实例提供了 REST API。服务实例使用 POST 请求来注册网络地址,每三十秒使用 PUT 请求来刷新注册信息。注册信息也能通过 HTTP DELETE 请求或者实例超时来被移除。以此类推,客户端能够使用 HTTP GET 请求来检索已注册的服务实例。

Netflix 通过在每个 AWS EC2 域运行一个或者多个 Eureka 服务实现高可用性。每个 Eureka 服务器都运行在拥有弹性 IP 地址的 EC2 实例上。DNS TEXT 记录被用来保存 Eureka 集群配置,后者包括可用域和 Eureka 服务器的网络地址列表。Eureka 服务在启动时会查询 DNS 去获取 Eureka 集群配置,确定同伴位置,以及给自己分配一个未被使用的弹性 IP 地址。

Eureka 客户端,包括服务和服务客户端,查询 DNS 去发现 Eureka 服务的网络地址。客户端首选同一域内的 Eureka 服务。然而,如果没有可用服务,客户端会使用其它可用域中的 Eureka 服务。

其它的服务注册表包括:

  • etcd – 高可用、分布式、一致性的键值存储,用于共享配置和服务发现。Kubernetes 和 Cloud Foundry 是两个使用 etcd 的著名项目。
  • consul – 发现和配置的服务,提供 API 实现客户端注册和发现服务。Consul 通过健康检查来判断服务的可用性。
  • Apache ZooKeeper – 被分布式应用广泛使用的高性能协调服务。Apache ZooKeeper 最初是 Hadoop 的子项目,现在已成为顶级项目。

此外,如前所强调,像 Kubernetes、Marathon 和 AWS 并没有明确的服务注册,相反,服务注册已经内置在基础设施中。

了解了服务注册的概念后,现在了解服务实例如何在注册表中注册。

服务注册的方式

如前所述,服务实例必须在注册表中注册和注销。注册和注销有两种不同的方法。方法一是服务实例自己注册,也叫自注册模式(self-registration pattern);另一种是采用管理服务实例注册的其它系统组件,即第三方注册模式。

自注册方式

当使用自注册模式时,服务实例负责在服务注册表中注册和注销。另外,如果需要的话,一个服务实例也要发送心跳来保证注册信息不会过时。下图描述了这种架构:

Netflix OSS Eureka 客户端是非常好的案例,它负责处理服务实例的注册和注销。Spring Cloud 能够执行包括服务发现在内的各种模式,使得利用 Eureka 自动注册服务实例更简单,只需要给 Java 配置类注释 @EnableEurekaClient。

自注册模式优缺点兼备。它相对简单,无需其它系统组件。然而,它的主要缺点是把服务实例和服务注册表耦合,必须在每个编程语言和框架内实现注册代码。

另一个方案将服务与服务注册表解耦合,被称作第三方注册模式。

第三方注册模式

使用第三方注册模式,服务实例则不需要向服务注册表注册;相反,被称为服务注册器的另一个系统模块会处理。服务注册器会通过查询部署环境或订阅事件的方式来跟踪运行实例的更改。一旦侦测到有新的可用服务实例,会向注册表注册此服务。服务管理器也负责注销终止的服务实例。下面是这种模式的架构图。

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

NetflixOSS Prana 是另一个服务注册器,主要面向非 JVM 语言开发的服务,是一款与服务实例一起运行的并行应用。Prana 使用 Netflix Eureka 来注册和注销服务实例。

服务注册器是部署环境的内置组件。由 Autoscaling Group 创建的 EC2 实例能够自动向 ELB 注册。Kubernetes 服务自动注册并能够被发现。

第三方注册模式也是优缺点兼具。在第三方注册模式中,服务与服务注册表解耦合,无需为每个编程语言和框架实现服务注册逻辑;相反,服务实例通过一个专有服务以中心化的方式进行管理。它的不足之处在于,除非该服务内置于部署环境,否则需要配置和管理一个高可用的系统组件。

总结

在微服务应用中,服务实例的运行环境会动态变化,实例网络地址也是如此。因此,客户端为了访问服务必须使用服务发现机制。

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

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

服务实例的注册和注销也有两种方式。一种是服务实例自己注册到服务注册表中,即自注册模式;另一种则是由其它系统组件处理注册和注销,也就是第三方注册模式。

在一些部署环境中,需要使用 Netflix Eureka、etcd、Apache Zookeeper 等服务发现来设置自己的服务发现基础设施。而另一些部署环境则内置了服务发现。例如,Kubernetes 和 Marathon 处理服务实例的注册和注销,它们也在每个集群主机上运行代理,这个代理具有服务端发现路由的功能。

HTTP 反向代理和 NGINX 这样的负载均衡器能够用做服务器端的服务发现均衡器。服务注册表能够将路由信息推送到 NGINX,激活配置更新,譬如使用 Cosul Template。NGINX Plus 支持额外的动态配置机制,能够通过 DNS 从注册表中获取服务实例的信息,并为远程配置提供 API。

英文原文:https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/

This entry was posted in 干货 and tagged 微服务. Bookmark the permalink.

Post navigation

← 容器技术会最终取代虚拟化技术吗?十拿九稳!

Docker Swarm 集群管理性能全面碾压 Kubernetes →

8 thoughts on “「Chris Richardson 微服务系列」服务发现的可行方案以及实践案例”

原文地址:https://www.cnblogs.com/long2050/p/12079913.html

时间: 2024-11-08 06:45:21

服务发现的可行方案以及实践案例-4(转)的相关文章

微服务实战(四):服务发现的可行方案以及实践案例

这是关于使用微服务架构创建应用系列的第四篇文章.第一篇介绍了微服务架构的模式,讨论了使用微服务架构的优缺点.第二和第三篇描述了微服务架构内部的通讯机制.这篇文章中,我们将会探讨服务发现相关问题. 为什么要使用服务发现? 设想一下,我们正在写代码使用了提供REST API或者Thrift API的服务,为了完成一次服务请求,代码需要知道服务实例的网络位置(IP地址和端口).传统应用都运行在物理硬件上,服务实例的网络位置都是相对固定的.例如,代码可以从一个经常变更的配置文件中读取网络位置. 而对于一

Service 服务发现的两种方式-通过案例来理解

1.环境变量 在创建一个Pod时,kubelet在该Pod的所有容器中为当前所有Service添加一系列环境变量. 例如,已存在名称为"redis-master"的Service,它对外暴露6379的TCP端口,且集群IP为10.0.0.11.kubelet会为新建的容器添加以下环境变量: REDIS_MASTER_SERVICE_HOST=10.0.0.11 REDIS_MASTER_SERVICE_PORT=6379 通过环境变量来创建Service会带来一个不好的结果,即任何被某

服务发现之 Etcd VS Consul

抄自这里 ************************************************************************************************ 网上找来找去都是zk和etcd的比较,和consul的比较很少,这个感觉还算靠谱,也在别的地方看到过对consul的吐槽,记录下 ***********************************************************************************

微服务理论系列(一):服务发现四问四答

在开始之前,我们先来回顾下业内对于微服务架构的定义.简单来说,微服务就是用一组小服务的方式来构建一个应用,服务独立运行在不同的进程中,服务之间通过轻量的通讯机制(如 RESTful 接口)来交互,并且服务可以通过自动化部署方式独立部署. 1.什么是服务发现,在微服务架构中,服务发现的作用是什么? 之前做单体式应用开发时很少提及服务发现,因为传统单体应用动态性不强,不会频繁的更新和重新发布,也较少进行自动伸缩.传统单体应用的网络位置很少发生变化,在发生变化时,由运维人员手工更新一下它们的配置文件,

Istio技术与实践01: 源码解析之Pilot多云平台服务发现机制

服务模型 首先,Istio作为一个(微)服务治理的平台,和其他的微服务模型一样也提供了Service,ServiceInstance这样抽象服务模型.如Service的定义中所表达的,一个服务有一个全域名,可以有一个或多个侦听端口. type Service struct { // Hostname of the service, e.g. "catalog.mystore.com" Hostname Hostname `json:"hostname"` Addre

.Net微服务实践(五)[服务发现]:Consul介绍和环境搭建

目录 介绍 服务发现 健康检查.键值存储和数据中心 架构 Consul模式 环境安装 HTTP API 和Command CLI 示例API介绍 最后 在上篇.Net微服务实践(四)[网关]:Ocelot限流熔断.缓存以及负载均衡中介绍Ocelot的限流.熔断.缓存.负载均衡以及其他一些特性,Ocelot的基本配置和功能都已经介绍完了.本篇我们会介绍服务发现Consul. 介绍 Consul是一款简单.易用.可伸缩性强的服务治理系统.主要核心功能有:服务发现.健康检查.键值存储和多数据中心. 服

DDD实践案例:引入事件驱动与中间件机制来实现后台管理功能

DDD实践案例:引入事件驱动与中间件机制来实现后台管理功能 一.引言 在当前的电子商务平台中,用户下完订单之后,然后店家会在后台看到客户下的订单,然后店家可以对客户的订单进行发货操作.此时客户会在自己的订单状态看到店家已经发货.从上面的业务逻辑可以看出,当用户下完订单之后,店家或管理员可以对客户订单进行跟踪和操作.上一专题我们已经实现创建订单的功能,则接下来自然就是后台管理功能的实现了.所以在这一专题中将详细介绍如何在网上书店案例中实现后台管理功能. 二.后台管理中的权限管理的实现 后台管理中,

服务发现系统etcd介绍

一.概述 etcd是一个高可用的键值存储系统,主要用于共享配置和服务发现.etcd是由CoreOS开发并维护的,灵感来自于 ZooKeeper 和 Doozer,它使用Go语言编写,并通过Raft一致性算法处理日志复制以保证强一致性.Raft是一个新的一致性算法,适用于分布式系统的日志复制,Raft通过选举的方式来实现一致性,在Raft中,任何一个节点都可能成为Leader.Google的容器集群管理系统Kubernetes.开源PaaS平台Cloud Foundry和CoreOS的Fleet都

微服务架构下的服务发现

编者的话]这是关于使用微服务架构创建应用系列的第四篇文章.第一篇介绍了微服务架构的模式,讨论了使用微服务架构的优缺点.第二和第三篇描述了微服务架构内部的通讯机制.这篇文章中,我们将会探讨服务发现相关问题. 为什么要使用服务发现? 我们设想一下当正在写代码时,使用了提供REST API或者Thrift API的服务,为了完成一次服务请求,代码需要知道服务实例的网络位置(IP地址和端口).传统应用都运行在物理硬件上,服务实例的网络位置都是相对固定的.例如,代码可以从一个经常变更的配置文件中读取网络位