1.Eureka集群环境配置
本质：互相注册。
注意：但在一个服务器上去模拟集群部署时，需修改配置本地host文件的loaclhost镜像，因为相同intance.name会被默认为只有一个注册中心，而不会去访问其他EurekaSever
大致跟一个Eureka相似，不同之处在于EurekaServer之间要相互绑定，
eg:
注意：7001，7002，7003均是EurekaSever，就是端口号不同，上图就是7001绑定了7002，7003；7002，7003也这样修改就可以了，实现了互相的绑定，三者是平行关系，作用是备份
服务提供者相关配置：yaml格式
eureka:
client:
service-url:
defaultZone:注册到所有EurekaSever中（url），每个url用逗号隔开
CAP原则
RDBMS（mysql，sqlsever，oracle）=》ACID原则
NoSql（redis，mongdb）=》CAP
ACID：
A 原子性（atomicity)
C 一致性（consistency)
I 隔离性（isolation）
D 持久性（durability）
CAP：
C 一致性（Consistency）
A 可用性（Availability）
P 分区容错性（Partition tolerance)
CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。（重点）
各组合的特点：
CA：单点集群，满足一致性和高可用性，通常扩展性比较差
CP；分区容错系统，因为一致性比可用性强，所以拉低了性能
AP；分区容错系统，一致性较低
注意：因为zookeeper和eureka都必须保留集群部署的能力所以，两者只能在CP，AP中选择
ZooKeeper保证的是CP
因为保证了CP,强调一致性（要体现一致性就必须保持主从关系才能实现），所以当集群中的master（主要的）节点，因网络故障等原因与其它节点失去联系时，剩余的节点会重新选举leader，er选举leader的时间会很长30s~120S这之间所有注册的服务都会瘫痪，这时不可容忍的情况
Eureka保证AP
自我保护机制就是AP的主要体现，注册中心和其他服务（包括注册中心服务）都是依靠心跳去监控各服务的健康的，当同一时间有大量服务没有心跳，就会自动触发自我保护机制，核心思想是，宁可保护一个可能是坏掉的服务，也不消除一个可能健康的服务，
这样的结果就是，即便在EurekaSever集群中的某个节点坏掉了，也不会影响整个系统的正常运行
总结：
zookeeper为强调一致性，他的注册中心集群会有主从关系，当主节点挂掉后，剩余的节点会重新选取leader，这期间整个注册与发现服务将会瘫痪，影响项目的运行
Eureka强调高可用性，集群节点间是平行关系，即便其中一个节点挂掉，并不会影响其他服务的运行