基础架构
服务注册中心
服务提供者
服务消费者
服务治理机制
服务提供者
服务注册
服务提供者在启动的时候会根据配置的注册中心地址，将自己通过rest请求的方式注册到注册中心（eureka server），同时会携带元数据信息，在eureka server中会用一个双层map结构存储该元数据信息，第一层map的key是服务名称，第二层map的key是该服务具体的被调用的服务实例的名称
注意：eureka.client.register-with-eureka=true #若为false则不启动注册操作
服务同步
当启动服务提供者时，服务提供者会注册到注册中心，若此时注册中心采用集群方案的话，该服务会注册到某一注册中心上，这时目标注册中心会将服务replicate到集群内的其他注册中心，实现服务同步。通过服务同步，provider可在eureka server集群内任意一注册中心被获取到。
服务续约
注册中心如何知道服务还活着？正常的服务会不会被注册中心的剔除任务所剔除？
在provider完成注册操作后，会维护一个心跳任务来告诉注册中心自己还活着。此操作叫续约renew
我们可以配置续约任务的间隔时间以及服务的有效时间
注意：eureka.instance.lease-renewal-interval-in-seconds=30#续约心跳间隔时间，默认时30s
eureka.instance.lease-expiration-duration-in-seconds=90#服务有效时间，超出此时间并且在此时间内没有任何心跳与注册中心通信的话，该服务被剔除（失效），默认90s
服务消费者
获取服务
启动cosumer后，会发送rest请求到注册中心，用来获取注册中心可用的服务清单，为了性能考虑，eureka server会维护一份只读清单返回客户端consumer，同时该缓存清单每隔30s更新一次。
注意：eureka.client.registry-fetch-interval-seconds=30#修改更新缓存清单时间，默认30s
eureka.client.fetch-registery=true#开启从eureka服务器端获取注册信息，该配置时检索服务，若为false则cosumer无意义，不能在eureka server进行服务检索。
服务调用
costumer获取到注册信息后，可根据服务名在注册信息内获取具体提供服务的实例名称及实例元数据信息，从而可以根据具体业务需求选择掉某一服务。调用时ribbon会通过默认的轮询算法进行客户端负载
注意：对于访问实例的选择，eureka中有region和zone的概念，一个region包含多个zone，每个服务会被注册到一个zone内，消费客户端调用服务时会现在所在的zone内查询服务（一个项目包含同时包含服务提供／消费），若没有再去其他zone内查询，
服务下线
服务面临关闭或重启时，在服务关闭期间，不希望该服务总被consumer掉，所以会发送一个通知（触发一个服务下线的rest请求）到注册中心，告诉注册中心本服务下线啦，此时consumer在获取到服务时发现该服务下线，则会在consumer端对此服务进行down标记，表示该服务已不可用。并把该下线的事件传播出去。
服务注册中心
失效剔除
自我保护
网友评论