是时候了解下 nacos 了!(一)

本文涉及的产品
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: 是时候了解下 nacos 了!(一)

nacos 简介


在 nacos-0.3 的时候我就开始关注,期间还写过一篇作为 Spring Cloud 配置中心的使用记录的博客。在前不久,nacos 终于出了正式版,赶个时髦出篇博客吹一波。


nacos 特性


服务发现和服务健康监测


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

动态配置服务


动态配置服务可以让开发者以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置(可以作为配置中心)。动态配置消除了配置变更时重新部署应用和服务的需要,让配置管理变得更加高效和敏捷。配置中心化管理让实现无状态服务变得更简单,让服务按需弹性扩展变得更容易。Nacos 提供了一个简洁易用的 UI 帮助开发者管理所有的服务和应用的配置。Nacos 还提供包括配置版本跟踪、金丝雀发布、一键回滚配置以及客户端配置更新状态跟踪在内的一系列开箱即用的配置管理特性,帮助开发者更安全地在生产环境中管理配置变更和降低配置变更带来的风险。


动态 DNS 服务


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

服务及其元数据管理


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


nacos的相关概念


  • 地域 (Region):物理的数据中心,资源创建成功后不能更换。
  • 可用区(Available Zone):同一地域内,电力和网络互相独立的物理区域。同一可用区内,实例的网络延迟较低。
  • 接入点(Endpoint):地域的某个服务的入口域名。
  • 命名空间(Namespace):用于进行租户粒度的配置隔离。不同的命名空间下,可以存在相同的 Group 或 Data ID 的配置。Namespace 的常用场景之一是不同环境的配置的区分隔离,例如开发测试环境和生产环境的资源(如配置、服务)隔离等。
  • 元信息(Metadata):Nacos 数据(如配置和服务)描述信息,如服务版本、权重、容灾策略、负载均衡策略、鉴权配置、各种自定义标签 (label),从作用范围来看,分为服务级别的元信息、集群的元信息及实例的元信息。
  • 实例(Instance):提供一个或多个服务的具有可访问网络地址(IP:Port)的进程。
  • 权重(Weight):实例级别的配置。权重为浮点数。权重越大,分配给该实例的流量越大。
  • 健康检测(Health Check):以指定方式检查服务下挂载的实例 (Instance) 的健康度,从而确认该实例 (Instance) 是否能提供服务。根据检查结果,实例 (Instance) 会被判断为健康或不健康。对服务发起解析请求时,不健康的实例 (Instance) 不会返回给客户端。
  • 健康保护阈值(Protect Threshold):为了防止因过多实例 (Instance) 不健康导致流量全部流向健康实例 (Instance) ,继而造成流量压力把健康 健康实例 (Instance) 压垮并形成雪崩效应,应将健康保护阈值定义为一个 0 到 1 之间的浮点数。当域名健康实例 (Instance) 占总服务实例 (Instance) 的比例小于该值时,无论实例 (Instance) 是否健康,都会将这个实例 (Instance) 返回给客户端。这样做虽然损失了一部分流量,但是保证了集群的剩余健康实例 (Instance) 能正常工作。
  • 服务分组(Service Group):不同的服务可以归类到同一分组。
  • 虚拟集群(Virtual Cluster):同一个服务下的所有服务实例组成一个默认集群, 集群可以被进一步按需求划分,划分的单位可以是虚拟集群。


nacos 使用


安装


可在 GitHub 上下载安装包安装,或者采用 docker 安装。

Windows 上运行:

在 GitHub 查看该项目的 releases 并下载最新版,解压后进入 bin 目录 运行 startup.cmd

docker 上运行:


docker run --name nacos-standalone -e MODE=standalone -p 8848:8848 nacos/nacos-server:latest


可运行一个单机版nacos

浏览器上访问 ip:8848/nacos 进入登陆界面,用户名和密码都是 nacos;登陆成功就能看到控制台 UI 界面了。在安装包的 ./conf 目录下有一个 application.properties 文件,这是 nacos 的配置文件。


作为配置中心


示例


