Eureka

服务治理

我们为什么需要服务治理模块呢？在最初开始构建微服务系统的时候可能服务并不多，我们可以通过做一些静态配置来完成服务的调用。但是随着业务的发展，系统功能越来越复杂，静态配置变得越来越难以维护。

服务注册与服务发现

服务注册：每个服务将自己的主机，端口号等信息告诉注册中心，注册中心维护一个服务清单。另外，服务注册中心还需要以心跳的方式去检测清单中的服务是否可用。
服务发现：举个例子，假设服务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来开发