原本在单体应用阶段常用的静态LB机制就不再适用，需要引入额外的组件来管理微服务提供者的注册与发现，而这个组件就是服务注册中心。

CAP理论是分布式架构中重要理论

  • 一致性(Consistency) (所有节点在同一时间具有相同的数据)

  • 可用性(Availability) (保证每个请求不管成功或者失败都有响应)

  • 分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)

ZK的设计原则是CP，即强一致性和分区容错性。他保证数据的强一致性，但舍弃了可用性，如果出现网络问题可能会影响ZK的选举，导致ZK注册中心的不可用。

Eureka的设计原则是AP，即可用性和分区容错性。他保证了注册中心的可用性，但舍弃了数据一致性，各节点上的数据有可能是不一致的（会最终一致）。

consul：支持CP,即保障一致性和分区容错性

nacos：支持AP和CP两种模式。可以分别支持AP和CP两种场景

Eureka

原理

注册中心选型 - 图1
生产者 服务注册 Register：
官方解释：当 Eureka Client 向 Eureka Server 注册时，它提供自身的元数据metaData，比如IP地址、端口，运行状况指示符URL，主页等。

生产者 服务续约 Renew：
官方解释：**Eureka** 客户会每隔30秒(默认情况下)发送一次心跳来续约。通过续约来告知 Eureka Server 该 Eureka 客户仍然存在，没有出现问题。正常情况下，如果 Eureka Server 在90秒没有收到 Eureka 客户的续约，它会将实例从其注册表中删除。

生产者 服务下线 Cancel：
官方解释：Eureka客户端在程序关闭时向Eureka服务器发送取消请求。发送请求后，该客户端实例信息将从服务器的实例注册表中删除。该下线请求不会自动完成，它需要调用以下内容：DiscoveryManager.getInstance().shutdownComponent();

服务剔除 Eviction：
官方解释：在默认的情况下，当Eureka客户端连续90秒(3个续约周期)没有向Eureka服务器发送服务续约，即心跳，Eureka服务器会将该服务实例从服务注册列表删除，即服务剔除。

消费者 获取注册列表信息 Fetch Registries：
官方解释：Eureka 客户端从服务器获取注册表信息，并将其缓存在本地。客户端会使用该信息查找其他服务，从而进行远程调用。该注册列表信息定期（每30秒钟）更新一次。每次返回注册列表信息可能与 Eureka 客户端的缓存信息不同, Eureka 客户端自动处理。如果由于某种原因导致注册列表信息不能及时匹配，Eureka 客户端则会重新获取整个注册表信息。Eureka 服务器缓存注册列表信息，整个注册表以及每个应用程序的信息进行了压缩，压缩内容和没有压缩的内容完全相同。Eureka 客户端和 Eureka 服务器可以使用JSON / XML格式进行通讯。在默认的情况下 Eureka 客户端使用压缩 JSON 格式来获取注册列表的信息。


Nacos

均提供服务注册和服务治理功能

模块 Nacos Eureka 说明
注册中心 是 服务治理基本功能，负责服务中心化注册
配置中心 是 否 Eureka需要配合Config实现配置中心，且不提供管理界面
动态刷新 是 否 Eureka需要配合MQ实现配置动态刷新，Nacos采用Netty保持TCP长连接实时推送
可用区AZ 是 对服务集群划分不同区域，实现区域隔离，并提供容灾自动切换
分组 是 否 Nacos可用根据业务和环境进行分组管理
元数据 是 是 提供服务标签数据，例如环境或服务标识
权重 是 否 Nacos默认提供权重设置功能，调整承载流量压力
健康检查 是 Nacos支持由客户端或服务端发起的健康检查，Eureka是由客户端发起心跳
负载均衡 是 是 均提供负责均衡策略，Eureka采用Ribion
管理界面 是 否 Nacos支持对服务在线管理，Eureka只是预览服务状态
模块 Nacos Eureka 说明
MySql 是 否 Nacos需要采用MySql进行数据进行持久化
MQ 否 是 Eureka需要采用MQ进行配置中心刷新
配置中心 是 否 Eureka结合Config或者Consul实现配置中心
配置文件 在线编辑 本地文件或者Git远程文件 Eureka结合Config或者Consul
集群 是 是 Nacos需要配置集群ip再启动


相比与Eureka：
(1)Nacos具备服务优雅上下线和流量管理（API+后台管理页面），而Eureka的后台页面仅供展示，需要使用api操作上下线且不具备流量管理功能。
(2)从部署来看，Nacos整合了注册中心、配置中心功能，把原来两套集群整合成一套，简化了部署维护
(3)从长远来看，Eureka开源工作已停止，后续不再有更新和维护，而Nacos在以后的版本会支持SpringCLoud+Kubernetes的组合，填补 2 者的鸿沟，在两套体系下可以采用同一套服务发现和配置管理的解决方案，这将大大的简化使用和维护的成本。同时来说,Nacos 计划实现 Service Mesh，是未来微服务的趋势
(4)从伸缩性和扩展性来看Nacos支持跨注册中心同步，而Eureka不支持，且在伸缩扩容方面，Nacos比Eureka更优（nacos支持大数量级的集群）。
(5)Nacos具有分组隔离功能，一套Nacos集群可以支撑多项目、多环境。
相比于apollo
(1) Nacos部署简化，Nacos整合了注册中心、配置中心功能，且部署相比apollo简单，方便管理和监控。
(2) apollo容器化较困难，Nacos有官网的镜像可以直接部署，总体来说，Nacos比apollo更符合KISS原则
(3)性能方面，Nacos读写tps比apollo稍强一些
结论：使用Nacos代替Eureka和apollo