文章目录
- 什么是Nacos
- 基本架构
- 逻辑架构及其组件介绍
- 领域模型
- 数据模型
- 服务领域模型
- 配置领域模型
- 下载
- 目录结构
- 配置
- 启动
什么是Nacos
Nacos:(Dynamic) Naming and Configuration Service,动态的服务发现和配置的服务,是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。
Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。
服务(Service)是 Nacos 世界的一等公民。Nacos 支持几乎所有主流类型“服务”的发现、配置和管理:Kubernetes Service、gRPC & Dubbo RPC Service、Spring Cloud RESTful Service。
Nacos 真正将配置从应用中剥离出来,统一管理,优雅的解决了配置的动态变更、持久化、运维成本等问题。
应用自身既不需要去添加管理配置接口,也不需要自己去实现配置的持久化,更不需要引入“定时任务”以便降低运维成本。Nacos 提供的配置管理功能,将配置相关的所有逻辑都收拢,并且提供简单易用的 SDK,让应用的配置可以非常方便被 Nacos 管理起来。
核心:配置管理、服务发现,即配置中心、服务注册中心。
Nacos 的关键特性包括:
服务发现和服务健康监测
Nacos 支持基于 DNS 和基于 RPC 的服务发现。
Nacos 提供对服务的实时的健康检查,阻止向不健康的主机或服务实例发送请求。Nacos 支持传输层 (PING 或 TCP)和应用层 (如 HTTP、MySQL、用户自定义)的健康检查。
动态配置服务
动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。
动态配置消除了配置变更时重新部署应用和服务的需要,让配置管理变得更加高效和敏捷。
配置中心化管理让实现无状态服务变得更简单,让服务按需弹性扩展变得更容易。
动态 DNS 服务
动态 DNS 服务支持权重路由,让您更容易地实现中间层负载均衡、更灵活的路由策略、流量控制以及数据中心内网的简单DNS解析服务。动态DNS服务还能让您更容易地实现以 DNS 协议为基础的服务发现,以帮助您消除耦合到厂商私有服务发现 API 上的风险。
服务及其元数据管理
Nacos 能让您从微服务平台建设的视角管理数据中心的所有服务及元数据,包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略、服务的 SLA 以及最首要的 metrics 统计数据。
总结:使用 Nacos 简化服务发现、配置管理、服务治理及管理的解决方案,让微服务的发现、管理、共享、组合更加容易。
基本概念
配置服务 (Configuration Service)
在服务或者应用运行过程中,提供动态配置或者元数据以及配置管理的服务提供者。
Namespace
命名空间,租户粒度的配置隔离。不同的命名空间下,可以存在相同的 Group 或 Data ID 的配置。Namespace 的常用场景之一是不同环境配置的区分隔离,例如开发测试环境和生产环境的资源(如配置、服务)隔离等。默认public。
Configuration Item
配置项。一个具体的可配置的参数与其值域,通常以 param-key=param-value 的形式存在。例如我们常配置系统的日志输出级别(logLevel=INFO|WARN|ERROR) 就是一个配置项。
Configuration Set
配置集。一组相关或者不相关的配置项的集合称为配置集。在系统中,一个配置文件通常就是一个配置集。
Data ID
配置集ID,Data ID 通常用于组织划分系统的配置集。一个系统或者应用可以包含多个配置集,每个配置集都可以被一个有意义的名称标识。
Group
配置分组,区分 Data ID 相同的配置集。默认值 DEFAULT_GROUP 。配置分组的常见场景:不同的应用或组件使用了相同的配置类型,如 database_url 配置和 MQ_topic 配置。
名字服务 (Naming Service)
提供分布式系统中所有对象(Object)、实体(Entity)的“名字”到关联的元数据之间的映射管理服务,例如 ServiceName -> Endpoints Info, Distributed Lock Name -> Lock Owner/Status Info, DNS Domain Name -> IP List, 服务发现和 DNS 就是名字服务的2大场景。
Service
服务,通过预定义接口提供网络访问给客户端的软件功能。
ServiceName
服务名,服务提供的标识,通过该标识可以唯一确定其指代的服务。
Service Registry
服务注册中心,存储服务实例、服务元数据和服务负载均衡策略的数据库。服务实例在启动时注册到服务注册表,并在关闭时注销。服务和路由器的客户端查询服务注册表以查找服务的可用实例。服务注册中心可能会调用服务实例的健康检查 API 来验证它是否能够处理请求。
Service Discovery
服务发现,在计算机网络上,(通常使用服务名)对服务下实例的地址和元数据进行探测,并以预先定义的接口提供给客户端进行查询。
Metadata
元信息,Nacos数据(如配置和服务)描述信息,如服务版本、权重、容灾策略、负载均衡策略、鉴权配置、各种自定义标签 (label),从作用范围来看,分为服务级别的元信息、集群的元信息及实例的元信息。服务元数据是指包括服务端点(endpoints)、服务标签、服务版本号、服务实例权重、路由规则、安全策略等描述服务的数据。
Application
应用,服务的属性,用于标识服务提供方。
Service Group
服务分组,不同的服务可以归类到同一分组。
Virtual Claster
虚拟集群,同一个服务下的所有服务实例组成一个默认集群, 集群可以被进一步按需求划分,划分的单位可以是虚拟集群。
Instance
实例,提供一个或多个服务的具有可访问网络地址(IP:Port)的进程。
Weight
权重,实例级别的配置。权重为浮点数。权重越大,分配给该实例的流量越大。
Health Check
健康检查,以指定方式检查服务下挂载的实例 (Instance) 的健康度,从而确认该实例 (Instance) 是否能提供服务。根据检查结果,实例 (Instance) 会被判断为健康或不健康。对服务发起解析请求时,不健康的实例 (Instance) 不会返回给客户端。
Protect Threshold
健康保护阈值,为了防止因过多实例 (Instance) 不健康导致流量全部流向健康实例 (Instance) ,继而造成流量压力把健康实例 (Instance) 压垮并形成雪崩效应,应将健康保护阈值定义为一个 0 到 1 之间的浮点数。当域名健康实例数 (Instance) 占总服务实例数 (Instance) 的比例小于该值时,无论实例 (Instance) 是否健康,都会将这个实例 (Instance) 返回给客户端。这样做虽然损失了一部分流量,但是保证了集群中剩余健康实例 (Instance) 能正常工作。
基本架构
逻辑架构及其组件介绍
- OpenAPI:暴露标准Rest风格HTTP接口,简单易用,方便多语言集成
- Console:易用控制台,做服务管理、配置管理等操作
- SDK:多语言sdk
- Agent:dns-f类似模式,或者与mesh等方案集成
- CLI:命令行对产品进行轻量化管理,像git一样好用
领域模型
数据模型
Nacos 数据模型 Key 由三元组唯一确定, Namespace默认是空串,公共命名空间(public),Group默认是 DEFAULT_GROUP。
服务领域模型
配置领域模型
围绕配置,主要有两个关联的实体,一个是配置变更历史,一个是服务标签(用于打标分类,方便索引),由 ID 关联。
下载
在tags中找到想要下载的版本
下载链接
目录结构
配置
standalone单机模式中需要更改bin目录下的startup配置文件
windows修改.bat文件,linux修改.sh文件
找到MODE,将MODE修改为standalone,set MODE=“standalone”
Nacos支持多种数据库,默认是Mysql,在conf目录下有对应的Mysql脚本,mysql-schema.sql执行这一个就可以了。
导入mysql后编辑application配置文件将Mysql的信息配置上去
db.url.0=jdbc:mysql://192.168.0.110:3306/nacos?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true&useUnicode=true&useSSL=false&serverTimezone=UTC
db.user.0=root
db.password.0=root!@#123
启动
windows 环境下 进入bin目录下,双击startup.cmd文件
Linux 环境下通过命令启动
./startup.sh