微服务之eureka

本帖最后由 yqw_gz_java 于 2019-8-15 14:26 编辑

与 ZooKeeper 一样 eureka 都可以注册服务发现服务
CAP 定理
在分布式系统领域有个著名的 CAP 定理（C- 数据一致性；A- 服务可用性；P- 服务对网络分区故障的容错性，这三个特性在任何分布式系统中不能同时满足，最多同时满足两个）；
Zookeeper 之 CAP

ZooKeeper 是个 CP 的，即任何时刻对 ZooKeeper 的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性；但是它不能保证每次服务请求的可用性（注：也就是在极端环境下，ZooKeeper 可能会丢弃一些请求，消费者程序需要重新请求才能获得结果）但是别忘了，ZooKeeper 是分布式协调服务，它的职责是保证数据（注：配置数据，状态数据）在其管辖下的所有服务之间保持同步、一致；所以就不难理解为什么 ZooKeeper 被设计成 CP 而不是 AP 特性的了，如果是 AP 的，那么将会带来恐怖的后果（注：ZooKeeper 就像交叉路口的信号灯一样，你能想象在交通要道突然信号灯失灵的情况吗？）。而且，作为 ZooKeeper 的核心实现算法 Zab，就是解决了分布式系统下数据如何在多个服务之间保持同步问题的。作为一个分布式协同服务，ZooKeeper 非常好，但是对于 Service 发现服务来说就不合适了；因为对于 Service 发现服务来说就算是返回了包含不实的信息的结果也比什么都不返回要好；再者，对于 Service 发现服务而言，宁可返回某服务 5 分钟之前在哪几个服务器上可用的信息，也不能因为暂时的网络故障而找不到可用的服务器，而不返回任何结果。所以说，用 ZooKeeper 来做 Service 发现服务是肯定错误的，如果你这么用就惨了！
Eureka
Eureka 由 Netflix 公司开发。（注：Eureka 由两个组件组成：Eureka 服务器和 Eureka 客户端。Eureka 服务器用作服务注册服务器。Eureka 客户端是一个 java 客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。）Eureka 一开始就被设计成高可用与可伸缩的 Service 发现服务，这两个特点也是 Netflix 公司开发所有平台的两个特色。首先，在 Eureka 平台中，如果某台服务器宕机，Eureka 不会有类似于 ZooKeeper 的选举 leader 的过程；客户端请求会自动切换到新的 Eureka 节点；当宕机的服务器重新恢复后，Eureka 会再次将其纳入到服务器集群管理之中；而对于它来说，所有要做的无非是同步一些新的服务注册信息而已。所以，再也不用担心有“掉队”的服务器恢复以后，会从 Eureka 服务器集群中剔除出去的风险了。Eureka 甚至被设计用来应付范围更广的网络分割故障，并实现“0”宕机维护需求。当网络分割故障发生时，每个 Eureka 节点，会持续的对外提供服务（注：ZooKeeper 不会）：接收新的服务注册同时将它们提供给下游的服务发现请求。这样一来，就可以实现在同一个子网中（same side of partition），新发布的服务仍然可以被发现与访问。
但是，Eureka 做到的不止这些。正常配置下，Eureka 内置了心跳服务，用于淘汰一些“濒死”的服务器；如果在 Eureka 中注册的服务，它的“心跳”变得迟缓时，Eureka 会将其整个剔除出管理范围（这点有点像 ZooKeeper 的做法）。这是个很好的功能，但是当网络分割故障发生时，这也是非常危险的；因为，那些因为网络问题（注：心跳慢被剔除了）而被剔除出去的服务器本身是很”健康“的，只是因为网络分割故障把 Eureka 集群分割成了独立的子网而不能互访而已。
幸运的是，Netflix 考虑到了这个缺陷。如果 Eureka 服务节点在短时间里丢失了大量的心跳连接（注：可能发生了网络故障），那么这个 Eureka 节点会进入”自我保护模式“，同时保留那些“心跳死亡“的服务注册信息不过期。此时，这个 Eureka 节点对于新的服务还能提供注册服务，对于”死亡“的仍然保留，以防还有客户端向其发起请求。当网络故障恢复后，这个 Eureka 节点会退出”自我保护模式“。所以 Eureka 的哲学是，同时保留”好数据“与”坏数据“总比丢掉任何”好数据“要更好，所以这种模式在实践中非常有效。
最后，Eureka 还有客户端缓存功能（注：Eureka 分为客户端程序与服务器端程序两个部分，客户端程序负责向外提供注册与发现服务接口）。所以即便 Eureka 集群中所有节点都失效，或者发生网络分割故障导致客户端不能访问任何一台 Eureka 服务器；Eureka 服务的消费者仍然可以通过 Eureka 客户端缓存来获取现有的服务注册信息。甚至最极端的环境下，所有正常的 Eureka 节点都不对请求产生相应，也没有更好的服务器解决方案来解决这种问题时；得益于 Eureka 的客户端缓存技术，消费者服务仍然可以通过 Eureka 客户端查询与获取注册服务信息，这点很重要。
Eureka 的构架保证了它能够成为 Service 发现服务。它相对与 ZooKeeper 来说剔除了 Leader 节点的选取或者事务日志机制，这样做有利于减少使用者维护的难度也保证了 Eureka 的在运行时的健壮性。而且 Eureka 就是为发现服务所设计的，它有独立的客户端程序库，同时提供心跳服务、服务健康监测、自动发布服务与自动刷新缓存的功能。但是，如果使用 ZooKeeper 你必须自己来实现这些功能。Eureka 的所有库都是开源的，所有人都能看到与使用这些源代码，这比那些只有一两个人能看或者维护的客户端库要好。
维护 Eureka 服务器也非常的简单，比如，切换一个节点只需要在现有 EIP 下移除一个现有的节点然后添加一个新的就行。Eureka 提供了一个 web-based 的图形化的运维界面，在这个界面中可以查看 Eureka 所管理的注册服务的运行状态信息：是否健康，运行日志等。Eureka 甚至提供了 Restful-API 接口，方便第三方程序集成 Eureka 的功能
[SQL] 纯文本查看 复制代码
?
1
2
3
4
5
6
7
8
9
eureka:
instance:

hostname: eureka7003.com #eureka 服务端的实例名称

client:

register-with-eureka: false     #false 表示不向注册中心注册自己。fetch-registry: false     #false 表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务
service-url: 
  #defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/       #设置与 Eureka Server 交互的地址查询服务和注册服务都需要依赖这个地址。defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/

eureka 的简要配置
结论
我们来比较一下，在 CAP 理论中，zk 更看重 C 和 P，即一致性和分区容错性。但 Eureka 更在意的是 A 和 P，A 为高可用。zk 中有 master 和 follower 区别，当进入选举模式时，就无法正常对外提供服务。但 Eureka 中，集群是对等的，地位是相同的，虽不能保证一致性，但至少可以提供注册服务。根据不同的业务场景，各有取舍吧。