微服务架构 | 服务注册发现中心/配置中心/消息总线 - [nacos]

INDEX

§1 简介§2 简单使用§2.1 搭建 nacos-server§2.2 作为服务注册发现中心§2.3 作为服务配置中心§2.4 切换 nacos 的一致性协议 §3 配置的层次和分组§4 集群 & 持久化实战§4.1 变更 nacos 的持久化§4.2 准备 nacos 实例§4.3 加入 nginx 支持§4.4 项目应用

§1 简介

Nacos =NamingConfigrationService

在 SpringCloud alibaba 中，nacos 同时扮演了 服务注册发现中心、配置中心、消息总线等角色。

nacos 与其他注册中心特性对比

§2 简单使用

§2.1 搭建 nacos-server

在官网下载

/alibaba/nacos

移动到指定位置并解压安装

tar -zxvf nacos-server-2.1.0.tar.gz

启动 nacos 服务

sh startup.sh -m standalone

使用 localhost:8848/nacos 本机访问

非本机访问

在非本机上，使用 ip:8848/nacos 可能连接超时，按下面步骤尝试

关闭防火墙

service iptables stop

重试访问若访问成功，添加防火墙规则

vim /etc/sysconfig/iptables

然后在文件中按队形增加一行

-A INPUT -m state --state NEW -m tcp -p tcp --dport 8080 -j ACCEPT

重启防火墙 (不用 restart是因为不成功，分开操作就可以了，原因不明)

service iptables stop

service iptables start

§2.2 作为服务注册发现中心

注意事项：

nacos 可以同时成为 springcloud 的配置中心和服务发现中心但两个职能对应的依赖、配置文件、配置项均不同

provider / comsumer 均按如下配置

默认服务调用方式同 ribbon

依赖

<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId></dependency>

配置文件

在application.yml中

server:port: 9001spring:application:name: provider-nacoscloud:nacos:discovery:server-addr: 192.168.3.10:8848

服务启动后可见

§2.3 作为服务配置中心

依赖

<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId></dependency>

配置文件

在bootstrap.yml中

server:port: 3377spring:application:name: nacos-config-clientcloud:nacos:config:server-addr: 192.168.3.10:8848file-extension: ymldiscovery:server-addr: 192.168.3.10:8848

在application.yml中

spring:profiles:active: dev

配置文件

注意使用注解@RefreshScope，以支持热更新

除下面示例中的@ConfigurationProperties外，@Value的方式也支持

@Configuration@ConfigurationProperties(prefix = "config")@RefreshScopepublic class ConfigTest {String info;/* ******************************** 以下是 setter/getter******************************* */public String getInfo() {return info;}public void setInfo(String info) {this.info = info;}}

在 nacos 控制台添加配置

Data ID

即配置文件名，完整格式如下

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

${prefix} 默认是 ${spring.application.name} 的值，即示例中的nacos-config-client${prefix} 也可以通过 ${spring.cloud.nacos.config.prefix} 配置${spring.profiles.active} 即示例中的dev${spring.profiles.active} 可以省略，省略时，前面的 - 也会省略，但强烈建议保留${file-extension} 即示例中的yml${file-extension} 的值必须与 ${spring.cloud.nacos.config.file-extension} 一致，比如混淆 yml 和 yaml 会导致问题（虽然二者其实是一回事）

Group

默认是 DEFAULT_GROUP

配置格式

配置格式要和配置文件名(Data ID)的后缀相匹配

配置内容

配置内容的格式要和配置格式相匹配

§2.4 切换 nacos 的一致性协议

curl -X ==PUT== '**$NACOS_SERVER**:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP'

§3 配置的层次和分组

nacos 中，如下图所示，

每个配置文件依次有三级所属层次，由概念的从大到小依次为

namespace，命名空间，默认publicGroup，组，默认DEFAULT_GROUPData Id，数据id(配置文件名)，默认${prefix}-${spring.profiles.active}.${file-extension}

namespace、group 和 data id 的作用和实践(存疑)

说明

众多视频和帖子在讲解 nacos 时，多数会涉及上述三个配置层次，感谢各位大佬的分享。

但讲解的过程中鲜见对应用场景的套用，尤其在演示切换不同 namespace、group、data_id 的作用时，均以通过切换上述三个层次已达到切换 DEV/TEST/PROD 环境为例。

笔者学习时递归懵逼，无法区分三者在真实使用上的区别。

从 nacos 的官网(nacos.io)中，笔者未找到三者比较明确的配置指导，比如 namespace 是用来具体配置什么的（也可能是没找对地方[手动捂脸]）。

