eureka的架构
eureka的基础架构可以分成三个部分：
1.服务注册中心：提供服务的发现和注册的功能。
2.服务提供者：提供服务的应用，可以是spring boot应用，也可以是其他遵循eureka通信机制的应用。
3.消费者应用从服务注册中心获取服务列表，从而使消费者可以知道去何处调用所v需要的服务。既可以使用 Ribbon，也可以使用Feign.
如图所示
服务提供者
服务注册
“服务提供者”在启动的时候会通过发送REST请求的方式将自己注册到Eureka Server上,同时带上了自身服务的一些元数据信息。Eureka Server接收到这个REST请求之后,将元数据信息存储在一个双层结构Map中。其中第一层的key是服务名,第二层的key是具体服务的实例名。
服务同步
比如在上图中所示，这里的两个服务提供者分别注册到了两个不同的服务注册中心上。信息分别被两个注册中心所维护。同时，这两个服务注册中心又相互注册，当服务提供这发送注册请求到一个服务注册中心的时候，它会将该请求转发给集群中相互连接的其他注册中心，从而实现了服务的同步。
服务续约
在注册完成服务之后，服务提供者会维护一个心跳用来持续告诉eureka server,我还活着。以防止eureka server将该服务从服务列表中排除出去，这种操作就叫做服务续约。
eureka.instance.lease-renewal-interval-in-seconds参数用于定义服务续约任务的调用间隔时间,默认为30秒。eureka.instance.lease-expiration-duration-in-seconds参数用于定义服务失效的时间,默认为90秒。
服务消费者
获取服务
当我们启动服务消费者的时候，他会发送一个Rest请求到服务注册中i性能，来获取上面注册的服务清单。为了性能考虑，eureka server会维护一份只读的服务清单返回给客户端，同时该缓存清单会每隔30秒更新一次。若希望修改缓存清单的更新时间,可以通过eureka.client.registry-fetch-interval-seconds=30参数进行修改,该参数默认值为30,单位为秒。
服务调用
服务消费者在获取服务清单后,通过服务名可以获得具体提供服务的实例名和该实例的元数据信息。因为有这些服务实例的详细信息,所以客户端可以根据自己的需要决定具体调用哪个实例,在Ribbon中会默认采用轮询的方式进行调用,从而实现客户端的负载均衡。
服务下线
在系统运行过程中必然会面临关闭或重启服务的某个实例的情况,在服务关闭期间,我们自然不希望客户端会继续调用关闭了的实例。所以在客户端程序中,当服务实例进行正常的关闭操作时,它会触发一个服务下线的REST请求给Eureka Server,告诉服务注册中心: "我要下线了”。服务端在接收到请求之后,将该服务状态置为下线(DOWN),并把该下线事件传播出去。
