精通springcloud：服务发现，Eureka API，副本和高可用性

Posted 2021-05-23 jinggege795

Eureka API

Spring Cloud Netflix 提供了一个用Java编写的客户端，它隐藏了开发人员的Eureka HTTP API。如果开发人员使用除Spring之外的其他框架，则Netflix OSS提供了一个可以作为依赖项包含的普通Eureka客户端。但是，开发人员很容易就能想到一些需要直接调用Eureka API的情况。例如，如果应用程序是使用除Java之外的其他语言编写的，或者开发人员在持续交付(Continuous Delivery)过程中需要已注册服务列表之类的信息，这些都需要直接调用EurekaAPI。表4.1 提供了Eureka API的快速参考。

 

 

副本和高可用性

前文已经讨论了一些有用的Eureka设置，但是到目前为止，我们只分析了一个具有单台服务发现服务器的系统。这样的配置虽然是有效的，但仅限于开发模式。对于生产模式来说，至少需要运行两台发现服务器，以防其中- -台发生故障或发生网络问题。根据定义，Eureka 是为可用性(Availability) 和弹性( Resiliency)而构建的，这是Netlix开发的两个主要支柱，但它不提供标准的集群机制，如领导选举或自动加入集群。它基于对等复制模型。这意味着所有服务器都复制数据并将心跳发送到所有对等体，这些对等体在当前服务器节点的配置中设置。这种算法对于包含数据简单而有效，但它也有一些缺点。它限制了可伸缩性，因为每个节点都必须承受服务器上的整个写入负载。

 

样本解决方案的架构

有趣的是，副本( Replication)机制是开发人员开始使用新版Eureka Server的主要动机之一。Eureka 2.0目前仍在积极开发中。除了优化的副本机制之外，它还将提供一些有趣的功能，如从服务器到客户端的推送模型(用于推送注册列表中的任何更改)、自动扩展的服务器和丰富的仪表板等。这个解决方案似乎很有实践意义，但Spring Cloud Nettlix使用的仍然是版本1. 说实话，我们尚未发现任何迁移到版本2的计划，目前Dalure.SR4版本列车的Eureka版本是1.6.2. 服务器端的集群机制的配置可以归结为一件事，即使用eureka.client.* 属性部分设置另一个发现服务器的URL. 所选定的服务器将只会在其他服务器中注册自己，而这些服务器将被选为已创建集群的一部分。要显示该解决方案在实践中的工作原理，最佳方式当然是通过示例。

现在就让我们从示例系统的架构开始。如图4.7所示，我们所有的应用程序都将在不同的端口上以本地方式运行。在此阶段，我们必须介绍基于Netlix Zuul的API网关示例，这对于进行负载均衡测试是有帮助的。本示例将测试在不同区域(Zone) 中注册的服务的3个实例之间的负载均衡。

 

构建示例应用程序

对于Eureka Server来说，可以在配置属性中定义所有必需的更改。在application.yml文件中，我们为发现服务的每个实例定义了3个不同的配置文件。现在，如果要尝试运行嵌入在Spring Boot应用程序中的Eureka Server,则需要通过提供VM参数_Dspring.profiles.active-peer[n]来激活特定的配置文件，其中，[n]是实例的顺序编号。

spring:

profiles: peerl

eureka :

instance:

hostname: peer1

metada taMap :

zone: zone 1

client:

serviceUr1:

de faultZone:

http://localhost:8762/eureka/ , http://localhost:8763/eureka/

server:

port: ${PORT:8761}

---

spring:

profiles: peer2

eureka :

instance :

hos tname: peer2

metadataMap:

zone: zone2

client:

serviceUrl :

defaultZone:

http://localhost:8761/eureka/，http://localhost:8763/eureka/

server:

port: ${PORT:8762 }

spring:

profiles: peer3

eureka:

instance:

hostname: peer3

metadataMap :

zone: zone3

client:

serviceUrl:

de faultZone :

http://localhost:8761/eureka/ ,http://localhost:8762/eureka/

server:

port: ${PORT:8763}

在使用不同的配置文件名运行所有3个Eureka实例后，我们就已经创建了一个本地发现集群。如果在启动后查看任何实例的Eureka仪表板，那么它看起来始终是一样的，我们可以看到3个DISCOVERY-SERVICE实例，如图4.8所示。

 

下一步是运行客户端应用程序。项目中的配置设置与使用Eureka Server 的应用程序的配置设置非常相似。defaultZone字段中提供的地址顺序决定了对不同发现服务的连接尝试的顺序。如果无法建立与第一个服务器的连接，那么它将尝试从列表中连接第二个服务器，以此类推。与前文所述一 样， 开发人员应该设置VM参数Dspring.profiles active =zone[n]来选择正确的配置文件。这里还建议设置-Xmx192m参数。请记住，我们要在本地测试所有服务，如果没有为Spring Cloud应用程序设置任何内存限制，则启动后消耗大约350MB的堆，并且总的内存使用大约为600MB。除非计算机上有大量内存，否则很难在本地机器上运行多个微服务实例。

