服务容错保护Spring Cloud Hystrix实现了断路器、线程隔离等一系列服务保护功能。它也是基于Netflix 的开源框架 Hystrix实现的，该框架的目标在于通过控制那些访问远程系统、服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力。Hystrix具备服务降级、服务熔断、线程和信号隔离、请求缓存、请求合并以及服务监控等强大功能。
Spring Cloud Hystrix
服务发现技术选型
分布式之CAP原则详解
分布式系统有个重要的CAP原则
一致性（Consistency）：数据一致性，即数据在存在多副本的情况下，可能由于网络、机器故障、
软件系统等问题导致数据写入部分副本成功，部分副本失败，进而造成副本之间数据不一致，存在冲突。满足一致性则要求对数据的更新操作成功之后，多副本的数据保持一致。
可用性（Availability）：在任何时候客户端对集群进行读写操作时，请求能够正常响应，即在一定的延时内完成。
分区容错性（Partition tolerance）：发生通信故障的时候，整个集群被分割为多个无法相互通信的分区时，集群仍然可用。
对于分布式系统来说，一般网络条件相对不可控，出现网络分区是不可避免的，因此系统必须具备分区容忍性。在这个前提下分布式系统的设计则在AP及CP之间进行选择。不过不能理解为CAP三者之间必须三选二，它们三者之间不是对等和可以相互替换的。在分布式系统领域，P是一个客观存在的事实，不可绕过，所以P与AC之间不是对等关系。
对于ZooKeeper，它是”C”P的，之所以C加引号是因为ZooKeeper默认并不是严格的强一致，比如客户端A提交一个写操作，ZooKeeper在过半数节点操作成功之后就返回，此时假设客户端B的读操作请求到的是A写操作尚未同步到的节点，那么读取到的就不是客户端A写操作成功之后的数据。如果在使用的时候需要强一致，则需要在读取数据的时候先执行一下sync操作，即与leader节点先同步下数据，这样才能保证强一致。在极端的情况下发生网络分区的时候，如果leader节点不在non-quorum分区，那么对这个分区上节点的读写请求将会报错，无法满足Availability特性。
Eureka是在部署在AWS的背景下设计的，其设计者认为，在云端，特别是在大规模部署的情况下，失败是不可避免的，可能因为Eureka自身部署失败，注册的服务不可用，或者由于网络分区导致服务不可用，因此不能回避这个问题。要拥抱这个问题，就需要Eureka 在
