前言

服务注册核心实质上是为理解耦服务提供者和服务消费者。对于任何一个微服务，原则上都应存在或者反对多个提供者，这是由微服务的分布式属性决定的。

更进一步，为了反对弹性扩缩容个性，一个微服务的提供者的数量和散布往往是动态变化的，也是无奈预先确定的。

因而，本来在单体利用阶段罕用的动态 LB 机制就不再实用了，须要引入额定的组件来治理微服务提供者的注册与发现，而这个组件就是服务注册核心。

CAP 实践

CAP 实践是分布式架构中重要实践

• 一致性(Consistency) (所有节点在同一时间具备雷同的数据)
• 可用性(Availability) (保障每个申请不论胜利或者失败都有响应)
• 分隔容忍(Partition tolerance) (零碎中任意信息的失落或失败不会影响零碎的持续运作)

对于 P 的了解，我感觉是在整个零碎中某个局部，挂掉了，或者宕机了，并不影响整个零碎的运作或者说应用，

而可用性是，某个零碎的某个节点挂了，然而并不影响零碎的承受或者发出请求，CAP 不可能都取，只能取其中 2 个

起因是如果 C 是第一需要的话，那么会影响 A 的性能，因为要数据同步，不然申请后果会有差别，然而数据同步会耗费工夫，期间可用性就会升高。

如果 A 是第一需要，那么只有有一个服务在，就能失常承受申请，然而对与返回后果变不能保障，起因是，在分布式部署的时候，数据统一的过程不可能想切线路那么快。

再如果，共事满足一致性和可用性，那么分区容错就很难保障了，也就是单点，也是分布式的根本外围，好了，明确这些实践，就能够在相应的场景选取服务注册与发现了

服务注册核心解决方案

设计或者选型一个服务注册核心，首先要思考的就是服务注册与发现机制。纵观当下各种支流的服务注册核心解决方案，大抵可归为三类：

• 利用内：间接集成到利用中，依赖于利用本身实现服务的注册与发现，最典型的是 Netflix 提供的 Eureka
• 利用外：把利用当成黑盒，通过利用外的某种机制将服务注册到注册核心，最小化对利用的侵入性，比方 Airbnb 的 SmartStack，HashiCorp 的 Consul
• DNS：将服务注册为 DNS 的 SRV 记录，严格来说，是一种非凡的利用外注册形式，SkyDNS 是其中的代表

注 1：对于第一类注册形式，除了 Eureka 这种一站式解决方案，还能够基于 ZooKeeper 或者 Etcd 自行实现一套服务注册机制，这在大公司比拟常见，但对于小公司而言显然性价比太低。

注 2：因为 DNS 固有的缓存缺点，本文不对第三类注册形式作深入探讨。

除了根本的服务注册与发现机制，从开发和运维角度，至多还要思考如下五个方面：

• 测活：服务注册之后，如何对服务进行测活以保障服务的可用性？
• 负载平衡：当存在多个服务提供者时，如何平衡各个提供者的负载？
• 集成：在服务提供端或者调用端，如何集成注册核心？
• 运行时依赖：引入注册核心之后，对利用的运行时环境有何影响？
• 可用性：如何保障注册核心自身的可用性，特地是打消单点故障？

支流注册核心产品

软件产品个性并非变化无穷，如果发现性能个性有变更，欢送评论斧正

• Consul 是反对主动登记服务实例，请见文档：https://www.consul.io/api-doc…，在 check 的 DeregisterCriticalServiceAfter 这个参数。
• 新版本的 Dubbo 也扩大了对 Consul 的反对。参考: https://github.com/apache/dub…

Apache Zookeeper -> CP

与 Eureka 有所不同，Apache Zookeeper 在设计时就紧遵 CP 准则，即任何时候对 Zookeeper 的拜访申请能失去统一的数据后果，同时系统对网络宰割具备容错性，然而 Zookeeper 不能保障每次服务申请都是可达的。

