Nacos架构与原理 - 注册中心的设计原理

 作者简介：大家好，我是码炫码哥，前中兴通讯、美团架构师，现任某互联网公司CTO，兼职码炫课堂主讲源码系列专题

代表作：《jdk源码&多线程&高并发》，《深入tomcat源码解析》，《深入netty源码解析》，《深入dubbo源码解析》，《深入springboot源码解析》，《深入spring源码解析》，《深入redis源码解析》等

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬。码炫课堂的个人空间-码炫码哥个人主页-面试，源码等

释放21集全网最深ConcurrentHashMap的vip视频，复现每一行源码 

Pre

目前的网络架构是每个主机都有⼀个独立的 IP 地址，那么服务发现基本上都是通过某种方式获取到服务所部署的 IP 地址。

DNS 协议是最早将⼀个网络名称翻译为网络 IP 的协议，在最初的架构选型中，
DNS+LVS+Nginx 基本可以满足所有的 RESTful 服务的发现，此时服务的 IP 列表通常配置在 nginx或者 LVS。

后来出现了 RPC 服务，服务的上下线更加频繁，人们开始寻求⼀种能够支持动态上下线并且推送 IP 列表变化的注册中心产品。

个人开发者或者中小型公司往往会将开源产品作为选型首选。

• Zookeeper 是⼀款经典的服务注册中心产品（虽然它最初的定位并不在于此），在很长⼀段时间里，它是国人在提起 RPC 服务注册中心时心里想到的唯⼀选择，这很大程度上与 Dubbo 在中国的普及程度有关。

• Consul 和 Eureka 都出现于 2014 年，Consul 在设计上把很多分布式服务治理上要用到的功能都包含在内，可以支持服务注册、健康检查、配置管理、Service Mesh 等。而 Eureka则借着微服务概念的流行，与 SpringCloud 生态的深度结合，也获取了大量的用户。

• Nacos则携带着阿里巴巴大规模服务生产经验，试图在服务注册和配置管理这个市场上，提供给用户⼀个新的选择。

  

---

服务的分级模型 （服务-集群-实例三层模型）

注册中心的核心数据存储模型一般分为三层:

• 服务 级别:存储服务名称和网络地址,以及服务级别的属性,如权限规则等。
• 集群 级别:针对大规模服务,其实例可能划分为不同的集群,每个集群又有不同的配置,所以在服务和实例之间再增加一个集群级别的数据。
• 实例 级别:存储实例的网络地址,健康状态,权重等属性。针对实例级别的数据可以实现实例过滤、流量分配等功能。</