响应式微服务 in java 译 <十二> service discovery

以前的内容重点都是在讲构建微服务，可是这节都是关于构建系统，一样，一个微服务并不能提供服务--它们是经过系统来实现的。当您采用微服务架构风格时，您将拥有数十个微服务。像咱们在上一章中所作的那样，管理两个微服务是很容易的。您使用的微服务越多，应用程序就越复杂。

首先，咱们将学习如何使用服务发现来解决位置透明性和移动性问题。而后，咱们将讨论恢复力和稳定性模式，如超时、中断和故障。

Service Discovery

当你有一组微服务时，你必须回答的第一个问题是：这些微服务将如何相互定位？为了与另外一个对等方通讯，微服务须要知道其地址。正如咱们在上一章中所作的那样，咱们能够在代码中硬编码地址(事件总线地址、URL、位置细节等)，或者将其外部化为配置文件。然而，这种解决方案不能有移动性。您的应用程序将至关严格，不一样的部分将没法移动，这与咱们试图经过微服务实现的目标相矛盾。

Client- and Server-Side Service Discovery

微型服务须要是可移动的，但也是可寻址的。消费者须要可以与微服务进行通讯，而无需事先知道其确切位置，特别是由于这个位置可能会随着时间的推移而改变。位置透明性提供了弹性和动态性：消费者可使用循环策略调用不一样的微服务实例，在两次调用之间，Microservice可能已被移动或更新。

位置透明性能够经过一种称为服务发现的模式来解决。每一个微服务都应该公布如何调用它及其特性，固然包括它的位置，还应该公布其余元数据，如安全策略或版本。这些公告存储在服务发现基础结构中，该基础结构一般是由执行环境提供的服务注册中心。微型服务还能够决定将其服务从注册表中撤回。一个寻找另外一个服务的微服务也能够搜索这个服务注册中心以找到匹配的服务，选择最好的服务(使用任何类型的标准)，而后开始使用它。

可使用两种类型的模式来使用服务。当使用客户端服务发现时，使用者服务根据服务注册表中的名称和元数据查找服务，选择匹配的服务并使用它。从服务注册中心检索的引用包含指向微服务的直接连接。因为微服务是动态实体，服务发现基础设施不只必须容许提供者发布其服务，并且容许使用者查找服务，同时也提供了有关航班抵达和离开的信息。当使用客户端服务发现时，服务注册中心能够采起各类形式，例如分布式数据结构、专用的基础设施(如Consul)，或者存储在库存服务中，例如ApacheZooKeeptor或Redis。

或者，您可使用服务器端服务发现，让负载均衡器、路由器、代理或API网关为您管理发现(图4-2)。使用者仍然根据服务的名称和元数据查找服务，但检索虚拟地址。当使用者调用服务时，请求被路由到实际实现。您能够在Kubernetes或使用AWS弹性负载均衡器时使用此机制。

Vert.x Service Discovery

Vert.x提供了一种可扩展的服务发现机制。您可使用相同的API使用客户端或服务器端服务发现。那个Vert.x发现能够从许多类型的服务发现基础设施(如Consuer或Kubernetes)导入或导出服务(图4-3)。它也能够在没有任何专用服务发现基础设施的状况下使用。在这种状况下，它使用Vert集群上共享的分布式数据结构。

 

您能够按类型检索服务，以使已配置的服务客户端能够随时使用。服务类型能够是HTTP端点、事件总线地址、数据源等。例如，若是您想检索咱们在上一章中实现的名为hello的HTTP端点，您能够编写如下代码：

检索到的WebClient配置了服务位置，这意味着您能够当即使用它来调用服务。若是您的环境使用客户端发现，则配置的URL将针对服务的特定实例。若是使用服务器端发现，则客户端使用虚拟URL。

根据您的运行时基础结构，您可能必须注册您的服务。可是在使用服务器端服务发现时，一般没必要这样作，由于在部署服务时声明了服务。不然，您须要显式地发布服务。要发布服务，须要建立包含服务名称、位置和元数据的记录：

服务发现是微服务基础结构中的一个关键组件。它使动态、位置透明性和流动性成为可能。当处理一小部分服务时，服务发现可能看起来很麻烦，但当系统增加时，这是必须的。那个Vert.x服务发现为您提供了惟一的API，而无论您使用的基础结构和服务发现类型如何。然而，当你的系统增加时，还有另外一个指数增加的变量--失败

 

原文地址：

https://developers.redhat.com/promotions/building-reactive-microservices-in-java/

有什么讨论的内容，能够加我微信公众号：