Eureka注册中心 --理论梳理
先举个栗子！！！
网约车：
在网约车出现以前，人们出门叫车只能叫出租车。一些私家车想做出租却没有资格，被称为黑车。而很多人想要约车，但是无奈出租车太少，不方便。私家车很多却不敢拦，而且满大街的车，谁知道哪个才是愿意载人的。一个想要，一个愿意给，就是缺少引子，缺乏管理啊。
此时滴滴这样的网约车平台出现了，所有想载客的私家车全部到滴滴注册，记录你的车型（服务类型），身份信息（联系方式）。这样提供服务的私家车，在滴滴那里都能找到，一目了然。
此时要叫车的人，只需要打开APP，输入你的目的地，选择车型（服务类型），滴滴自动安排一个符合需求的车到你面前，为你服务，完美！
Eureka是做什么：
Eureka就好比是滴滴，负责管理、记录服务提供者的信息。服务调用者无需自己寻找服务，而是把自己的需求告诉Eureka，然后Eureka会把符合你需求的服务告诉你。
同时，服务提供方与Eureka之间通过“心跳”机制进行监控，当某个服务提供方出现问题，Eureka自然会把它从服务列表中剔除。
这就实现了服务的自动注册、发现、状态监控。
Eureka基本架构原理图：
-
Eureka：就是服务注册中心（可以是一个集群），对外暴露自己的地址
-
提供者：启动后向Eureka注册自己信息（地址，提供什么服务）
-
消费者：向Eureka订阅服务，Eureka会将对应服务的所有提供者地址列表发送给消费者，并且定期更新
-
心跳(续约)：提供者定期通过http方式向Eureka刷新自己的状态
高可用的Eureka Server
1、高可用是什么？
-
强调服务的可用性，就算是非常非常极端的情况下，也可以稳定的提供服务
2、如何实现高可用？
-
集群 是实现高可用必须方式
3、分布式、集群、负载均衡的关系？
-
分布式：将一个大服务拆成N个小服务，每个小服务都是独立的，开发独立，部署独立
-
集群：将同一个项目代码部署在N台服务器
-
负载均衡：将N多请求分摊在各个服务器上
-
如果集群，必然要负载均衡；如果负载均衡，必须集群
4、集群 至少需要几台服务器？
-
3台 及时挂了一台，其他两台还能继续集群
5、Eureka服务同步
多个Eureka Server之间也会互相注册为服务，当服务提供者注册到Eureka Server集群中的某个节点时，该节点会把服务的信息同步给集群中的每个节点，从而实现数据同步。因此，无论客户端访问到Eureka Server集群中的任意一个节点，都可以获取到完整的服务列表信息。
服务提供者
服务提供者要向EurekaServer注册服务，并且完成服务续约等工作。
服务注册
服务提供者在启动时，会检测配置文件属性的：eureka.client.register-with-erueka=true参数是否正确，事实上默认就是true。如果值确实为true，则会向EurekaServer发起一个Rest请求，并携带自己的元数据信息，Eureka Server会把这些信息保存到一个双层Map结构中。第一层Map的Key就是服务名称，第二层Map的key是服务的实例id。
服务续约
在注册服务完成以后，服务提供者会维持一个心跳（定时-每隔30s-向EurekaServer发起Rest请求），告诉EurekaServer：“我还活着”。这个我们称为服务的续约（renew）；
-
lease-renewal-interval-in-seconds：服务续约(renew)的间隔，默认为30秒
-
lease-expiration-duration-in-seconds：服务失效时间，默认值90秒
也就是说，默认情况下每隔30秒服务会向注册中心发送一次心跳，证明自己还活着。如果超过90秒没有发送心跳，EurekaServer就会认为该服务宕机，会从服务列表中移除，这两个值在生产环境不要修改，默认即可。但是在开发时，这个值有点太长了，经常我们关掉一个服务，会发现Eureka依然认为服务在活着。所以我们在开发阶段可以适当调小。
服务消费者
获取服务列表
当服务消费者启动时，会检测eureka.client.fetch-registry=true参数的值，如果为true，则会从Eureka Server服务的列表只读备份，然后缓存在本地。并且每隔30秒会重新获取并更新数据。我们可以通过下面的参数来修改：
eureka:
client:
registry-fetch-interval-seconds: 5
服务的失效剔除和自我保护
失效剔除
有些时候，我们的服务提供方并不一定会正常下线，可能因为内存溢出、网络故障等原因导致服务无法正常工作。Eureka Server需要将这样的服务剔除出服务列表。因此它会开启一个定时任务，每隔60秒对所有失效的服务（超过90秒未响应）进行剔除。
可以通过eureka.server.eviction-interval-timer-in-ms参数对其进行修改，单位是毫秒，生成环境不要修改。
这个会对我们开发带来极大的不便，你对服务重启，隔了60秒Eureka才反应过来。开发阶段可以适当调整，比如10S。
自我保护
我们关停一个服务，就会在Eureka面板看到一条警告：
这是触发了Eureka的自我保护机制。当一个服务未按时进行心跳续约时，Eureka会统计最近15分钟心跳失败的服务实例的比例是否超过了85%。在生产环境下，因为网络延迟等原因，心跳失败实例的比例很有可能超标，但是此时就把服务剔除列表并不妥当，因为服务可能没有宕机。Eureka就会把当前实例的注册信息保护起来，不予剔除。生产环境下这很有效，保证了大多数服务依然可用。
开发阶段我们都会关闭自我保护模式：
eureka:
server:
enable-self-preservation: false # 关闭自我保护模式（缺省为打开）
eviction-interval-timer-in-ms: 1000 # 扫描失效服务的间隔时间（缺省为60*1000ms）
负载均衡Ribbon基于Eureka
什么是Ribbon：
重试机制
为什么要有重适机制：
当第一次调用某个服务失败的时候，不是立刻返回失败结果，而是尝试重新请求
默认情况下， 不会重试，只会请求一次
那我应该何时重试呢？
重试几次呢？
Eureka的服务治理CAP：
CAP原则：CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得。
Eureka的服务治理强调了CAP原则中的AP，即可用性和可靠性。它与Zookeeper这一类强调CP（一致性，可靠性）的服务治理框架最大的区别在于：Eureka为了实现更高的服务可用性，牺牲了一定的一致性，极端情况下它宁愿接收故障实例也不愿丢掉健康实例，正如我们上面所说的自我保护机制。
但是，此时如果我们调用了这些不正常的服务，调用就会失败，从而导致其它服务不能正常工作！这显然不是我们愿意看到的。
配置实现Ribbon的重试，当访问到某个服务超时后，它会再次尝试访问下一个服务实例，如果不行就再换一个实例，如果不行，则返回失败。