服务治理
我们为什么需要服务治理模块呢?在最初开始构建微服务系统的时候可能服务并不多,我们可以通过做一些静态配置来完成服务的调用。但是随着业务的发展,系统功能越来越复杂,静态配置变得越来越难以维护。
服务注册与服务发现
服务注册:每个服务将自己的主机,端口号等信息告诉注册中心,注册中心维护一个服务清单。另外,服务注册中心还需要以心跳的方式去检测清单中的服务是否可用。
服务发现:举个例子,假设服务C希望调用服务A,服务C向注册中心发起咨询服务请求,服务注册中心就会将服务A的位置清单返回给服务C。
高可用注册中心
在微服务架构这样的分布式环境中,我们需要充分考虑发生故障的情况,所以必须对各个组件进行高可用部署,对于服务注册中心也是一样。Eureka Server一开始就考虑了这个问题,Eureka Server的高可用实际上就是将自己作为服务向其他服务注册中心注册自己。这样就可以形成一组互相注册的服务注册中心,以实现服务清单的互相同步,达到高可用的效果。
Eureka详解
Eureka的三个核心要素:
- 服务注册中心:提供服务注册与发现的功能
- 服务提供者:提供服务的应用
- 服务消费者:消费者从服务注册中心获取服务列表,从而可以知道去何处调用所需的服务
服务治理机制
关于服务提供者
- 服务注册:在这里不多做赘述
- 服务同步:假设两个服务提供者分别注册到了两个不同的服务注册中心上。此时由于服务注册中心互相注册为服务,当服务提供者发送注册请求到一个注册中心时,他会将请求转发到其他注册中心,实现注册中心之间的同步。
- 服务续约:服务提供者维护一个心跳告诉Eureka Server它还活着,防止被剔除
- 服务下线: 服务正常的关闭或者重启
对于服务消费者:
- 服务发现:在这里不做赘述
- 服务调用:服务消费者在获取地址清单后,服务消费者根据自己的需要决定调用哪个实例
对于服务注册中心
- 失效剔除:Eureka会创建一个定时任务,每隔60秒将当前清单中没有续约的服务剔除
Eureka的自我保护机制
默认情况下,如果Eureka Server在一定时间内没有接收到某个服务实例的心跳,就会移除该实例。但是当网络发生故障时,服务与Eureka Server之间无法正常通信,而服务本身是正常运行的,不应该移除,此时就引入了自我保护机制
自我保护的工作机制是如果15分钟内超过85%的服务实例都没有正常的心跳,那么Eureka就认为服发生了网络故障,进入自我保护机制,有以下几种情况:
- Eureka Server不再移除服务清单中长时间没收到心跳的服务
- Eureka Server仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上,保证当前节点依然可用。当网络稳定时,当前Eureka Server新的注册信息会被同步到其它节点中
跨平台支持
Eureka的通信机制使用了HTTP的Rest接口实现。由于HTTP的平台无关性,虽然Eureka Server通过Java实现,但在其下的微服务应用不限于使用Java来开发