精通springcloud：服务发现，如何使用Eureka的区域机制

Posted 2021-05-23 jinggege795

区域

在大多数情况下，基于集群(Cluster)的对等复制模型(Peer-to-Peer Replication Model)是一种很好的方式，但并不总是够用。Eureka 还有一个更有趣的功能，在集群环境中非常有用。事实上，区域机制(Zone Mechanism)是其默认行为。即使开发人员有一个独立的服务发现实例，每个客户端的属性也必须在配置设置中将其设置为
eureka.client.serviceUrl.defaultZone。 这在什么时候对我们很有用呢?为了分析清楚，不妨回到之前的示例。假设现在我们的环境分为3个不同的物理网络，或者只有3台不同的机器处理传入的请求。

 

当然，发现服务仍然在逻辑上分组在集群中，但每个实例都放在一个单独的区域中。每个客户端应用程序都将在与其主发现服务器相同的区域中注册。我们将启动3个实例(而不是Zuul网关的一个实例) ，每个实例用于一个区域。如果请求进入网关，那么它所选择的客户端应该在尝试调用另一个区域中注册的服务之前，优先利用同一区域内的服务。如图4.12 所示是当前系统架构的可视化示意图。当然，出于示例目的，该架构被简化为能够在单台本地机器上运行。在现实世界中，正如前文所述，它将在3台不同的机器上运行，甚至在3组不同的机器上启动，从物理上分隔为其他网络。

 

具有独立服务器的区域

在本阶段，我们应该强调一件重要的事情，即分区机制只在客户端实现。这意味着服务发现实例未指定给任何区域。因此，图4.12可能会让开发人员略微产生一些混淆，但它指出了哪个Eureka是在特定区域中注册的所有客户端应用程序和网关的默认服务发现。我们的目的是检查高可用性模式中的机制，但我们也可以仅使用单个发现服务器来构建它。图4.13 演示了与图4.12类似的情况，但它假定所有应用程序只存在-一个发现服务器。

 

构建示例应用程序

要启用区域处理机制，开发人员需要在客户端和网关的配置设置中执行一些更改。以下是客户端应用程序中修改后的application.yml文件。

spring:

profiles: zone1

eureka:

instance:

metadataMap:

zone: zone1

client:

serviceUrl:

defaultZone :

http://localhost:8761/eureka/，http://localhost:8762/eureka/，http://localhost:

8763/eureka/

唯一需要更新的是
eureka.instance.metadataMap.zone属性，在该属性中可以设置区域的名称和已经注册的服务。

在网关配置中还必须进行更多更改。首先，需要添加3个配置文件，以便能够运行在3个不同的区域和3个不同的发现服务器中注册的应用程序。现在，在启动网关应用程序时，开发人员应该设置VM参数-Dspring profiles. active = zone[n]以选择正确的配置文件。

 

与client-service类似，开发人员还必须在配置设置中添加eureka.instance metadataMap.zone属性。还有一个属性eureka client preferSameZoneEureka也值得一提， 这是在示例中第一次使用的，如果网关应该优先选择在同一区域中注册的客户端应用程序的实例，则该属性必须等于true。

spring:

profiles: zonel

eureka:

client:

serviceUrl:

defaultZone: http://localhost:8761/eureka/

---

registerWithEureka: false

preferSameZoneEureka: true

instance:

metadataMap :

zone: zonel

server:

port: ${PORT:8765}

spring:

profiles: zone2

eureka:

client:

serviceUrl:

defaultZone: http:// localhost:8762/eureka/

registerWithEureka: false

preferSameZoneEureka: true

instance:

metadataMap:

zone: zone2

server:

port: ${PORT:8766}

---

spring:

profiles: zone3

eureka:

client:

serviceUrl:

defaultZone: http://localhost:8763/eureka/

registerWithEureka: false

preferSameZoneEureka: true

instance:

metadataMap:

zone: zone3

server:

port: ${PORT:8767}

在启动发现，客户端和网关应用程序的所有实例后，开发人员可以尝试调用在
htp:/ocaho/:87/a/iclient/pig、ht:t:o/766/apiclient/pingig 和ht:t:oclhosthht8767/api/client/ping地址下可用的端点。它们中的每一个都将始终与在同一区域中注册的客户端实例进行通信。因此，与没有首选区域的测试不同，端口8765下可用的第一个网关实例将始终在调用ping端点时显示I'minzonezone1，如图4.14所示。

 

当客户端编号#1不可用时会发生什么呢?传入请求将在客户端应用程序的两个其他实例之间进行50/50的负载均衡，因为它们都位于与网关#1不同的区域中。

 小结

本章首次使用了Spring Cloud开发应用程序。在笔者看来，学习使用微服务框架的最佳方法是尝试了解如何正确实现服务发现。本章从最简单的用例和示例开始，全面介绍了Netlix OSS Eureka项目提供的高级功能和可直接应用于生产模式的功能。本章展示了如何在5分钟内创建和运行基本客户端和独立发现服务器。基于该实现，本章还介绍了如何自定义Eureka客户端和服务器以满足开发人员的特定需求，并且重点讨论了网络或应用程序故障等负面情况的应对。本章还详细讨论了REST API或用户界面仪表板等功能。最后，本章还演示了如何使用Eureka的机制( 如副本、区域和高可用性等)创建可用于生产模式的环境。有了这些知识，开发人员就应该能够正确选择Eureka的功能，并通过这些功能构建适应基于微服务架构要求的服务发现。

 

在掌握了服务发现之后，开发人员即可进入基于微服务的体系结构中的下一个基本元素，即配置服务器。发现和配置服务通常都基于键/值存储，因此它们可以使用相同的产品提供。但是，由于Eureka仅专注于发现，所以Spring Cloud引入了自己的框架SpringCloud Config来管理分布式配置。

总结

因为文章包含的内容实在是太多了，就不给大家做过多的介绍了，需要这份文档来学习的小伙伴，可以转发此文关注小编。

扫码来获取就可以了！