这里为方便讲解,我们现在 Windows 环境下运行一个单机版 nacos ,启动后登陆,创建一个 SpringBoot 应用,导入依赖

 <dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-alibaba-nacos-config</artifactId>
    <version>0.9.0.RELEASE</version>
 </dependency>

然后删除 application.properties 新建一个 bootstrap.properties 。这里可能还有同学不知道 application 和 bootstrap 的区别,在这里科普一下:在 Spring Boot 中有两种上下文,一种是 bootstrap , 另外一种是 application , bootstrap 是应用程序的父上下文,也就是说 bootstrap 加载优先于 application 。bootstrap 主要用于从额外的资源来加载配置信息,还可以在本地外部配置文件中解密属性。这两个上下文共用一个环境,它是任何 Spring 应用程序的外部属性的来源。bootstrap 里面的属性会优先加载,它们默认也不能被本地相同配置覆盖。bootstrap 比 application 要先加载,bootstrap 只在 cloud 项目中使用。

添加配置:

#服务名
spring.application.name=nacos-config-example
# 配置中心url
spring.cloud.nacos.config.server-addr=127.0.0.1:8848
# 配置中心的配置语法
spring.cloud.nacos.config.file-extension=properties

现在在 nacos 配置中心新建配置:

dataId:nacos-config-example.properties

e7376c17b2300e3c905d800534ce05ff_640_wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1.png


启动项目,发现项目端口号是8082,我们的配置成功了。

说明

注意 图中几个选项 TEXT\JSON\ XML \YAML\ HTML\Propertiest 这些并不是指定 nacos 以何种语法去解析配置文件,仅仅是提供语法提示,代码高亮辅助样式;第一次使用的人很容易被误导。我们要指定配置文件语法要在bootstrap做如下配置:

spring.cloud.nacos.config.file-extension=properties
spring.cloud.nacos.config.file-extension=yaml

配置中心配置依靠dataId将配置信息和客户端绑定,我们来看看dataId组成规则:


${prefix}-${spring.profile.active}.${file-extension}

prefix 默认为 spring.application.name 的值,也可以通过配置项 spring.cloud.nacos.config.prefix 来配置。

spring.profile.active 即为当前环境对应的 profile , 注意:当 spring.profile.active 为空时,对应的连接符 - 也将不存在,dataId 的拼接格式变成 prefix.{prefix}.{file-extension}

file-exetension 为配置内容的数据格式,可以通过配置项 spring.cloud.nacos.config.file-extension 来配置。目前只支持 propertiesyaml 类型。


也就是说我们这个配置中心的 dataId 和我们平时用 Spring Boot 命名配置文件只有一个 prefix 的区别

现在我们来修改一下配置文件,bootstrap 加一项:

spring.cloud.nacos.config.prefix=config-test
spring.profiles.active=dev

配置中心弄两个配置方便比较,一个 dataId 是 config-test-dev.properties ,一个 dataId 是 config-test-prod.properties 配置端口号分别为 8081 和 8082 测试。启动项目后发现项目端口号为 8081,然后修改配置重启:


spring.profiles.active=prod


此时端口变成了 8082。用法和 Spring Boot 的配置文件区别不大。


相关文章
|
6月前
|
Nacos
|
存储 关系型数据库 MySQL
Nacos 2.0.3和Nacos 2.2.3版本
Nacos 2.0.3和Nacos 2.2.3版本
843 1
|
4天前
|
监控 网络协议 Nacos
介绍一下Nacos
介绍一下Nacos
|
1月前
|
网络协议 Java Nacos
Nacos的应用
Nacos的应用
47 0
|
5月前
|
SQL 关系型数据库 MySQL
详解nacos使用
详解nacos使用
116 0
|
Nacos
Nacos 配置文件属性说明
Nacos 配置文件属性说明
211 0
|
6月前
|
Nacos
Nacos的某些配置
Nacos的某些配置
71 2
|
存储 运维 网络安全
Nacos使用总结
Nacos使用总结
204 0
|
存储 负载均衡 Java
Nacos
Nacos
633 0
|
负载均衡 网络协议 前端开发
是时候了解下 nacos 了!(二)
是时候了解下 nacos 了!(二)