Nacos简介

发表于   |   分类于

https://zhuanlan.zhihu.com/p/375912272 > https://www.cnblogs.com/crazymakercircle/p/14231815.html

1、Nacos 优势

问题，既然有了 Eureka ，为啥还要用 Nacos？
而 Nacos 作为微服务核心的服务注册与发现中心，让大家在 Eureka 和 Consule 之外有了新的选择，开箱即用，上手简洁，暂时也没发现有太大的坑。

1.1、与 eureka 对比

  • eureka 2.0 闭源码了
  • 从官网来看 nacos 的注册的实例数是大于 eureka 的
  • 因为 nacos 使用的 raft 协议,nacos 集群的一致性要远大于 eureka 集群

分布式一致性协议 Raft，自 2013 年论文发表，之后就受到了技术领域的热捧，与其他的分布式一致性算法比，Raft 相对比较简单并且易于实现，这也是 Raft 能异军突起的主要因素。
image.png
Raft 的数据一致性策略
Raft 协议强依赖 Leader 节点来确保集群数据一致性。即 client 发送过来的数据均先到达 Leader 节点，Leader 接收到数据后，先将数据标记为 uncommitted 状态，随后 Leader 开始向所有 Follower 复制数据并等待响应，在获得集群中大于 N/2 个 Follower 的已成功接收数据完毕的响应后，Leader 将数据的状态标记为 committed，随后向 client 发送数据已接收确认，在向 client 发送出已数据接收后，再向所有 Follower 节点发送通知表明该数据状态为 committed。

1.2、与 spring cloud config 对比

三大优势：

  • springcloud config 大部分场景结合 git 使用, 动态变更还需要依赖 Spring Cloud Bus 消息总线来通过所有的客户端变化
  • springcloud config 不提供可视化界面
  • nacos config 使用长连接更新配置, 一旦配置有变动后，通知 Provider 的过程非常的迅速, 从速度上秒杀 spring cloud 原来的 config 几条街

2、Spring Cloud Alibaba 套件

目前 Spring Cloud Alibaba 主要有三个组件：

  • Nacos：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
  • Sentinel：把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
  • AliCloud OSS: 阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。

Spring Cloud Alibaba 套件 和 Spring Cloud Netflix 套件类比
仔细看看各组件的功能描述，
Spring Cloud Alibaba 套件和 Spring Cloud Netflix 套件大致的对应关系：

  • Nacos = Eureka/Consule + Config + Admin
  • Sentinel = Hystrix + Dashboard + Turbine
  • Dubbo = Ribbon + Feign
  • RocketMQ = RabbitMQ
  • Schedulerx = Quartz
  • AliCloud OSS、AliCloud SLS 这三个应该是独有的

链路跟踪（Sleuth、Zipkin）不知道会不会在 Sentinel 里
以上只是猜测，待我从坑里爬出来之后再回来更新。也欢迎大家一起交流探讨~
这里我就先试试 Nacos。

3、Nacos 的架构和安装

3.1、Nacos 的架构

image.png
这是 Nacos 的架构图，可以看到它确实是融合了服务注册发现中心、配置中心、服务管理等功能，类似于 Eureka/Consule + Config + Admin 的合体。
另外通过官方文档发现，Nacos 除了可以和 Spring Cloud 集成，还可以和 Spring、SpringBoot 进行集成。不过我们只关注于 Spring Cloud，别的就略过了，直接上手实战吧。

3.2、Nacos Server 的下载和安装

在使用 Nacos 之前，需要先下载 Nacos 并启动 Nacos Server。
安装的参考教程：
https://www.cnblogs.com/crazymakercircle/p/11992539.html

4、Nacos Server 的运行

4.1、两种模式

Nacos Server 有两种运行模式：

  • standalone

  • cluster

4.2、standalone 模式

此模式一般用于 demo 和测试，不用改任何配置，直接敲以下命令执行
sh bin/startup.sh -m standalone
Windows 的话就是
cmd bin/startup.cmd -m standalone
然后从 http://cdh1:8848/nacos/index.html 进入控制台就能看到如下界面了
image.png
默认账号和密码为：nacos nacos

4.3、cluster 模式