从 Zookeeper 的理论利用状况来看，在应用 Zookeeper 获取服务列表时，如果此时的 Zookeeper 集群中的 Leader 宕机了，该集群就要进行 Leader 的选举，又或者 Zookeeper 集群中半数以上服务器节点不可用（例如有三个节点，如果节点一检测到节点三挂了，节点二也检测到节点三挂了，那这个节点才算是真的挂了），那么将无奈解决该申请。所以说，Zookeeper 不能保障服务可用性。

当然，在大多数分布式环境中，尤其是波及到数据存储的场景，数据一致性应该是首先被保障的，这也是 Zookeeper 设计紧遵 CP 准则的另一个起因。

然而对于服务发现来说，状况就不太一样了，针对同一个服务，即便注册核心的不同节点保留的服务提供者信息不尽相同，也并不会造成灾难性的结果。

因为对于服务消费者来说，能生产才是最重要的，消费者尽管拿到可能不正确的服务实例信息后尝试生产一下，也要胜过因为无奈获取实例信息而不去生产，导致系统异样要好（淘宝的双十一，京东的 618 就是紧遵 AP 的最好参照）。

当 master 节点因为网络故障与其余节点失去分割时，残余节点会从新进行 leader 选举。问题在于，选举 leader 的工夫太长，30~120s，而且选举期间整个 zk 集群都是不可用的，这就导致在选举期间注册服务瘫痪。

在云部署环境下，因为网络问题使得 zk 集群失去 master 节点是大概率事件，尽管服务能最终复原，然而漫长的选举事件导致注册长期不可用是不能容忍的。

Spring Cloud Eureka -> AP

Spring Cloud Netflix 在设计 Eureka 时就紧遵 AP 准则（只管当初 2.0 公布了，然而因为其闭源的起因，然而目前 Ereka 1.x 任然是比拟沉闷的）。

Eureka Server 也能够运行多个实例来构建集群，解决单点问题，但不同于 ZooKeeper 的选举 leader 的过程，Eureka Server 采纳的是 Peer to Peer 对等通信。这是一种去中心化的架构，无 master/slave 之分，每一个 Peer 都是对等的。在这种架构格调中，节点通过彼此相互注册来进步可用性，每个节点须要增加一个或多个无效的 serviceUrl 指向其余节点。每个节点都可被视为其余节点的正本。

在集群环境中如果某台 Eureka Server 宕机，Eureka Client 的申请会主动切换到新的 Eureka Server 节点上，当宕机的服务器从新复原后，Eureka 会再次将其纳入到服务器集群治理之中。当节点开始承受客户端申请时，所有的操作都会在节点间进行复制（replicate To Peer）操作，将申请复制到该 Eureka Server 以后所知的其它所有节点中。

当一个新的 Eureka Server 节点启动后，会首先尝试从邻近节点获取所有注册列表信息，并实现初始化。Eureka Server 通过 getEurekaServiceUrls() 办法获取所有的节点，并且会通过心跳契约的形式定期更新。

默认状况下，如果 Eureka Server 在肯定工夫内没有接管到某个服务实例的心跳（默认周期为 30 秒），Eureka Server 将会登记该实例（默认为 90 秒，eureka.instance.lease-expiration-duration-in-seconds 进行自定义配置）。

当 Eureka Server 节点在短时间内失落过多的心跳时，那么这个节点就会进入自我保护模式。

Eureka 的集群中，只有有一台 Eureka 还在，就能保障注册服务可用（保障可用性），只不过查到的信息可能不是最新的（不保障强一致性）。除此之外，Eureka 还有一种自我爱护机制，如果在 15 分钟内超过 85% 的节点都没有失常的心跳，那么 Eureka 就认为客户端与注册核心呈现了网络故障，此时会呈现以下几种状况：

1. Eureka 不再从注册表中移除因为长时间没有收到心跳而过期的服务；
2. Eureka 依然可能承受新服务注册和查问申请，然而不会被同步到其它节点上（即保障以后节点仍然可用）；
3. 当网络稳固时，以后实例新注册的信息会被同步到其它节点中；

