SpringCloud:服务注册与发现之Eureka(2)(服务注册到eureka)

Eureka集群原理

SpringCloud:服务注册与发现之Eureka(2)(服务注册到eureka)

问题:微服务RPC远程服务调用最核心的是什么?
高可用,试想你的注册中心只有一个only one, 它出故障了那就呵呵( ̄▽ ̄)”了,会导致整个为服务环境不可用。
解决办法:搭建Eureka注册中心集群 ,实现负载均衡+故障容错

Eureka集群原理:互相注册,相互守望

SpringCloud:服务注册与发现之Eureka(2)(服务注册到eureka)

EurekaServer集群环境构建

准备工作: 修改host文件 :  C:\Windows\System32\drivers\etc

127.0.0.1 eureka7001.com
127.0.0.1 eureka7002.com

1.新建7002

参考cloud-eureka-server7001 新建 cloud-eureka-server7002

2.pom

7002 的 pom 和7001的相同

3.yml

eureka1

eureka1

测试

开启eureka7001和eureka7002这两个服务
访问http://eureka7001.com:7001和http://eureka7002.com:7002

SpringCloud:服务注册与发现之Eureka(2)(服务注册到eureka)

两个服务器的相互注册成功。

注册提供者这微服务和消费者微服务

将提供者服务8001微服务和消费者服务80微服务发布到上面的2台Eureka集群配置中

修改8001和80的yaml

 测试

先启动eureka7001/7002
再启动payment8001、order80
登陆http://eureka7001.com:7001测试

生产者(provider)微服务集群构建

一个提供者微服务不可能应对所有的消费者微服务,所有要建一个生产者微服务集群

新建cloud-provider-payment8002 微服务模块

1.pom

cloud-provider-payment8001一致
唯一区别在于 <artifactId>cloud-provider-payment8002</artifactId>

2.写yml

与8001一致,将port改为8002

3.其他

其他和8001相同,注意主启动类修改

4.修改 80 客户端

在配置类上使用@LoadBlanced注解赋予RestTemplate负载均衡的能力

ApplicationContextConfig

controller层的URL修改为服务的名字 CLOUD-PAYMENT-SERVICE(以前写死,因为只有一个微服务,现在有多个)

 测试

提供者为8001和8002轮训,根据端口号看出

SpringCloud:服务注册与发现之Eureka(2)(服务注册到eureka)

actuator微服务信息完善

在8001和8002的配置文件中加入

SpringCloud:服务注册与发现之Eureka(2)(服务注册到eureka)

SpringCloud:服务注册与发现之Eureka(2)(服务注册到eureka)

服务发现Discovery

服务发现:对于注册进eureka里面的微服务,可以通过服务发现来获得该服务的信息

@EnableDiscoveryClient注解

需要拿到在eureka上注册了的微服务的信息,例如:主机名称、端口号

在8001中进行测试

2 在8001的主启动类中开启注解:@EnableDiscoveryClient
测试,访问http://localhost:8001/payment/discovery

SpringCloud:服务注册与发现之Eureka(2)(服务注册到eureka)

eureka自我保护

CAP

  • Consistency(一致性):即更新操作成功并返回客户端后,所有节点在同一时间的数据完全一致。对于客户端来说,一致性指的是并发访问时更新过的数据如何获取的问题。从服务端来看,则是更新如何复制分布到整个系统,以保证数据最终一致。
  • Avaliability(可用性):即服务一直可用,而且是正常响应时间。系统能够很好的为用户服务,不出现用户操作失败或者访问超时等用户体验不好的情况。
  • Partition Tolerance(分区容错性):即分布式系统在遇到某节点或网络故障的时候,仍然能够对外提供满足一致性和可用性的服务。分区容错性要求应用虽然是一个分布式系统,但看上去切好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了,其他剩下的机器还能够正常运转满足系统要求,对于用户而言并没有什么体验上的影响
  • CP和AP:分区容错是必须保证的,当发生网络分区的时候,如果要继续服务,那么强一致性和可用性只能2选1

自我保护

如果一定时间内丢失大量该微服务的实例,这时Eureka就会开启自我保护机制,不会剔除该服务。 因为这个现象可能是因为网络暂时不通,而不是服务不健康了,出现了Eureka的假死,拥堵,卡顿。 稍等会客户端还能正常发送心跳。 这就是CAP里面的AP分支思想

怎么禁止自我保护

如果在EurekaServer的首页看到以下这段提示,则说明Eureka进入了保护模式

SpringCloud:服务注册与发现之Eureka(2)(服务注册到eureka)

修改7001的yml配置文件

SpringCloud:服务注册与发现之Eureka(2)(服务注册到eureka)

修改eurekaClient端8001

它有两个默认的配置
# Eureka客户端向服务端发送心跳的时间间隔默认30秒
eureka.instance.lease-renewal-interval-in-seconds: 30 单位秒
# Eureka服务端在收到最后一次心跳后,90s没有收到心跳,剔除服务
eureka.instance.lease-expiration-duration-in-seconds: 90 单位秒

SpringCloud:服务注册与发现之Eureka(2)(服务注册到eureka)

正文完
 0