测试环境，可以先用 standalone 模式撸起来，享受 coding 的快感，但是，生产环境可以使用 cluster 模式。
cluster 模式需要依赖 MySQL，然后改两个配置文件：
conf/cluster.conf
conf/application.properties
大致如下：
1、cluster.conf，填入要运行 Nacos Server 机器的 ip
192.168.100.155
192.168.100.156
2、修改 NACOS_PATH/conf/application.properties，加入 MySQL 配置

db.num=1
db.url.0=jdbc:mysql://localhost:3306/nacos_config?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true
db.user=root
db.password=root

创建一个名为 nacos_config 的 database，将 NACOS_PATH/conf/nacos-mysql.sql 中的表结构导入刚才创建的库中，这几张表的用途就自己研究吧

4.4、Nacos Server 的配置数据是存在哪里呢？

问题来了： Nacos Server 的配置数据是存在哪里呢？
我们没有对 Nacos Server 做任何配置，那么数据只有两个位置可以存储：

  • 内存
  • 本地数据库

如果我们现在重启刚刚在运行的 Nacos Server，会发现刚才加的 nacos.properties 配置还在，说明不是内存存储的。
这时候我们打开 NACOS_PATH/data，会发现里边有个 derby-data 目录，我们的配置数据现在就存储在这个库中。

Derby 是 Java 编写的数据库，属于 Apache 的一个开源项目

如果将数据源改为我们熟悉的 MySQL 呢？当然可以。

注意：不支持 MySQL 8.0 版本

这里有两个坑：

Nacos Server 的数据源是用 Derby 还是 MySQL 完全是由其运行模式决定的：

standalone 的话仅会使用 Derby，即使在 application.properties 里边配置 MySQL 也照样无视； cluster 模式会自动使用 MySQL，这时候如果没有 MySQL 的配置，是会报错的。
官方提供的 cluster.conf 示例如下

#it is ip
#example
10.10.109.214
11.16.128.34
11.16.128.36

以上配置结束后，运行 Nacos Server 就能看到效果了。

5、配置的隔离

在实际的应用中，存在着以下几种环境隔离的要求：
1、开发环境、测试环境、准生产环境和生产环境需要隔离
2、不同项目需要隔离
3、同一项目，不同的模块需要隔离
可以通过三种方式来进行配置隔离：Nacos 的服务器、namespace 命名空间、group 分组，在 bootstrap.yml 文件中可以通过配置 Nacos 的 server-addr、namespace 和 group 来区分不同的配置信息。

  • Nacos 的服务器 spring.cloud.nacos.config.server-addr
  • Nacos 的命名空间 spring.cloud.nacos.config.namespace，注意，这里使用命名空间的 ID 不是名称
  • Nacos 的分组 spring.cloud.nacos.config.group

6、nacos 集群搭建

如果我们要搭建集群的话，那么肯定是不能用内嵌的数据库，不然数据无法共享。所以，集群搭建的时候我们需要将 Nacos 对接 Mysql 进行数据存储。
集群模式跟我们平时进行扩容是一样的，可以通过 Nginx 转发到多个节点，最前面挂一个域名即可，如下图：image.png

IP 规划

通常如果我们只是为了体验的话，直接在本地起动 3 个实例就可以了，没必要真的去搞三台服务器，下面我们就以在本地的方式来搭建集群。 将 Nacos 的解压包复制分成 3 份，分别是:
nacos
nacos1
nacos2
进入 nacos 的 conf 目录，编辑 application.properties 文件，增加数据库配置

# 指定数据源为Mysql
spring.datasource.platform=mysql

# 数据库实例数量
db.num=1
db.url.0=jdbc:mysql://localhost:3306/nacos?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true
db.user=root
db.password=123456

复制代码同样的步骤进入 nacos1 和 nacos2 操作一遍，唯一需要修改的就是 application.properties 文件中的 server.port，默认 nacos 的 server.port=8848，
我们在本地启动三个实例，那么端口肯定会冲突，所以其他 2 个实例的端口我们需要进行修改，比如 nacos1 修改成 8847，nacos2 修改成 8846。
数据库配置信息好了后，我们需要将对应的数据库和表进行初始化，数据库脚本在 conf 目录下的 nacos-mysql.sql 中，执行即可。
最后一步需要配置一份集群节点信息，配置文件在 conf 目录下的 cluster.conf.example 文件，我们进行重命名成 cluster.conf。 然后编辑 cluster.conf 文件，增加 3 个节点的信息，格式为 IP:PORT，三个目录都一致即可。

