Eureka、Nginx和ZooKeeper的介绍

1、Nginx是著名的反向代理服务器，也被广泛的作为负载均衡服务器
2、ZooKeeper是分布式协调服务框架，有时也被用来做负载均衡

先说下什么是注册中心规则
每一个微服务启动的时候，都需要去注册中心注册（eureka或zookeeper或其他),同类服务注册的服务名必须相同，不同类服务注册的服务名一定不能相同

1、订单服务部署5台服务器，那么这5台微服务在注册中心中注册的服务名必须一致，例如ORDER
2、商品服务部署4台服务器，那么这4台微服务在注册中心中注册的服务名必须一致，例如GOODS
3、订单服务和商品服务注册的服务名一定不能相同，不能同为ORDER,也不能同为GOODS

一、Nginx

配置负载节点

upstream backend {
  server 192.168.1.10;
  server 192.168.1.11;
}

当随着单个服务的节点变多

upstream backend {
  server 192.168.1.10;
  server 192.168.1.11;
  .....
}

缺点：
1、【配置维护的成本变高】

因为节点太多（节点太多了，就会出现一个问题就是，那么Ip，如果某个Ip挂了，就不知道这个服务Ip是好的还是坏的，缺乏心跳检测）

2、【单点故障的风险增加了】

因为热点服务的访问量很高，如果这个服务集群内的负载均衡服务出现问题，这个服务将失效（负载均衡和热点服务放在一台机器上，这个机器的压力会很大，如果机器挂了，Nginx就会挂了，那么这个服务都不能用了）

第二个问题：可以通过双机高可用部署方案，使用另一台机器单独部署nginx用来负载均衡只是成本较高

二、ZooKeeper

ZooKeeper作为一个服务的注册中心，在其中登记每个服务，每台服务器知道自己是属于哪个服务，在服务器启动时，自己向所属服务进行登记，这样，一个树形的服务结构就呈现出来了
服务的调用者到注册中心里面查找：能提供所需服务的服务器列表，然后自己根据负载均衡算法，从中选取一台服务器进行连接
调用者取到服务器列表后，就可以缓存到自己内部，省得下次再取，当服务器列表发生变化，例如某台服务器宕机下线，或者新加了服务器，ZooKeeper会自动通知调用者重新获取服务器列表
由于ZooKeeper并没有内置负载均衡策略，需要调用者自己实现，这个方案只是利用了ZooKeeper的树形数据结构、watcher机制等特性，把ZooKeeper作为服务的注册和变更通知中心，解决了Nginx负载均衡方案带来的问题

三、eureka

1、eureka作为分布式系统的注册中心，主要作用是用于服务治理
2、eureka分为eureka server和eureka client

四、CAP基本概念

分布式系统的三个指标

1、Consistency 一致性
2、Availability 可用性
3、Partition tolerance 分区容错性

五、eureka和zookeeper区别

eureka基于AP，zookeeper基于CP

优点：数据强一致 vs 服务高可用
缺点：网络分区会影响Leader选举,超过阈值后集群不可用，服务节点间的数据可能不一致；Client-Server间的数据可能不一致；

适用场景

单机房集群: 对数据一致性要求较高
云机房集群: 跨越多机房部署；对注册中心服务可用性要求较高

由于作为注册中心可用性的需求要高于一致性，所以eureka貌似要比zookeeper更合理一些

AP和CP

Zookeeper集群和Eureka集群有一个最大的区别：

1、zookeeper集群是存在leader和follower关系的，也就是【一主多从】。
2、eureka集群中的各个节点是平等的地位，这是一种【去中心化】的架构，节点通过彼此互相注册来提高可用性，每个节点都可被视为【其他节点的副本】。

1.1 zookeeper是如何保证"一致性"呢？

1、当往zookeeper的leader【节点写数据】时，leader会对剩下的follower节点进行主从数据同步，它必须得同步【超过半数】的follower节点才给客户端返回写成功的信号。所以从这点上它是保证了【数据一致性】，但是却【不是强一致性】。

为什么说zookeeper缺乏可用性

1、由于网络故障或是其他原因导致leader节点挂了，那么这个时候zookeeper集群就得在剩下那些follower接点中重新进行leader的选举，选出一个新leader来。但是别忘了，选举是需要时间的，哪怕30s到120秒，这一段时间之内，zookeeper集群是【不能给外部提供服务】的，处于不可用的状态，所以从这个角度来讲它丧失了一定的系统可用性

ZK如何保障一致性必看《跳转》

1.2 eureka是如何保证"可用性"的呢？

1、Eureka集群中【各个节点】都【是平等的】，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以【提供注册】和【查询服务】。并且Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会【自动切换】至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息【可能不是最新的】(不保证强一致性)。 因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper集群那样使整个注册服务瘫痪。

2、在心跳检测时可能会触发，自我保护机制。这也保障服务高可用的一个因素，当网络稳定时， 当前实例新的注册信息会被同步到其他节点中。

总结：

1、zookeeper的设计理念就是分布式协调服务，保证数据（配置数据，状态数据）在多个服务系统之间保证一致性，这也不难看出Zookeeper是属于CP特性（Zookeeper的核心算法是Zab，保证分布式系统下，数据如何在多个服务之间保证数据同步）。
2、Eureka是吸取Zookeeper问题的经验，先保证可用性。zookeeper优先选择了一致性（CP），Eureka优先选择了可用性（AP）。

关于AP和CP的更详细说明请看 《跳转》

高可用和一致性原则《跳转》