本文概览:介绍了eureka的集群搭建:单机房和双机房

1 Eureka单机房集群搭建

相对于单点部署这里需要修改配置文件。比如存在3个机器 host1host2host3。配置如下:

host1的配置如下:

host2的配置

host3的配置

这里有个偷懒的地方就是,就是三台机器的eureka.client.serviceUrl.defaultZone配置都指定三台机器,可能启动时候会报错,但是没影响。

当Eureka-Server由单点变为集群时,对于Eureka-Client的变更,就是在配置中增加如下配置

 

2  Eureka双机房集群搭建

为了保证服务稳定性,我们经常将服务划分为2个逻辑机房。通过Regionzone实现划分多机房和同机房访问。比如服务A调用服务B,可以实现A服务优先访问同机房的服务B,避免跨机房影响访问时间。如下涉及到6个服务,每个机房各有三个服务:注册中心eureka、网关gateway、客户端服务client

83712797

2.1 配置信息

1server配置

1server-zone1

(2)server-zon2

2clinet配置

1client-zone1

(2) client-zone2

3、gateway

(1)gateway-zone1

(2)gateway-zone2

4、运行服务之后

发现在一个机房注册中心页面上可以看到所有服务的实例,不仅仅是同机房的。如下:

(1) zone1的注册中心

2

(2) zone2的注册中心

3

2.2 测试代码

通过网关访问一个服务时,需要验证下网关否可以访问同机房的服务,而不会跨机房。

client中增加如下代码

通过zone1的网关服务访问provider服务,此时调用的provider服务也是zone1

11

通过zone2的网关服务访问provider服务,此时调用的provider服务也是zone2

11

2.3 多机房总结

1一定要注意 availability-zones 的顺序,当前实例所属zone 写在最前面

2、在使用逻辑机房时,已经配置了eureka.client.service-url.zon1eureka.client.service-url.zone2。是否还需要eureka.client.service-url.default

1)结论:只有在根据zone查找服务实例为空时,才会使用eureka.client.service-url.default

有这种场景会用到,我们配置了这两个属性

但是并没有配置eureka.client.service-url.zone1和eureka.client.service-url.zone2,

只有一个defalut配置

2)分析:只有在根据zone查找服务实例为空时,才会使用eureka.client.service-url.default

根据配文件加载注册中心地址的地址信息,会根据zone生成一个map。如下:

getEurekaServerServiceUrls负责根据一个zone查找一实例地址,在如下代码中可以看到:当根据zone查找服务实例为空时,才会使用eureka.client.service-url.default

3、启动多个注册中心后,节点均出现在unavailable-replicas

dd

问题原因是:因为注册中心都在一台机器部署,分别部署到2台机器上就没有问题了

3 Eureka集群多机房属性

总结:

介绍了基于Eureka的微服务划分机房的两类属性,即 customer/注册中心同机房调用属性    customer/server同机房调用属性。通过这两种属性可以实现两种双机房策略。

3.1 划分机房的两类属性

1、配置客户端/注册中心同机房属性

获取eureka地址用到的属性。保证eureka注册中心区分机房,实现客户端和注册中心同机房即保证客户方服务可以在服务注册、服务查询时,获取到同机房的eurka实例。如果不区分,一个机房网A络有问题了,机房B通过机房A的注册中心获取一个server的地址时,就报错了,所以同机房策略,可以保证客户端访问注册中心在同一个机房。

  • 对于服务注册时,可以保证客户端服务调用到同一个zone的eureka注册中心实例来进行注册。
  • 对于服务查询时,可以获取到同一个zone的eureka注册中心实例。

(1)availability-zones

为了保证服务注册到同一个 zone 的注册中心,一定要注意 availability-zones 的顺序,必须把同一 zone 写在最前面

(2) prefer-same-zone-eureka

如果 prefer-same-zone-eureka 为true,先通过 region 取 availability-zones 内的第一个zone,然后通过这个zone取 service-url 下的list,并向list内的第一个注册中心进行注册和维持心跳,不再向list内的其它的注册中心注册和维持心跳。

(3)service-url

2、customer/server同机房调用属性

customer查询server的路由策略的属性。 保证customerServer区分机房实现customer和server同机房访问

(1)eureka.instance.metadata-map.zone

可以保证customer和server属于同一个机房。

3.2 使用上面属性配置双机房策略

1、策略1只使用eureka.instance.metadata-map.zone 。使用默认的 service-url.default  属性

eureka地址不需要再划分机房了,只需要customer查询server的划分机房。这样可能存在问题是,如果一个机房网A络有问题了,可能调用A获取server的地址时,就报错了

1

2、策略2  同时使用两种属性。使用eureka.instance.metadata-map.zone    service-url.zone1、eureka.client.availability-zones.xxx  属性

2

3.3  查询服务的划分机房流程

服务查询流程如下,其中划分逻辑机房会发生在“Customer查询EurekaServer    路由策略:选取一个实例”的两个过程中。

3

无论是zuul还是feign都是通过spring cloud ribbon来实现路由策略的。spring cloud ribbon 的策略使用了eureka.instance.metadataMap.zone这个属性,默认策略是customer获取到同机房的server实例。

(1)微服务通过feign来访问

4

(2)mvc老服务需要自定义路由策略

5

3.4 服务注册的划分机房流程流程

需要根据配置文件获取到一个注册中心的地址,然后向注册中心进行注册。

7876891

参考

比较好的参考如下

Eureka 中的 region Zone  : https://juejin.im/post/5d68b73af265da03b12061be

一个实例:https://blog.marcosbarbero.com/ha-and-zone-affinity-spring-cloud-eureka/

 

 

分类&标签