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就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：
-
Eureka不再从注册表中移除因为长时间没有收到心跳而过期的服务；
-
Eureka仍然能够接受新服务注册和查询请求，但是不会被同步到其它节点上（即保证当前节点依然可用）；
-
当网络稳定时，当前实例新注册的信息会被同步到其它节点中；
因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使得整个注册服务瘫痪。
Nacos
Nacos除了服务的注册发现之外，还支持动态配置服务。动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。动态配置消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。
一句话概括就是Nacos = Spring Cloud注册中心 + Spring Cloud配置中心。