服务发现和服务健康监测

Nacos 支持基于 DNS 和基于 RPC 的服务发现。服务提供者使用原生SDK、OpenAPI、或一个独立的Agent TODO注册 Service 后，服务消费者可以使用DNS TODO 或HTTP&API查找和发现服务。

Nacos 提供对服务的实时的健康检查，阻止向不健康的主机或服务实例发送请求。Nacos 支持传输层 (PING 或 TCP)和应用层 (如 HTTP、MySQL、用户自定义）的健康检查。对于复杂的云环境和网络拓扑环境中（如 VPC、边缘网络等）服务的健康检查，Nacos 提供了 agent 上报模式和服务端主动检测2种健康检查模式。Nacos 还提供了统一的健康检查仪表盘，帮助您根据健康状态管理服务的可用性及流量。
动态配置服务

动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。

动态配置消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。

配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。

Nacos 提供了一个简洁易用的UI (控制台样例 Demo) 帮助您管理所有的服务和应用的配置。Nacos 还提供包括配置版本跟踪、金丝雀发布、一键回滚配置以及客户端配置更新状态跟踪在内的一系列开箱即用的配置管理特性，帮助您更安全地在生产环境中管理配置变更和降低配置变更带来的风险。
动态 DNS 服务

动态 DNS 服务支持权重路由，让您更容易地实现中间层负载均衡、更灵活的路由策略、流量控制以及数据中心内网的简单DNS解析服务。动态DNS服务还能让您更容易地实现以 DNS 协议为基础的服务发现，以帮助您消除耦合到厂商私有服务发现 API 上的风险。

Nacos 提供了一些简单的 DNS APIs TODO 帮助您管理服务的关联域名和可用的 IP:PORT 列表.
服务及其元数据管理

Nacos 能让您从微服务平台建设的视角管理数据中心的所有服务及元数据，包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略、服务的 SLA 以及最首要的 metrics 统计数据。
更多的特性列表 ...

Nacos 地图

一图看懂 Nacos，下面架构部分会详细介绍。

特性大图：要从功能特性，非功能特性，全面介绍我们要解的问题域的特性诉求
架构大图：通过清晰架构，让您快速进入 Nacos 世界
业务大图：利用当前特性可以支持的业务场景，及其最佳实践
生态大图：系统梳理 Nacos 和主流技术生态的关系
优势大图：展示 Nacos 核心竞争力
战略大图：要从战略到战术层面讲 Nacos 的宏观优势

Nacos 生态图

如 Nacos 全景图所示，Nacos 无缝支持一些主流的开源生态，例如

使用 Nacos 简化服务发现、配置管理、服务治理及管理的解决方案，让微服务的发现、管理、共享、组合更加容易。

关于如何在这些生态中使用 Nacos，请参考以下文档：

Nacos与Spring Cloud一起使用

Nacos 概念

NOTE: Nacos 引入了一些基本的概念，系统性的了解一下这些概念可以帮助您更好的理解和正确的使用 Nacos 产品。

地域

物理的数据中心，资源创建成功后不能更换。

可用区

同一地域内，电力和网络互相独立的物理区域。同一可用区内，实例的网络延迟较低。

接入点

地域的某个服务的入口域名。

命名空间

用于进行租户粒度的配置隔离。不同的命名空间下，可以存在相同的 Group 或 Data ID 的配置。Namespace 的常用场景之一是不同环境的配置的区分隔离，例如开发测试环境和生产环境的资源（如配置、服务）隔离等。

配置

在系统开发过程中，开发者通常会将一些需要变更的参数、变量等从代码中分离出来独立管理，以独立的配置文件的形式存在。目的是让静态的系统工件或者交付物（如 WAR，JAR 包等）更好地和实际的物理运行环境进行适配。配置管理一般包含在系统部署的过程中，由系统管理员或者运维人员完成。配置变更是调整系统运行时的行为的有效手段。

配置管理

系统配置的编辑、存储、分发、变更管理、历史版本管理、变更审计等所有与配置相关的活动。

配置项

一个具体的可配置的参数与其值域，通常以 param-key=param-value 的形式存在。例如我们常配置系统的日志输出级别（logLevel=INFO|WARN|ERROR）就是一个配置项。

配置集

一组相关或者不相关的配置项的集合称为配置集。在系统中，一个配置文件通常就是一个配置集，包含了系统各个方面的配置。例如，一个配置集可能包含了数据源、线程池、日志级别等配置项。

配置集 ID

Nacos 中的某个配置集的 ID。配置集 ID 是组织划分配置的维度之一。Data ID 通常用于组织划分系统的配置集。一个系统或者应用可以包含多个配置集，每个配置集都可以被一个有意义的名称标识。Data ID 通常采用类 Java 包（如 com.taobao.tc.refund.log.level）的命名规则保证全局唯一性。此命名规则非强制。

配置分组

Nacos 中的一组配置集，是组织配置的维度之一。通过一个有意义的字符串（如 Buy 或 Trade ）对配置集进行分组，从而区分 Data ID 相同的配置集。当您在 Nacos 上创建一个配置时，如果未填写配置分组的名称，则配置分组的名称默认采用 DEFAULT_GROUP 。配置分组的常见场景：不同的应用或组件使用了相同的配置类型，如 database_url 配置和 MQ_topic 配置。

配置快照

Nacos 的客户端 SDK 会在本地生成配置的快照。当客户端无法连接到 Nacos Server 时，可以使用配置快照显示系统的整体容灾能力。配置快照类似于 Git 中的本地 commit，也类似于缓存，会在适当的时机更新，但是并没有缓存过期（expiration）的概念。

服务

通过预定义接口网络访问的提供给客户端的软件功能。

服务名

服务提供的标识，通过该标识可以唯一确定其指代的服务。

服务注册中心

存储服务实例和服务负载均衡策略的数据库。

服务发现

在计算机网络上，（通常使用服务名）对服务下的实例的地址和元数据进行探测，并以预先定义的接口提供给客户端进行查询。

元信息

Nacos数据（如配置和服务）描述信息，如服务版本、权重、容灾策略、负载均衡策略、鉴权配置、各种自定义标签 (label)，从作用范围来看，分为服务级别的元信息、集群的元信息及实例的元信息。

应用

用于标识服务提供方的服务的属性。

服务分组

不同的服务可以归类到同一分组。

虚拟集群

同一个服务下的所有服务实例组成一个默认集群, 集群可以被进一步按需求划分，划分的单位可以是虚拟集群。

实例

提供一个或多个服务的具有可访问网络地址（IP:Port）的进程。

权重

实例级别的配置。权重为浮点数。权重越大，分配给该实例的流量越大。

健康检查

以指定方式检查服务下挂载的实例 (Instance) 的健康度，从而确认该实例 (Instance) 是否能提供服务。根据检查结果，实例 (Instance) 会被判断为健康或不健康。对服务发起解析请求时，不健康的实例 (Instance) 不会返回给客户端。

健康保护阈值

为了防止因过多实例 (Instance) 不健康导致流量全部流向健康实例 (Instance) ，继而造成流量压力把健康健康实例 (Instance) 压垮并形成雪崩效应，应将健康保护阈值定义为一个 0 到 1 之间的浮点数。当域名健康实例 (Instance) 占总服务实例 (Instance) 的比例小于该值时，无论实例 (Instance) 是否健康，都会将这个实例 (Instance) 返回给客户端。这样做虽然损失了一部分流量，但是保证了集群的剩余健康实例 (Instance) 能正常工作。

Nacos 架构

基本架构及概念

服务 (Service)

服务是指一个或一组软件功能（例如特定信息的检索或一组操作的执行），其目的是不同的客户端可以为不同的目的重用（例如通过跨进程的网络调用）。Nacos 支持主流的服务生态，如 Kubernetes Service、gRPC|Dubbo RPC Service 或者 Spring Cloud RESTful Service.

服务注册中心 (Service Registry)

服务注册中心，它是服务，其实例及元数据的数据库。服务实例在启动时注册到服务注册表，并在关闭时注销。服务和路由器的客户端查询服务注册表以查找服务的可用实例。服务注册中心可能会调用服务实例的健康检查 API 来验证它是否能够处理请求。

服务元数据 (Service Metadata)

服务元数据是指包括服务端点(endpoints)、服务标签、服务版本号、服务实例权重、路由规则、安全策略等描述服务的数据

服务提供方 (Service Provider)

是指提供可复用和可调用服务的应用方

服务消费方 (Service Consumer)

是指会发起对某个服务调用的应用方

配置 (Configuration)

在系统开发过程中通常会将一些需要变更的参数、变量等从代码中分离出来独立管理，以独立的配置文件的形式存在。目的是让静态的系统工件或者交付物（如 WAR，JAR 包等）更好地和实际的物理运行环境进行适配。配置管理一般包含在系统部署的过程中，由系统管理员或者运维人员完成这个步骤。配置变更是调整系统运行时的行为的有效手段之一。

配置管理 (Configuration Management)

在数据中心中，系统中所有配置的编辑、存储、分发、变更管理、历史版本管理、变更审计等所有与配置相关的活动统称为配置管理。

名字服务 (Naming Service)

提供分布式系统中所有对象(Object)、实体(Entity)的“名字”到关联的元数据之间的映射管理服务，例如 ServiceName -> Endpoints Info, Distributed Lock Name -> Lock Owner/Status Info, DNS Domain Name -> IP List, 服务发现和 DNS 就是名字服务的2大场景。

配置服务 (Configuration Service)

在服务或者应用运行过程中，提供动态配置或者元数据以及配置管理的服务提供者。

逻辑架构及其组件介绍

服务管理：实现服务CRUD，域名CRUD，服务健康状态检查，服务权重管理等功能
配置管理：实现配置管CRUD，版本管理，灰度管理，监听管理，推送轨迹，聚合数据等功能
元数据管理：提供元数据CURD 和打标能力
插件机制：实现三个模块可分可合能力，实现扩展点SPI机制
事件机制：实现异步化事件通知，sdk数据变化异步通知等逻辑
日志模块：管理日志分类，日志级别，日志可移植性（尤其避免冲突），日志格式，异常码+帮助文档
回调机制：sdk通知数据，通过统一的模式回调用户处理。接口和数据结构需要具备可扩展性
寻址模式：解决ip，域名，nameserver、广播等多种寻址模式，需要可扩展
推送通道：解决server与存储、server间、server与sdk间推送性能问题
容量管理：管理每个租户，分组下的容量，防止存储被写爆，影响服务可用性
流量管理：按照租户，分组等多个维度对请求频率，长链接个数，报文大小，请求流控进行控制
缓存机制：容灾目录，本地缓存，server缓存机制。容灾目录使用需要工具
启动模式：按照单机模式，配置模式，服务模式，dns模式，或者all模式，启动不同的程序+UI
一致性协议：解决不同数据，不同一致性要求情况下，不同一致性机制
存储模块：解决数据持久化、非持久化存储，解决数据分片问题
Nameserver：解决namespace到clusterid的路由问题，解决用户环境与nacos物理环境映射问题
CMDB：解决元数据存储，与三方cmdb系统对接问题，解决应用，人，资源关系
Metrics：暴露标准metrics数据，方便与三方监控系统打通
Trace：暴露标准trace，方便与SLA系统打通，日志白平化，推送轨迹等能力，并且可以和计量计费系统打通
接入管理：相当于阿里云开通服务，分配身份、容量、权限过程
用户管理：解决用户管理，登录，sso等问题
权限管理：解决身份识别，访问控制，角色管理等问题
审计系统：扩展接口方便与不同公司审计系统打通
通知系统：核心数据变更，或者操作，方便通过SMS系统打通，通知到对应人数据变更
OpenAPI：暴露标准Rest风格HTTP接口，简单易用，方便多语言集成
Console：易用控制台，做服务管理、配置管理等操作
SDK：多语言sdk
Agent：dns-f类似模式，或者与mesh等方案集成
CLI：命令行对产品进行轻量化管理，像git一样好用

领域模型

数据模型

Nacos 数据模型 Key 由三元组唯一确定, Namespace默认是空串，公共命名空间（public），分组默认是 DEFAULT_GROUP。

nacos_data_model

服务领域模型

nacos_naming_data_model

配置领域模型

围绕配置，主要有两个关联的实体，一个是配置变更历史，一个是服务标签（用于打标分类，方便索引），由 ID 关联。

nacos_config_er

类视图

Nacos-SDK 类视图

服务部分待续

nacos_sdk_class_relation

构建物、部署及启动模式

undefined

两种交付工件

Nacos 支持标准 Docker 镜像(TODO: 0.2版本开始支持）及 zip(tar.gz)压缩包的构建物。

两种启动模式

Nacos 支持将注册中心(Service Registry）与配置中心(Config Center) 在一个进程合并部署或者将2者分离部署的两种模式。

免费的公有云服务模式

除了您自己部署和启动 Nacos 服务之外，在云计算时代，Nacos 也支持公有云模式，在阿里云公有云的商业产品（如ACM, EDAS) 中会提供 Nacos 的免费的公有云服务。我们也欢迎和支持其他的公有云提供商提供 Nacos 的公有云服务。

Nacos功能和需求列表

本文列举了目前Nacos支持的主要功能和一些还未支持的需求排期，方便读者了解目前Nacos已经支持和计划支持的能力，同时所有计划支持的能力都开放给开发者进行认领，本文末有详细的认领教程。

在下面的表格中，每个需求都有一个状态的标志，包含若干种取值，各种取值的含义如下：

状态的取值：
不支持：该功能还不支持，且没有在现在的时间表里有任何排期；
排期中：该功能还不支持，但是已经放到了时间表里，有希望在后面的某个版本支持；
设计中：表示该功能正在方案设计中，方案的草稿和终稿都会开放访问，供大家讨论；
开发中：表示该功能设计方案已经确定，正在有对应的开发者进行开发，会在接下来的某个版本正式发布；
beta：该功能已经发布，但是未经过大规模的用户验证，还不能确保稳定性；
稳定：表示已经迭代至少4个版本，目前没有反馈重大缺陷；

服务发现

代码地址：https://github.com/alibaba/nacos/tree/develop/naming

描述	主要开发者	状态	排期
服务注册与发现	nkorange	稳定	0.1.0
健康检查（服务端探测、客户端心跳）	xuanyin	稳定	0.1.0
路由策略（权重、保护阈值、就近访问）	wangjianwei	稳定	0.1.0

配置管理

代码地址：https://github.com/alibaba/nacos/tree/develop/config

描述	主要开发者	状态	排期
配置管理（发布、修改、查询、监听配置）	yanlinly	稳定	0.1.0
灰度配置	yanlinly	稳定	1.1.0
加密配置		不支持

元数据管理

代码地址：https://github.com/alibaba/nacos/tree/develop/cmdb

描述	主要开发者	状态	排期
对接第三方CMDB	nkorange	beta	0.7.0

地址服务器

代码地址：https://github.com/alibaba/nacos/tree/develop/address

描述	主要开发者	状态	排期
支持Nacos寻址	pbting	beta	1.1.0

Nacos内核

代码地址：https://github.com/alibaba/nacos/tree/develop/core

描述	主要开发者	状态
去除MySQL依赖	chuntaojun	设计中
Raft协议替换成JRaft	chuntaojun	设计中
异步通知机制统一	wfnuser	设计中
线程模块统一		排期中
传输通道统一	nkorange	设计中
推送模块统一	satjd	设计中
启动模块统一		排期中

安全与稳定性

代码地址：https://github.com/alibaba/nacos

描述	主要开发者	状态	排期
命名空间模块下沉为公共模块		排期中
权限控制，包括认证与鉴权	nkorange	开发中	1.2.0
操作审计与记录		排期中
支持加密传输		排期中
OpenTracing对接		排期中
metrics收集	TsingLiang	稳定	0.8.0
缓存容灾机制统一		排期中
支持命令行运维		排期中
数据自动备份		排期中
限流模块		排期中
容量管理		排期中

代码质量

代码地址：https://github.com/alibaba/nacos

描述	主要开发者	状态
工具类模块统一		排期中
常量定义统一		排期中
异常处理模块统一		排期中
日志模块统一		排期中
系统参数模块统一		排期中
依赖统一		排期中
状态码模块统一	KeRan213539	设计中

云原生

描述	主要开发者	状态	排期
对接Istio	nkorange	beta	1.1.4
对接ConfigMap		排期中
对接CoreDNS	JianweiWang	beta	0.1.0
对接SPIFFE		排期中

客户端

客户端支持包含了目前已知的Nacos多语言客户端及Spring生态的相关客户端，除了Java客户端和Go客户端，其他均为社区热心贡献者开发，如果您有新的语言的客户端，或者有目前已经支持的语言的客户端的另外一个实现，欢迎在github上留言进行登记。

描述	主要开发者	状态
Java客户端	Nacos	稳定
Go客户端	atlanssia, lzp0412	稳定
Node.js客户端	czy88840616, gxcsoccer	稳定
Python客户端	sanwei	beta
C#客户端	catcherwong	推荐
C++客户端
PHP客户端
Spring客户端	chuntaojun	稳定
SpringBoot客户端	chuntaojun	稳定

Nacos-Docker

代码地址：https://github.com/nacos-group/nacos-docker

描述	主要开发者	状态	排期
Docker部署Nacos Server	paderlol	稳定	0.1.0

Nacos-K8s

代码地址：https://github.com/nacos-group/nacos-k8s

描述	主要开发者	状态	排期
K8s部署Nacos Server	paderlol	稳定	0.1.0

Nacos-Sync

代码地址：https://github.com/nacos-group/nacos-sync

描述	主要开发者	状态	排期
Nacos与Nacos服务双向同步	paderlol	稳定	0.1.0
Nacos与Zookeeper服务双向同步	paderlol	稳定	0.3.0
Nacos与Eureka服务双向同步	paderlol	稳定	0.3.0
Nacos与Consul服务双向同步	paderlol	稳定	0.3.0

Nacos官网

代码地址：https://github.com/nacos-group/nacos-group.github.io

描述	主要开发者	状态	排期
支持页面内锚链接		不支持

参与共建

参与共建能得到什么？

参与Nacos共建，你将有机会让你的代码被全中国甚至全世界的用户阅读并使用，同时在成为Nacos Committer后（如何成为Nacos Committer可以参考手册），还可以有以下福利：

在Nacos官网团队页留名；
收到我们带Nacos logo的小礼物，有T恤、水杯、帽衫等等；
代表Nacos参加各种线上线下活动，与更多小伙伴交流；
更多我们还在筹划中的福利；

如何共建

除了在上面列举的功能和需求，其他的在github仓库上打上了contribution welcome或者help wanted标签的issue，也非常欢迎大家提交代码贡献。加入Nacos 社区核心贡献小组钉钉群23335652，联系群管理员认领需求。

大家提PR的时候有几点需要注意下：

比较重大的特性需要有方案文档：https://github.com/alibaba/nacos/issues/858
已经阅读并遵守共建规范： https://github.com/alibaba/nacos/blob/master/CONTRIBUTING.md
使用github账户提交代码，这样大家才会在contributor列表看到自己的名字；
commit信息要带上issue id，这样才能在issue里看到PR的进度；
代码中不要出现中文注释，提交前要格式化，并添加必要的集成测试用例和单元测试用例；
提PR前运行mvn -Prelease-nacos clean install -U和mvn clean install -Pit-test成功；

任务认领原则：每人一次最多领取两个任务，任务PR合并后，即可开始认领下个任务。

Nacos微服务注册发现、配置和管理微服务

Nacos介绍

什么是 Nacos？

Nacos 地图

Nacos 生态图

Nacos 概念

地域

可用区

接入点

命名空间

配置

配置管理

配置项

配置集

配置集 ID

配置分组

配置快照

服务

服务名

服务注册中心

服务发现

元信息

应用

服务分组

虚拟集群

实例

权重

健康检查

健康保护阈值

Nacos 架构

基本架构及概念

服务 (Service)

服务注册中心 (Service Registry)

服务元数据 (Service Metadata)

服务提供方 (Service Provider)

服务消费方 (Service Consumer)

配置 (Configuration)

配置管理 (Configuration Management)

名字服务 (Naming Service)

配置服务 (Configuration Service)

更多概念...

逻辑架构及其组件介绍

领域模型

数据模型

服务领域模型

配置领域模型

类视图

Nacos-SDK 类视图

构建物、部署及启动模式

两种交付工件

两种启动模式

免费的公有云服务模式

Nacos功能和需求列表

服务发现

配置管理

元数据管理

地址服务器

Nacos内核

安全与稳定性

代码质量

云原生

客户端

Nacos-Docker

Nacos-K8s

Nacos-Sync

Nacos官网

参与共建

参与共建能得到什么？

如何共建

猜你喜欢