spring:

profiles: zone1

eureka:

client:

serviceUrl:

defaultZone:

http://localhost:8761/eureka/. http://localhost:8762/eureka/ , http://1ocalhost:

8763/eureka/

server:

port: $(PORT:80817

spring:

profiles: zone2

eureka:

client:

serviceUrl:

defaultZone:

http://1ocalhost:8762/eureka/.http://localhost:8761/eureka/ , http://localhost:

8763/eureka/

server :

port: ${PORT:8082}

spring:

profiles: zone3

eureka:

client:

serviceurl:

defaultZone:

http://localhost:8763/eureka/ , http://localhost: 8761/eureka/，http://localhost:

8762/eureka/

server:

port: ${PORT:8083}

现在再来看一下Eureka仪表板。尽管应用程序最初只连接到发现服务的一个实例，但我们在任何地方都注册了3个客户端服务实例。无论进入哪个发现服务实例的仪表板，结果都是相同的。这就是该练习的确切目的。现在可以创建一些额外的实现以证明一切都已如预期一样工作，如图4.9所示。

 

客户端应用程序除了将打印所选配置文件名称的REST端点公开之外并无其他操作。配置文件名称指向特定应用程序实例的主发现服务实例。以下@RetController实现非常简单，它将打印当前区域的名称。

eRestController

public class ClientController {

@Value ("S {spring.profiles}")

private String zone;

@GetMapping("/ping")

public String ping() {

return "I'm in zone”+ zone;

最后，开发人员可以继续实现API网关。当然，详细介绍Zuul、Netlix 的API网关和路由器提供的功能超出了本章的范围( 后续章节将对此展开详细的讨论)。Zuul 现在将有助于测试我们的示例解决方案，因为它能够检索在发现服务器中注册的服务列表，并在客户端应用程序的所有正在运行的实例之间执行负载均衡。正如以下配置片段所示，开发人员可以使用侦听端口8763的发现服务器。所有包含/api/clien/**路径的传入请求都将路由到client-service.

zuul:

prefix: /api

routes:

client:

path: /client/**

serviceId: client-service

eureka:

client:

serviceUrl:

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

registerWithEureka: false

现在来继续进行测试。开发人员可以使用java -jar命令启动Zuul代理(Proxy) 的应用程序，与以前的服务 不同，这次不需要设置任何其他参数，包括配置文件名称。默认情况下，它将与编号#3的发现服务连接。要通过Zuul代理调用客户端API，开发人员必须在Web浏览器中输入以下地址
ht://o/alhost:8765/apiclientping. 其结果如图4.10所示。

 

如果连续多次重试请求，则应按1:1:1 的比例在所有现有client-service实例之间进行负载均衡，尽管我们的网关仅连接到编号#3的发现服务。此示例完整演示了如何使用多个Eureka实例构建服务发现。

上述示例应用程序可在GitHub (tps:/github com/piomin/sample spring coud-netlix.git)上的cluster'分支(tps:/github con/piomin/sample spring- cou-.titree/clusterr _no zones)中获得。

故障转移

也许有读者会问:如果一个服务发现实例发生故障会怎么样呢?为了检查集群在发生故障时的行为方式，不妨稍微修改一下之前的示例。现在，Zuul 具有一个故障转移(Failover)连接，它可以连接到其配置设置中设置的端口8762.上可用的第二个服务发现。出于测试目的，可以关闭端口8763上可用的第三个发现服务实例。

eureka:

client:

serviceUrl :

de faultZone :

http://localhost :8763/eureka/，http://localhost:8762/eureka/

registerwithEureka: false

目前的情况如图4.11所示。通过调用
ht//alhost:8765/apiclientping 地址下可的网关端点，可以按与先前相同的方式执行测试。其结果也与之前的测试相同，负载均衡在所有3个客户端服务实例中按预期平均执行。虽然已禁用发现服务#3，但是其他两个实例仍然能够相互通信，并且只要它是活动的，就可以获得有关从实例#3复制的第3个客户端应用程序实例的网络位置的信息。现在，即使重新启动网关，它仍然能够按顺序使用第二个地址连接发现集群(这是在ht:t/ocalhost:/762/urekae的defaultZone字段中设置的)。这同样适用于客户端应用程序的第3个实例，而第3个实例又会将发现服务#1作为备份连接。

 

总结

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

扫码来获取就可以了！