冗余和故障转移

高可用设计的核心思想是冗余和故障转移，具体分析下业界比较流行的高可用中间件框架的高可用实现思想。

1.SpringCloud+eureka(高可用的设计理念)

考虑到发生故障的情况，服务注册中心发生故障必将会造成整个系统的瘫痪，因此需要保证服务注册中心的高可用。

Eureka Server在设计的时候就考虑了高可用设计，在Eureka服务治理设计中，所有节点既是服务的提供方，也是服务的消费方，服务注册中心也不例外。

Eureka Server的高可用实际上就是将自己做为服务向其他服务注册中心注册自己，这样就可以形成一组互相注册的服务注册中心，以实现服务清单的互相同步，达到高可用的效果。

Eureka Server的同步遵循着一个非常简单的原则：只要有一条边将节点连接，就可以进行信息传播与同步。可以采用两两注册的方式实现集群中节点完全对等的效果，实现最高可用性集群，任何一台注册中心故障都不会影响服务的注册与发现。

eureka强调高可用性，也就是牺牲强一致性的前提下，保证AP。

eureka是Servlet程序，需要嵌入到Servlet容器中，会影响服务治理的性能，这就是在网关技术选型的时候很多人放弃eureka-zuul,选择更加粗暴的Nginx和lua做基础网关，服务只要嵌入到servlet容器，性能就会受到setvlet容器的限制。

eureka1.0高可用架构缺陷：

eureka没有使用强一致性的选举协议，比如ZAB协议作为数据一致性的算法（zookeeper选举算法）比如Consul的数据一致性算法Raft，Eureka 集群的多副本的一致性协议采用类似“异步多写”的 AP 协议，每一个server都会把本地接收到的写请求（register/heartbeat/unregister/update）发送给组成集群的其他所有的机器（Eureka 称之为 peer，对等服务)，特别是 hearbeat 报文是周期性持续不断的在 client->server->all peers 之间传送。

eureka数据一致性协议缺点：

每一台 Server 都需要存储全量的服务数据，Server 的内存明显会成为瓶颈。当订阅者却来越多的时候，需要扩容 Eureka 集群来提高读的能力，但是扩容的同时会导致每台 server 需要承担更多的写请求，扩容的效果不明显。组成 Eureka 集群的所有server都需要采用相同的物理配置，并且只能通过不断的提高配置来容纳更多的服务数据

eureka2.0架构升级：

数据推送从 pull 走向 push 模式，并且实现更小粒度的服务地址按需订阅的功能。

读写分离，写集群相对稳定，无需经常扩容；读集群可以按需扩容以提高数据推送能力。

新增审计日志的功能和功能更丰富的 Dashboard。

eureka2.0架构整体升级类似于阿里巴巴自研的分布式注册中心ConfigServer的架构演进。

2.SpringCloud+Consul(高可用的设计理念)

由于Spring Cloud为服务治理做了一层抽象接口，所以在Spring Cloud应用中可以支持多种不同的服务治理框架，比如：Netflix Eureka、Consul、Zookeeper。在Spring Cloud服务治理抽象层的作用下，我们可以无缝地切换服务治理实现，并且不影响任何其他的服务注册、服务发现、服务调用等逻辑。

Consul类似于Zookeeper，保证强一致性的前提下，牺牲高可用性，保证CP。

Consul采用go语言编写，不需要嵌入，高性能。

在 CAP 中，Consul 使用 CP 体系结构，有利于实现可用性的一致性。

Consul 强一致性(C)带来的是：

服务注册相比 Eureka 会稍慢一些。因为 Consul 的 raft 协议要求必须过半数的节点都写入成功才认为注册成功 Leader 挂掉时，重新选举期间整个 Consul 不可用。保证了强一致性但牺牲了可用性。

Eureka 保证高可用(A)和最终一致性：

服务注册相对要快，因为不需要等注册信息 replicate 到其他节点，也不保证注册信息是否 replicate 成功当数据出现不一致时，虽然A, B上的注册信息不完全相同，但每个Eureka节点依然能够正常对外提供服务，这会出现查询服务信息时如果请求A查不到，但请求B就能查到。如此保证了可用性但牺牲了一致性。

其他方面，eureka 就是个 servlet 程序，跑在 servlet 容器中; Consul 则是 go 编写而成。

一致性协议采用 Raft 算法,用来保证服务的高可用. 使用 GOSSIP 协议管理成员和广播消息, 并且支持 ACL 访问控制。

consul服务注册中心的优势:

使用 Raft 算法来保证一致性, 比复杂的 Paxos 算法更直接

支持多数据中心

支持健康检查

支持http和dns协议封口

官方支持Dashboard web-ui

部署简单，运维友好

一致性协议Raft 和ZAB协议都是强一致性数据协议。

3.SpringCloud+Zookeeper(高可用的设计理念)

dubbo支持zk、redis、db注册中心，公司基本都是使用zookeeper作为高可用注册中心组件，充分利用zk的分布式cp特性。其实个人理解，作为服务治理的数据一致性，应该要关注可用性，及关注AP特性，作为核心电商交易高并发场景，在数据一致性上应该关注CP，注重数据最终一致性，核心业务场景更应该关注强一致性。所以很多高可用场景都会牺牲强一致性，保证最终一致性，满足AP特性，也就是在搞可用组件的选型上会主动的放弃zk，自己设计一条HA组件，比如RocketMq的高可用架构。