之前的内容重点都是在讲构建微服务，但是这节都是关于构建系统，同样，一个微服务并不能提供服务--它们是通过系统来实现的。当您采用微服务架构风格时，您将拥有数十个微服务。像我们在上一章中所做的那样，管理两个微服务是很容易的。您使用的微服务越多，应用程序就越复杂。
首先，我们将学习如何使用服务发现来解决位置透明性和移动性问题。然后，我们将讨论恢复力和稳定性模式，如超时、中断和故障。
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/
有什么讨论的内容，可以加我微信公众号：
