微服务架构中,选择的是哪种治理组件

微服务架构中,选择的是哪种治理组件(eureka zookeeper)?为什么?
思路:技术选型来答.(CAP理论)
CAP:理论已经被验证正确了,是分布式环境下一个基础理论.很多技术选型都要考虑到理论的使用
C: consistence 数据一致性
A: avalibility 系统可用性
P: partition/partition tolerence 分区/分区容忍度

P:分区和分区容忍度,在分布式环境中,一旦出现网络波动,故障,异常,数据相互之间不可通信造成了分区的出现,一旦涉及到分区出现时的读写要求.考虑分区容忍度.
C:数据一致性,如果分区出现时,对于分布式数据进行写操作,要求数据有一致性,要求数据不必要一致
要求数据一致性:保证操作时,加锁,加事务
分区容忍度–高--数据一致性要求高
要求不必要一致:不需要加锁,加事务
分区容忍度–低--一致性要求低
A:可用性,在分区出现时,要求数据有一致性,加锁加事务,导致系统可用性降低,不要求数据一致性,不加锁事务,系统可用性提高

CAP结论:不可能CAP同时存在,只能同时满足2个

CA:网络通畅无比,没有分区,一致性能满足,可用性能满足(很难实现 P分区不出现)

CP:分区出现时,要求数据一致性,忽略可用性

AP:分区出现时,要求可用性,不能保证一致性

CP:支付时,必须保证数据一致.(支付平台必须和银行账户一致)

AP:做应用系统,基本保证可用性(访问的电商网站大部分功能)

eureka治理组件:
管理服务信息时,有没有保证一致性(任何时间点,系统所有角度观察数据都是完全一致的).
eureka并没有实现强数据一致性的保证
服务提供者宕机,eureka注册信息最晚多长时间才剔除 120秒
可用性比较高,不会因为维护一致性消耗可用性的效果

zookeeper治理组件:
管理的注册信息是强一致性的,任意时间点观察其中的数据所有角度都是一致的,所以可用性降低了.
为什么使用zookeeper (看中强一致性,一致性不会让可用性那么差 网络比较通畅)
为什么使用eureka(看中可用性,网络环境比较差,只能选择可用性)
BASE理论:基本可用,数据保持最终一致性,是CAP理论延伸