微服务之Nacos、Eureka

1.1 服务注册和发现基本概念

服务注册：将某个或者某些服务的信息（模块的ip和端口）注册到一个公用的组件上。

服务发现：新注册的模块信息能够被其他调用者发现，无论是服务的新增还是服务的剔除都可以知晓。

1.2 web1.0数据请求模型框架

在传统的项目框架中，没有服务的注册和发现组件，因为当时的服务架构比较简单，都是单体应用服务，这里不存在，服务的注册和发现因为这是一个单体的服务，足够应对当时的网络用户需求，但是所着科技的进步和社会的发展，这种单体的应用架构不足以支持业务的发展。

1.3 web2.0数据请求模型框架

随着用户变多，单体服务扛不住用户的请求压力时，我们将服务进行水平扩展，增加服务器，来应对用户的请求，用户的请求经过nginx来进行负载均衡到后面的服务器，这种架构虽然可以抗住用户的请求，但是服务的信息是配置在nginx上面，如果需要进行增加模块或者对一些应用进行扩展，还需要在nginx上面配置一遍，对运维人员非常不友好，而且服务太多了不好管理。

1.4 web3.0微服务框架

微服务即每个应用抽取出来成为一个独立的服务，部署在相同或者不同的服务器上面，彼此之间独立解耦，这种架构虽然解耦好扩展，但是随着业务的发展后面服务越来越多，服务的管理越来越复杂，如果进行服务之间的调用，可能需要将各个服务的信息写入数据库等其他地方，这种情况下服务的地址就是写死的很不容易进行扩展，所以便出现了服务管理组件

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

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

因此，原本在单体应用阶段常用的静态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固有的缓存缺陷，本文不对第三类注册方式作深入探讨。

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

• 测活：服务注册之后，如何对服务进行测活以保证服务的可用性？

• 负载均衡：当存在多个服务提供者时，如何均衡各个提供者的负载？

• 集成：在服务提供端或者调用端，如何集成注册中心？

• 运行时依赖：引入注册中心之后，对应用的运行时环境有何影响？

• 可用性：如何保证注册中心本身的可用性，特别是消除单点故障？

zuaj

	Nacos	Eureka	Consul	CoreDNS	Zookeeper
一致性协议	CP+AP	AP	CP	—	CP
健康检查	TCP/HTTP/MYSQL/Client Beat	Client Beat	TCP/HTTP/gRPC/Cmd	—	Keep Alive
负载均衡策略	权重/ metadata/Selector	Ribbon	Fabio	RoundRobin	—
雪崩保护	有	有	无	无	无
自动注销实例	支持	支持	支持	不支持	支持
访问协议	HTTP/DNS	HTTP	HTTP/DNS	DNS	TCP
监听支持	支持	支持	支持	不支持	支持
多数据中心	支持	支持	支持	不支持	不支持
跨注册中心同步	支持	不支持	支持	不支持	不支持
SpringCloud集成	支持	支持	支持	不支持	支持
Dubbo集成	支持	不支持	支持	不支持	支持
K8S集成	支持	不支持	支持	支持	不支持

1、协议：

eureka内部是AP协议，即它可以保证服务的高可用，但是对于一致性的要求不高

zookepper内部是CP协议，即它可以保证服务的数据一致性，但是对于服务的可用性要求不高

nacos内部是AP/CP协议，默认AP协议，如果对一致性的要求比较高可以切换为CP协议

2、雪崩保护：

eureka是存在雪崩保护机制的，服务注册列表会缓存再调用方的本地

zookepper没有雪崩保护机制

nacos的雪崩保护机制和eureka的原理相同，将服务的注册列表保存在调用方的本地

3、容器化部署：

eureka和zookepper暂时不支持k8s

nacos在这方面是支持的

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

1. Eureka不再从注册表中移除因为长时间没有收到心跳而过期的服务；

2. Eureka仍然能够接受新服务注册和查询请求，但是不会被同步到其它节点上（即保证当前节点依然可用）；

3. 当网络稳定时，当前实例新注册的信息会被同步到其它节点中；

因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使得整个注册服务瘫痪。

Nacos

---

Nacos是阿里开源的，Nacos 支持基于 DNS 和基于 RPC 的服务发现。在Spring Cloud中使用Nacos，只需要先下载 Nacos 并启动 Nacos server，Nacos只需要简单的配置就可以完成服务的注册发现。

Nacos除了服务的注册发现之外，还支持动态配置服务。动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。动态配置消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。

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