由此， namespace、group 和 data id可能不存在比较严格的使用标准，而只是配置中心划分出三个维度，用来区分各个配置文件，以方便研发人员使用。因此，在示例项目的部署场景比较简单的情况下可以十分灵活的使用它们，只要别找不到正确的配置即可（否则无法解释为啥众多教程使用“不恰当”的例子）。

但这仨层级毕竟不是按namespace.group.data_id的形式出现在 nacos 中的，命名空间甚至是个单独的标签页，因此肯定存在需要进行明确区分的场景。

一种在应用上可行的使用方案

下面，结合使用 apollo 的经验，尝试分享一种可行的使用方案，谬误之处请各位大佬斧正。

首先三个配置层级的关系如下 图 3-1 所示无疑

然后我们设想一个使用 nacos 的场景，并尽量假设的复杂一点

有一个公司，叫 company，为了防止过于灵活假设它很大（废话，小公司小项目都多余上配置中心）因此，company 下有多个业务线，换句话说，好多产品，每个产品都是一个项目，P1/P2/P3每个项目都有很多子项目，或者服务，P1s1/P1s2/P2s1/P2s2……每个服务下有多个实例(instance)每个项目在部署时，为了异地容灾都会部署在多个机房，company 本部/武汉/成都……机房考虑进一步灾备，防止一套环境挂了后，所有使用此服务的业务都挂了，于是又划分了多个集群，单个个集群负责业务中的一部分现在，company 搭建了一个 nacos 平台作为配置中心

上述内容如下 图 3-2 所示：

对比 图 3-1 和 图 3-2，我们可以如下使用三者：

data id

作用于 instance，它的作用是使一些实例按当前配置进行启动

一个标准的 data id 主要包含两个维度，

${prefix} 用来标注属于哪个服务(service)，默认值是 ${spring.application.name}${spring.profiles.active} 用来标注属于哪个环境，默认值是 ${spring.profiles.active}data id 可能存在更多维度，此时可以通过 ${spring.cloud.nacos.config.prefix} 配置 比如 P1s1 需要两个配置文件，可以参考 Nacos加载多个配置集 中的场景一个用来配置相关环境比如 kafka 地址另一个配置业务比如这个服务太小了所以不需要记录日志

namespace

作用于项目或者租户，以区分不同项目中的同名服务（“那个瓜是孙红雷的，与我闰土何干！”）

项目和租户在某些平台（比如 OpenStack）上是同一个概念，

每个项目加入配置中心，占用一块资源。对于配置中心来说，这个项目就是一个租户

group(主要是这里存疑)

作用于 data id 往上，namespace 往下的中间维度

组是对服务实例的分组，

这里的服务实例不局限于同一个服务

比如只要是部署在武汉机房的服务实例，无论属于的哪个服务只要用了 kafka 的，都配置成某个地址同时一个服务的所有实例也不一定都在同一个组里

比如都是 P1s1 的实例，划分两个集群，一个处理客户1（这里的客户可能是指一个公司）的业务，另一个处理客户2

总结（顺便皮一下）

若有如下配置文件

namespace = coding dog ICU each-help platformgroup = wuhan_oldestdata id = roast-publish-flow-prod.yml

这个配置文件用来配置代码狗 ICU 互助平台(coding dog ICU each-help platform)这个项目里，我也来喷一段(roast-publish-flow)这个服务的生产环境(prod)

服务部署在多个机房，现在这个配置文件是部署在武汉(wuhan)机房的实例用的

并且武汉的机房有多套环境，有的旧有的新，这个业务线的一部分还是跑在最老性能最差的那套环境(_oldest)里的，因为没办法，都 ICU 了，都上最新的环境太贵

§4 集群 & 持久化实战

在 §2 简单使用 中，完成了 单点 nacos 的搭建和使用。

但是，实际开发、生产环境中不可能按上面的姿势使用 nacos

standalone 的结构摆明了是等着单点故障standalone 的 nacos 使用的内嵌的 derby 数据库，这意味着如果只是简单的部署多节点，会导致节点间的数据隔离

因此，实践上需要向下 图4-1 所示架构进行调整，官方文档 见此 和 此

nacos 的官方文档，有的前面的文章说过的事，后面的文章就不提了，所以只能一起看

下面的示例中（出 nacos 外的集群使用单点代替）

使用 nginx 反向代理 nacos 集群，并对外暴露虚拟 ip持久化层使用 mysql

§4.1 变更 nacos 的持久化

准备 mysql 实例

略

创建 nacos 库

在 nacos 的安装目录的 config 路径下，有一个 nacos 出厂自带的建库 sql 文件，如下 图 4-1-1

使用它建立自己的 nacos 库(手动建库，sql 文件内容粘出来，运行即可) ，效果如下图

修改配置文件

配置文件即 图4-1-1 中application.properties

按官网教程配置

