目录
Nacos简介
Nacos特性
Nacos 地图
Nacos 生态图
各种服务注册中心模型区别
Nacos的AP和CP
Nacos 何时选择切换模式
命名空间、分组和DataId
名词解释
三者关系
默认情况
具体情况
Nacos集群
Nacos持久化配置
官方网站
home
用户手册
什么是 Nacos
Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集,帮助您实现动态服务发现、服务配置管理、服务及流量管理。
相当于注册中心+配置中心
Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构(例如微服务范式、云原生范式)的服务基础设施。
服务(Service)是 Nacos 世界的一等公民。Nacos 支持几乎所有主流类型的“服务”的发现、配置和管理
服务发现和服务健康监测
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设计的时候重复的考虑到了市场化的运作(市面上大多都是以单一的实现形式为主,例如:Zookeeper使用的是 CP、而 Eureka采用的是AP),在Nacos中提供了两种模式的动态切换。
1.一般来说,如果不需要储存服务界别的信息且服务实例通过nacos-client注册,并能够保持心跳上报,那么就可以选择AP模式。如Spring Cloud和Dubbo,都适用于AP模式, AP模式为了服务的可用性减弱了一致性,因此AP模式下只支持注册临时实例。
2.如果需要在服务级别编辑或者储存配置信息,那么CP是必须的,K8S服务和DNS服务则是用于CP模式。CP模式下则支持注册持久化实例,此时则是以Raft协议为集群运行模式,该模式下注册实例之前必须先注册服务,如果服务不存在,则会返回错误。
3. 切换命令(默认是AP):
cur1 -X PUT 'SNACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP'
注意:临时和持久化的区别主要在健康检查失败后的表现,持久化实例健康检查失败后会被标记成不健康,而临时实例会直接从列表中被删除。
命名空间(Namespace)
用于进行租户粒度的配置隔离。不同的命名空间下,可以存在相同的Group或Data ID的配置。Namespace的常用场景之一是不同环境的配置的区分隔离,例如开发测试环境和生产环境的资源(如配置、服务)隔离等。
配置分组(Group)
Nacos中的一组配置集,是组织配置的维度之一。通过一个有意义的字符串(如 Buy 或Trade )对配置集进行分组,从而区分DataID相同的配置集(即一个命名空间下,不同的分组,可以有相同名称的配置文件)。当您在Nacos上创建一个配置时,如果未填写配置分组的名称,则配置分组的名称默认采用DEFAULT_GROUP。配置分组的常见场景:不同的应用或组件使用了相同的配置类型,如 database_url 配置和 MQ_topic 配置。
配置集ID (Data ID)
Nacos中的某个配置集的ID。配置集 ID 是组织划分配置的维度之一(一个真实的系统有一个或者多个dataId)。Data ID 通常用于组织划分系统的配置集。一个系统或者应用可以包含多个配置集,每个配置集都可以被一个有意义的名称标识。Data ID通常采用类Java包(如com.taobao.tc.refund.log.level)的命名规则保证全局唯一性。此命名规则非强制。
配置集:一组相关或者不相关的配置项的集合称为配置集。在系统中,一个配置文件通常就是一个配置集,包含了系统各个方面的配置。例如,一个配置集可能包含了数据源、线程池、日志级别等配置项。
这三者的关系类似于Java里面的package名和类名,最外层的Namespace是可以用于区分部署环境的,Group和DatalD逻辑上区分两个目标对象。
Namespace=public, Group=DEFAULT_GROUP,默认Cluster是DEFAULT
Nacos默认的命名空间是public,我们就可以利用Namespace来实现隔离,比如我们现在有三个环境:开发、测试、生产环境,我们就可以创建三个Namespace,不同的N amespace之间是隔离的。
Group本身就是分组的意思,它可以把不同的微服务划分到同一个分组里面去。
剩下的就是具体微服务,一个Service可以包含多个Cluster, Nacos默认Cluster是DEFAULT, Cluster是对指定微服务的一个虚拟划分。比如说,将一个Service部署在北京和和杭州的机房中,北京机房的Service就可以起名为(BJ),杭州机房中的Service就可以起名为(HZ),这样就可以尽量让同一个机房的微服务互相调用,提升性能。
Nacos支持三种部署模式
1.单机模式-用于测试和单机试用
2.集群模式-用于生产环境,确保高可用
3.多集群模式 - 用于多数据中心场景
集群部署说明
参考网站: https://nacos.io/zh-cn/docs/cluster-mode-quick-start.html
架构图:部署生产使用的集群模式
预备环境
默认Nacos使用嵌入式数据库实现数据的存储,所以,如果启动多个默认配置下的Nacos节点,数据储存存在一致性问题,为了解决这个问题,Nacos采用了集中存储方式来支持集群化部署,目前仅支持MySql的存储。
1.推荐使用Linux
2.可以使用内部数据源或者外部数据源(推荐使用外部)MySql
Nacos默认自带嵌入式数据库derby,所以我们每次创建一个Nacos实例就会有一个derby,当有多个Nacos节点的时候,就会出现一致性问题,所以Nacos支持了外部数据库统一数据管理MySql。