Spring Cloud Netflix 是什么
This project provides Netflix OSS integrations for Spring Boot apps through autoconfiguration and binding to the Spring Environment and other Spring programming model idioms. With a few simple annotations you can quickly enable and configure the common patterns inside your application and build large distributed systems with battle-tested Netflix components. The patterns provided include Service Discovery (Eureka), Circuit Breaker (Hystrix), Intelligent Routing (Zuul) and Client Side Load Balancing (Ribbon).
Spring Cloud Netflix 基于 Spring Boot，集成了NetFlix OSS的一些组件，只需通过注解配置和Spring的简单注解，就可以快速的启用和配置NetFlix的组件实现分布式系统的构建。这些组件包含的功能有服务发现（Eureka），熔断器（Hystrix），智能路由(Zuul)以及客户端的负载均衡器（Ribbon）
Spring Cloud Eureka 是什么
Spring Cloud Eureka 是基于Spring Cloud Netflix 做了二次封装，它主要负责完成各个微服务实例的自动化注册和发现功能。
Spring Cloud Eureka 相关概念
服务提供者
1.服务注册
服务在启动的时候会通过发送REST请求的方式将自己注册到Eureka Server上， 同时带上了自身服务的一些元数据信息。注册中心Eureka Server通过与服务之间的心跳来保持通信，当某个服务实例在超时时间内没有与注册中心保持会话，那么该服务实例将会从注册中心正常移除。
Eureka Server 接收到这个REST请求之后，将元数据信息存储在一个双层结构Map中， 其中第一层的key是服务名， 第二层的key是具体服务的实例名。
2.服务同步
如架构图中所示，这里的两个服务提供者分别注册到了两个不同的服务注册中心上，它们的信息分别被两个服务注册中心所维护。由于服务注册中心之间因互相注册为服务， 当服务提供者发送注册请求到一个服务注册中心时， 它会将该请求转发给集群中相连的其他注册中心， 从而实现注册中心之间的服务同步。通过服务同步，两个服务提供者的服务信息就可以通过这两台服务注册中心中的任意一台获取到。
3.服务续约
在注册完服务之后，服务提供者会维护一个心跳用来保持与EurekaServer 的会话，以防止Eureka Server 的剔除任务将该服务实例从服务列表中移除掉，那么这个心跳保持就叫做服务续约(Renew)。
关于服务续约有两个重要属性，我们可以关注并根据需要来进行调整：
服务续约任务的调用间隔时间，默认为30秒
eureka.instance.lease-renewal-interval-in-seconds=30
服务失效的时间，默认为90秒。
eureka.instance.lease-expiration-duration-in-seconds=90
服务消费者
1.获取服务
当启动服务消费者的时候，它会发送一个REST请求给服务注册中心，来获取上面注册的服务列表。Eureka Server会维护一份只读的服务列表来返回给客户端，同时服务消费者会在本地缓存服务列表的清单并每隔30秒更新一次。
获取服务是服务消费者的基础，所以必有两个重要参数需要注意：
# 启用服务消费者从注册中心拉取服务列表的功能
eureka.client.fetch-registry=true
# 设置服务消费者从注册中心拉取服务列表的间隔
eureka.client.registry-fetch-interval-seconds=30
2.服务调用
服务消费者在获取服务清单后，通过服务名可以获得具体提供服务的实例名和该实例的元数据信息。因为有这些服务实例的详细信息， 所以客户端可以根据自己的需要决定具体调用哪个实例，在ribbon中会默认采用轮询的方式进行调用，从而实现客户端的负载均衡。
对于访问实例的选择，Eureka中有Region和Zone的概念， 一个Region中可以包含多个Zone, 每个服务客户端需要被注册到一个Zone中， 所以每个客户端对应一个Region和一个Zone。在进行服务调用的时候，优先访问同处一个Zone 中的服务提供方，若访问不到，就访问其他的Zone。
3.服务下线
在客户端程序中，当服务实例进行正常的关闭操作时，它会触发一个服务下线的REST请求给Eureka Server, 告诉服务注册中心自己要下线了。服务端在接收到请求之后，将该服务状态置为下线(DOWN), 并把该下线事件传播出去。
服务注册中心
1.失效剔除
服务实例并不一定会正常下线，可能由于内存溢出、网络故障等原因使得服务不能正常工作，而服务注册中心并未收到“服务下线” 的请求。为了从服务列表中将这些无法提供服务的实例剔除， Eureka Server在启动的时候会创建一个定时任务，默认每隔一段时间（默认为60秒） 将当前清单中超时（默认为90秒）没有续约的服务剔除出去。
2.自我保护机制
当我们在本地调试基于Eureka的程序时， 基本上都会碰到这样一个问题， 在服务注册中心的信息面板中出现类似下面的红色警告信息：
EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE.
事实上，该警告就是触发了EurekaServer的自我保护机制。当服务注册到EurekaServer之后，会维护一个心跳连接，告诉EurekaServer自己还活着。EurekaServer在运行期间，会统计心跳失败的比例在15分钟之内是否低于85%, 如果出现低于该值，Eureka Server会将当前的实例注册信息保护起来，让这些实例不会过期，尽可能保护这些注册信息。但是，在这段保护期间内实例若出现问题，那么客户端很容易拿到实际已经不存在的服务实例， 会出现调用失败的清况，所以客户端必须要有容错机制，比如可以使用请求重试、断路器等机制。
由于本地调试很容易触发注册中心的保护机制，这会使得注册中心维护的服务实例不那么准确。所以，我们在本地进行开发的时候， 可以使用eureka.server.enableself-preservation=false 参数来关闭保护机制， 以确保注册中心可以将不可用的实例正确剔除。