因而，Eureka 能够很好的应答因网络故障导致局部节点失去分割的状况，而不会像 zookeeper 那样使得整个注册服务瘫痪。

Consul：

Consul 是 HashiCorp 公司推出的开源工具，用于实现分布式系统的服务发现与配置。Consul 应用 Go 语言编写，因而具备人造可移植性（反对 Linux、windows 和 Mac OS X）。

Consul 内置了服务注册与发现框架、散布一致性协定实现、健康检查、Key/Value 存储、多数据中心计划，不再须要依赖其余工具（比方 ZooKeeper 等），应用起来也较为简单。

Consul 遵循 CAP 原理中的 CP 准则，保障了强一致性和分区容错性，且应用的是 Raft 算法，比 zookeeper 应用的 Paxos 算法更加简略。尽管保障了强一致性，然而可用性就相应降落了，例如服务注册的工夫会稍长一些，因为 Consul 的 raft 协定要求必须过半数的节点都写入胜利才认为注册胜利；在 leader 挂掉了之后，从新选举出 leader 之前会导致 Consul 服务不可用。

Consul 实质上属于利用外的注册形式，但能够通过 SDK 简化注册流程。而服务发现恰好相反，默认依赖于 SDK，但能够通过 Consul Template（下文会提到）去除 SDK 依赖。

Consul Template

Consul，默认服务调用者须要依赖 Consul SDK 来发现服务，这就无奈保障对利用的零侵入性。

所幸通过 Consul Template，能够定时从 Consul 集群获取最新的服务提供者列表并刷新 LB 配置（比方 nginx 的 upstream），这样对于服务调用者而言，只须要配置一个对立的服务调用地址即可。

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

1. 服务注册相比 Eureka 会稍慢一些。因为 Consul 的 raft 协定要求必须过半数的节点都写入胜利才认为注册胜利
2. Leader 挂掉时，从新选举期间整个 consul 不可用。保障了强一致性但就义了可用性。

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

1. 服务注册绝对要快，因为不须要等注册信息 replicate 到其余节点，也不保障注册信息是否 replicate 胜利
2. 当数据呈现不统一时，尽管 A, B 上的注册信息不完全相同，但每个 Eureka 节点仍然可能失常对外提供服务，这会呈现查问服务信息时如果申请 A 查不到，但申请 B 就能查到。如此保障了可用性但就义了一致性。

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

Nacos：

Nacos 是阿里开源的，Nacos 反对基于 DNS 和基于 RPC 的服务发现。在 Spring Cloud 中应用 Nacos，只须要先下载 Nacos 并启动 Nacos server，Nacos 只须要简略的配置就能够实现服务的注册发现。

Nacos 除了服务的注册发现之外，还反对动静配置服务。动静配置服务能够让您以中心化、内部化和动态化的形式治理所有环境的利用配置和服务配置。动静配置打消了配置变更时重新部署利用和服务的须要，让配置管理变得更加高效和麻利。配置中心化治理让实现无状态服务变得更简略，让服务按需弹性扩大变得更容易。

一句话概括就是 Nacos = Spring Cloud 注册核心 + Spring Cloud 配置核心。

参考链接：

https://yq.aliyun.com/article…

https://nacos.io

作者：琦彦 \
链接：https://blog.csdn.net/fly9109…\
版权申明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协定，转载请附上原文出处链接和本申明。
近期热文举荐：

1.600+ 道 Java 面试题及答案整顿(2021 最新版)

2. 终于靠开源我的项目弄到 IntelliJ IDEA 激活码了，真香！

3. 阿里 Mock 工具正式开源，干掉市面上所有 Mock 工具！

4.Spring Cloud 2020.0.0 正式公布，全新颠覆性版本！

5.《Java 开发手册（嵩山版）》最新公布，速速下载！

感觉不错，别忘了顺手点赞 + 转发哦！