给大家推荐个靠谱的公众号程序员探索之路，大家一起加油
1.Eureka是什么
Eureka是Netflix的一个子模块之一，AP设计原则。Eureka是一个以及Rest的服务，用于定位服务，以实现云端中间层服务发现和故障转移。服务注册与发现对于微服务架构来说是非常重要的，有了服务发现与注册，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务调用的配置文件了。功能类似于dubbo的注册中心，比如zookeeper
Eureka Server 注册中心示意图
Dubbo示意图
2.Eureka包含两个组件：Eureka Server和Eureka Client
Eureka Server 提供服务注册服务
各个节点启动后，会在EurekaServer中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到
EurekaClient 是一个Java客户端，用于简化EurekaServer的交互，客户端同时也具备一个内置的，使用轮询（roud-robin）负载算法的负载均衡器。在应用启动后，将会想EurekaServer发送心跳（默认周期为30秒）。如果EurekaServer在多个心跳周期内没有接收到某个节点的心跳，EurekaServer将会从服务注册表中把这个服务节点移除（默认90秒）
3.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.
默认情况下，如果RurekaServer在一定时间内没有接收端哦某个微服务实例的心跳，EurekaServer将会注销该实例（默认90秒）。但是当网络分区故障发生时，微服务与EurekaServer之间无法正常通信，以上行为可能变得危险了---因为微服务本身其实是健康的，此时本不应该注销这个微服务。Eureka通过“自我保护模式”来解决这个问题—当EurekaServer节点在短时间内丢失过多客户端时（可能发生了网络分区故障），那么这节点就会进入自我保护模式。一旦进入该模式，EurekaServer就会保护服务注册表中的信息，不在删除服务主表中的数据（也就是不会注销任何微服务）。当网络故障恢复后，该EurekaServer节点会自动推出自我保护模式。
在自我保护模式中，EurekaServer会保护服务注册表中的信息，不在注销任何服务实例。当它收到的心跳数重新恢复到阈值以上时，该EurekaServer节点就会自动推出自我保护模式。它的设计哲学就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。一句话讲解：好死不如赖活着
综上，自我保护模式是一种应对网络异常的安全保护措施。他的架构哲学是宁可同时保留所有微服务（健康的微服务和不健康的微服务都会保留），也不盲目注销任何健康的微服务。使用自我保护模式，可以让Eureka集群更加的健壮,稳定。
在SrpingCloud，可以使用eureka.server.enable-self-preservation=false禁用自我保护机制
4.ACID是什么？关系型数据库遵循ACID原则
A Atomicity 原子性
原子性很容易理解，也就是说事务里的所有操作要么全部做完，要么都不做，事务成功的条件是事务里的所有操作都成功，只要有一个操作失败，整个事务就失败，需要回滚。
C Consistency 一致性
一致性比较容易理解，也就是说数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束
I Isolation 独立性
所谓的独立性是指并发的事务之间不会互相影响，如果一个事务要访问数据正在被另外一个事务修改，只要另外一个事务未提交，他所访问的数据就不收未提交事务的影响。
D durability 持久性
持久性是指一旦事务提交后，他所作的修改将会永久的保存在数据库上，即使出现宕机也不会丢失。
CAP是什么？
C Consistency 强一致性
A Availability 可用性
P Partition tolerance 分区容错性
经典CAP图
CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，因此根据CAP原理将NoSQL数据库分成了满足CA原则，满足CP原则和满足AP原则三大类
CA-单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大
CP- 满足一致性，分区容忍性的系统，通常性能不是特别高
AP- 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些
CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。
而由于当前的网络硬件肯定会出现演示丢包等问题，所以，分布容错性我们必须选择的
5.作为服务注册中心，Eureka比Zookeeper好在哪里
著名的CAP理论指出，一个分布式系统不可能同时满足CAP。由于分区容错性p在分布式系统中是必须要保证的，因此我们只能在A和C之间权衡
因此
Zookeeper保证的CP
Eureka则是AP
Zookeeper保证CP
当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高与一致性。但是zk会出现这一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader时间太长，30~120s，且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在于部署的环境下，因网络问题使得zk汲取闹市区master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用事不能容忍的。
Eureka保证AP
Eureka 看明白这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在想某个Eureka注册时如果发现连接失败，则会自动切换至其他节点，只要有一台Eureka还在，就能保证注册服务可用（保证可用性），之不过查到的信息可能不是最新的（不保证强一致性）。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现一下几种情况：
- Eureka不在从注册列表中移除因为长时间没有收到心跳而应该过期的服务
- Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上（即保证当前节点依然可用）
- 当网络稳定时，当前实例新的注册信息会被同步到其他节点中
因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会向zookeeper那样使整个注册服务瘫痪
本次新增eurekatest7001,7002,7003项目
C:\Windows\System32\drivers\etc 修改houst文件
127.0.0.1 eureka7001.com
127.0.0.1 eureka7002.com
127.0.0.1 eureka7003.com
代码地址https://github.com/ZhZGod/spring-cloud-codes
效果截图：
