loud中的注册中心和consume消费者和provier服务者之间的关系理解

pringCloud

第一层的key是服务名第二层的key是具体服务的实例名一个服务有多个实例

配置文件中

eureka.client.register-with-eurekatrue

若为false

provider会维持一个心跳心跳机制来通知server不要让注册中心将这个服务实例在服务列表中remove掉这个保持心跳的操作就是

服务续约

eureka.instance.lease-renewal-interval-in-seconds

表示eureka

client间隔多久去拉取服务注册信息默认为30秒对于api-gateway如果要迅速获取服务注册状态可以缩小该值比如5秒.

eureka.instance.lease-expiration-duration-in-seconds

表示eureka

server至上一次收到client的心跳之后等待下一次心跳的超时时间在这个时间内若没收到下一次心跳则将移除该instance。

Consumer

在注册中心里依旧注册了一个provider,并且有两个实例启动consumer的时候会发送一个rest请求给注册中心来获得注册中心上的服务清单

server

会维护一份onlyRead的清单返回给consumer,并且该缓存清单每隔30秒更新一次.获取服务的配置为

eureka.client.fetch-registrytrue,如果是false就不能获取服务清单了更新服务清单缓存时间的配置

eureka.client.registry-fetch-interval-seconds

第二步

通过provider的name拿到具体服务的实例名和该实例的元数据信息在Ribbon中会采用轮询的方式去调用来获得负载均衡访问实例的时候

一个Region中里有很多Zone

每个Zone里都有一个服务客户端被注册.在进行服务调用的时候优先会访问处于同一个Zone的服务提供方如果调用不到才去别Zone访问。

第三步

会触发一个consumer下线的请求给server,server接收到请求之后把这个服务状态设置为down,并且广播这个事件

server

如果server没有接收到consumer或者provider下线的rest请求server会自动创建一个定时任务默认每隔60s剔掉当前清单中超时的90s的没有续约的服务请求

第二步

原因是因为provider注册到server上的时候会维护一个心跳连接server在运行的时候会统计心跳失败的比例在15分钟是否低于85%.如果低于85%server会把当前的实例注册信息保护起来让这些实例不会过期。

但是如果在这段保护时间的时候实例若出现问题那么consumer很容易拿到实际不存在的实例会出现调用失败的情况所以provider必须有容错机制比如可以请求重试断路器等机制。

由于本地调试很容易出现server保护机制会让server维护的实例不那么准确所以本地开发的时候可以使用eureka.server.enable-self-preservationfalse来关闭保护机制已确保剔除失效的实例。