127.0.0.1:8848
127.0.0.1:8847
127.0.0.1:8846

启动的话直接到 bin 目录下，执行./startup.sh 就可以了，默认就是集群模式，不需要加任何参数。

集群的使用

上面的集群，虽然可用， 但仍不是真正的集群， 我们一般不会这么用。nacos 集群的使用一般有 4 种方式：

  • http://ip1:port/openAPI 直连 ip 模式，不同的节点，则需要修改 ip 才可以使用。
  • http://VIP:port/openAPI VIP 模式高可用，客户端 vip 即可，VIP 下面挂 server 真实 ip，部署比较麻烦，需要部署 vip（keepalive）。
  • http://nacos.com:port/openAPI 域名模式，可读性好，而且换 ip 方便，在 host 文件配置本地域名即可。
  • http://反向代理:port/openAPI 反向代理模式

这里介绍一下反向代理模式。
关于 Nginx 的安装和配置，本文就不进行讲解了，不会的可以自己去尝试下，反向代理模式 核心配置如下：

upstream nacos_server {
  server 127.0.0.1:8848;
  server 127.0.0.1:8847;
  server 127.0.0.1:8846;
}

server {
listen 8648;
   server_name localhost;
  #charset koi8-r;
  #access_log logs/host.access.log main;
  location / {
     proxy_pass http://nacos_server;
     index index.html index.htm;
   }
}

整体来说，nacos 的集群搭建方式还是挺简单的，没什么特别要注意的，最好是能通过域名的方式来进行访问，另外数据库这块如果上生产环境，也需要考虑高可用问题，至少也得有个主从。
8648 的 nginx 提供的 nacos 服务接口，可以自定义。 我们访问
http://localhost:8648/nacos/#/clusterManagement?dataId=&group=&appName=&namespace=&serverId=
，就可以看到：
image.png
我们可以简单测试一下，杀掉 一个的 nacos ，看服务是否正常。 后面，我们对微服务提供 nacos 服务的时候，只要配置这个 nginx 端口就好了！！

新版本部署

Nacos2.0 版本相比 1.X 新增了 gRPC 的通信方式，因此需要增加 2 个端口。新增端口是在配置的主端口(server.port)基础上，进行一定偏移量自动生成。

端口 与主端口的偏移量 描述
9848 1000 客户端 gRPC 请求服务端端口，用于客户端向服务端发起连接和请求
9849 1001 服务端 gRPC 请求服务端端口，用于服务间同步等

使用 VIP/nginx 请求时，需要配置成 TCP 转发，不能配置 http2 转发，否则连接会被 nginx 断开。
image.png
客户端拥有相同的计算逻辑，用户如同 1.X 的使用方式，配置主端口(默认 8848)，通过相同的偏移量，计算对应 gRPC 端口(默认 9848)。
因此如果客户端和服务端之前存在端口转发，或防火墙时，需要对端口转发配置和防火墙配置做相应的调整。其余部署参考Nacos 部署手册 ，将版本相关替换成 2.0.0。

https://alicharles.oss-cn-hangzhou.aliyuncs.com/static/images/mp_qrcode.jpg
文章目录
  1. 1、Nacos 优势
    1. 1.1、与 eureka 对比
    2. 1.2、与 spring cloud config 对比
  2. 2、Spring Cloud Alibaba 套件
  3. 3、Nacos 的架构和安装
    1. 3.1、Nacos 的架构
    2. 3.2、Nacos Server 的下载和安装
  4. 4、Nacos Server 的运行
    1. 4.1、两种模式
    2. 4.2、standalone 模式
    3. 4.3、cluster 模式
    4. 4.4、Nacos Server 的配置数据是存在哪里呢？
  5. 5、配置的隔离
  6. 6、nacos 集群搭建
    1. IP 规划
    2. 集群的使用
    3. 新版本部署
Charles ©2022   浙ICP备14035515号-1