SpringCloud（二） 微服务架构-服务注册与发现

注册中心原理

　　注册中心主要涉及到三大角色：服务提供者、服务消费者、注册中心。它们之间的关系大致如下：

• 各个微服务在启动时，将自己的网络地址等信息注册到注册中心，注册中心存储这些数据。
• 服务消费者从注册中心查询服务提供者的地址，并通过该地址调用服务提供者的接口。
• 各个微服务与注册中心使用一定机制（例如心跳）通信。如果注册中心与某微服务长时间无法通信，就会注销该实例。
• 微服务网络地址发送变化（例如实例增加或IP变动等）时，会重新注册到注册中心。这样，服务消费者就无需人工修改提供者的网络地址了。

CAP理论

• 一致性(Consistency) (数据一致性)
• 可用性(Availability) (服务可用性)
• 分隔容忍(Partition tolerance) (服务对网络分区故障的容错性)

　　在分布式环境下，必须选择 P，因为网络原因可能出现故障，所以分区是一个必然现象。因此，分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP。

　　CP（一致性、分区容错性）

　　例如 N1 和 N2 两个节点，N1 上的数据更新为了y，同步到 N2 之前，网络中断，发生分区，N2 上还是旧的数据 x。为了保证一致性，当客户端访问 N2 时，N2 不能返回 x，需要提示系统发生了错误，返回 error，这就违背了可用性原则。

　　AP（可用性/分区容忍性） 　　

　　还是上面的场景，为了保证可用性，N2 返回 x，但不是最新的数据，违背了一致性原则。

 注册中心对比

 　　①Zookeeper

　　Zookeeper是Apache下非常著名的一个顶级项目。它保证的是CP，即任何时刻对Zookeeper的访问请求能得到一致性的数据结果，同时系统对网络分区具备容错性，但是它不能保证每次服务请求的可用性。如果Zookeeper正在选主，或者Zookeeper集群中半数以上的机器不可用，那么就无法获取数据。因此Zookeeper适合涉及数据存储的场景。

　　 ②Eureka

　　Spring Cloud Netflix 在设计 Eureka 时就紧遵AP原则（尽管现在2.0发布了，但是由于其闭源的原因 ，但是目前 Ereka 1.x 任然是比较活跃的）。Eureka Server 也可以运行多个实例来构建集群，解决单点问题，但不同于 ZooKeeper 的选举 leader 的过程，Eureka Server 采用的是Peer to Peer 对等通信。这是一种去中心化的架构，无 master/slave 之分，每一个 Peer 都是对等的。在这种架构风格中，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点。每个节点都可被视为其他节点的副本。

　　 ③Consul

　　Consul 是一个支持多数据中心分布式高可用的服务发现和配置共享的服务软件,由 HashiCorp 公司用 Go 语言开发。在官方网站最新的介绍中，Consul 定义为Service Mesh的解决方案。Consul 遵循CAP原理中的CP原则，保证了强一致性和分区容错性，且使用的是Raft算法，比zookeeper使用的Paxos算法更加简单。虽然保证了强一致性，但是可用性就相应下降了，例如服务注册的时间会稍长一些，因为 Consul 的 raft 协议要求必须过半数的节点都写入成功才认为注册成功 ；在leader挂掉了之后，重新选举出leader之前会导致Consul 服务不可用。

　　 ④Nacos

　　Nacos是阿里开源的，Nacos 支持基于 DNS 和基于 RPC 的服务发现。Nacos除了服务的注册发现之外，还支持动态配置服务。Nacos支持AP和CP两种模式。

• 一般来说，如果 不需要存储 服务级别的信息，且服务实例是通过Nacos-client注册，并能够保持心跳上报，那么就可以选择AP模式。AP模式为了服务的可用性而减弱了一致性，因此AP模式下只能注册 临时实例
• 如果需要在服务级别 编辑或存储 配置信息，那么CP是必须，K8S服务和DNS服务则适用于CP服务，CP模式下则支持注册持久化实例，此时则是以Raft协议为集群运行模式，该模式下注册实例之前必须先注册服务，如果服务不存在，则会返回错误