效果如下，注意红框处于实际建库使用的数据库名一致

重启 nacos 验证

先单点重启 nacos，查看持久化层切换效果

sh startup.sh -m standalone

看到一个空白的 nacos

创建一个配置，在数据库中查看数据

§4.2 准备 nacos 实例

PS:现在停止上一节启动的 nacos，如果没有，后面实践时会出现莫名其妙的问题

cluster.conf

cluster.conf 用于配置集群内各节点的ip:port，因为是纵向集群模拟，所以示例中使用端口号区分

同时参考 §2.1 搭建 nacos-server#非本机访问 的方式配置防火墙（注意重启）

startup.sh(在这个示例中很重要)

nacos 是基于 JVM 运行的，默认的 nacos 集群模式配置 JVM 的参数为

-Xms2g -Xmx2g -Xmn1g -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=320m

若机器性能有限，需要调整启动脚本以降低硬件需求（实际开发生产环境务必不要这样搞）

startup.sh 的摘要和修改点如下：

#!/bin/bash## 这里有一大坨代码## 指令参数对应的变量export SERVER="nacos-server"export MODE="cluster"export FUNCTION_MODE="all"export MEMBER_LIST=""export EMBEDDED_STORAGE=""# 接受指令参数while getopts ":m:f:s:c:p:" optdocase $opt inm)MODE=$OPTARG;;# 依次用接受的参数给上面变量复制?)echo "Unknown parameter"exit 1;;esacdone#===========================================================================================# JVM Configuration，# nacos 是基于 java 的，这里是针对 -m 参数给 jvm 配置启动参数 #===========================================================================================if [[ "${MODE}" == "standalone" ]]; thenJAVA_OPT="${JAVA_OPT} -Xms512m -Xmx512m -Xmn256m" # 抄这里JAVA_OPT="${JAVA_OPT} -Dnacos.standalone=true"elseif [[ "${EMBEDDED_STORAGE}" == "embedded" ]]; thenJAVA_OPT="${JAVA_OPT} -DembeddedStorage=true"fi# 抄到这里，原始的值是 -Xms2g -Xmx2g -Xmn1g -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=320mJAVA_OPT="${JAVA_OPT} -server -Xms512m -Xmx512m -Xmn256m -XX:MetaspaceSize=64m -XX:MaxMetaspaceSize=128m"JAVA_OPT="${JAVA_OPT} -XX:-OmitStackTraceInFastThrow -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${BASE_DIR}/logs/java_heapdump.hprof"JAVA_OPT="${JAVA_OPT} -XX:-UseLargePages"fi## 这里是一大坨代码，处理其他参数和日志目录## start# 下面是实际启动 nacos 的命令，启动时用了上面的 JVM Configurationif [[ "$JAVA_OPT_EXT_FIX" == "" ]]; thennohup "$JAVA" ${JAVA_OPT} nacos.nacos >> ${BASE_DIR}/logs/start.out 2>&1 &elsenohup "$JAVA" "$JAVA_OPT_EXT_FIX" ${JAVA_OPT} nacos.nacos >> ${BASE_DIR}/logs/start.out 2>&1 &fi

准备多个nacos

将上面改好的 nacos 准备三份

application.properties

application.properties 里需要配置两个地方

如上节演示的变更持久化层本示例需要修改默认端口，按cluster.conf的值变更，本示例中上面准备的三份 nacos 依次改为 8838/8848/8858

启动和验证

使用启动指令依次启动三个 nacos 实例

./shartup.sh

而后，可以再管理端看到效果

§4.3 加入 nginx 支持

上面已经实现了 nacos 的集群部署，引入 nginx 的目的是对 nacos 集群进行代理和负载均衡，实现统一的集群访问

准备 nginx

下载解压 nginx，因环境限制略，有需要的可参考 Linux安装nginx

配置 nginx.conf

vim opt/nginx-1.22.0/conf/nginx.conf

#gzip on;# 配置上游服务器，用 nginx 进行代理和负载均衡upstream cluster{server 192.168.3.10:8838;server 192.168.3.10:8848;server 192.168.3.10:8858;}# 配置 nginx 的访问地址server {listen 8888;server_name localhost;...... 略

启动并验证

因环境限制，直接用 windows 版的

§4.4 项目应用

修改项目配置

调整对应项目的application.yml

server:port: 9001logging:config: classpath:logback.cfg.dev.xmlspring:application:name: provider-nacoscloud:nacos:discovery:server-addr: 192.168.3.7:8888 #换成 nginx 的访问地址，这里现在已经是个 nacos 集群了management:endpoints:web:exposure:include: '*'

启动验证

本文部分内容参考自

Nacos加载多个配置集

Linux安装nginx

传送门：

微服务架构 | 组件目录