前言
随着技术的不断发展,后端领域慢慢摒弃传统的单体架构,转而开始流行微服务架构模式。
微服务中将服务按业务拆分的理念确实不错,但福祸相依,单体架构转换为微服务架构的过程中,不可避免的会遇到一些问题。
我们首先遇到的一个问题就是——如何去管理这些拆分出来的服务?
假设现在一个系统存在 A、B、C 三个应用,每个应用部署三份,则现在存在了 A1、A2、A3、B1、B2、B3、C1、C2、C3 共九个应用。
这些应用并非各为孤岛,而是彼此联系,需要相互调用,比如 A –> B –> C( A 应用需要调用 B,B 调用 C)。
在调用的时间轴中,不得不考虑以下问题:
- A 应当去调用谁,哪个 B?B 调用 C 同理,人为手动的去管理调用关系吗?这明显不科学
- A 调用 B 的时候,应当选择 B1、B2,还是 B3?不可能一直调用一个吧?那么应当采取什么路由策略?
- 若调用后某个应用宕机了,再次调用时必然失败,此时是否只允许调用可用的呢?
经以上分析,我们发现——微服务中迫切需要一个组件来管理大量微服务,这个组件一般被称为注册中心。
除此之外,我们还发现多应用中,冗余了大量重复的的配置属性,比如说:
- 数据库的连接信息
- 定时任务的启动信息
- 某些特定功能的开关属性
- ……
这些属性部分重复且应用一经发布若想二次修改,则必须重启应用才能生效,另外,不同环境的各种属性配置又不一样。
那么,思考这些问题:
- 类似 Java 的继承特性,重复的属性能否抽离共用?
- 配置热部署,属性是否支持修改不重启即可生效?
- 能否支持多环境,甚至异地?
经以上分析,我们发现——微服务中迫切需要一个组件来管理大量微服务的配置属性,这个组件一般被称为配置中心。
那么,市面上有没有一个框架,既可当成注册中心,又可充当配置中心,两全其美的解决上面我们遇到的问题呢?
当然是有滴啦,Nacos 就可以充当这两个角色,并且其更加强大。
简介
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 的 GitHub 页面,可直接下载其安装包。
由于 Nacos 一般部署在 Linux 上,因此下载 tar.gz
格式安装包。
目录结构
Nacos 的文件目录结构如下:1
2
3
4
5bin # 可执行文件
conf # 配置文件
data # 数据
logs # 日志
target # jar 包
单机部署
在部署 Nacos 之前,需要进行一些准备工作。
① 下载 Nacos 安装包
下载 Nacos 安装包上传到部署机器即可。
② SQL 初始化
由于 Nacos 服务依赖于 MySQL,因此需要将相应的数据库创建并执行 SQL 文件。
下载的 Nacos 安装包中的conf
文件夹下提供了nacos-mysql.sql
脚本,执行即可。
③ 配置修改
Nacos 启动时需要读取相应的数据库,为了读取到对应的数据库,需要将conf
下的application.properties
文件配置一下:1
2
3
4### Connect URL of DB:
db.url.0=jdbc:mysql://127.0.0.1:3306/nacos?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true&useUnicode=true&useSSL=false&serverTimezone=UTC
db.user.0=root
db.password.0=root
④ 启动
直接执行bin
目录下的startup.sh
脚本即可:1
2# 单机部署
sh startup.sh -m standalone
⑤ 日志
启动后logs
文件夹会输出对应的日志信息,出现以下日志代表启动成功:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
172022-01-03 16:39:08,195 INFO Adding welcome page: class path resource [static/index.html]
2022-01-03 16:39:08,421 INFO Creating filter chain: Ant [pattern='/**'], []
2022-01-03 16:39:08,452 INFO Creating filter chain: any request, [org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@21a5fd96, org.springframework.security.web.context.SecurityContextPersistenceFilter@f31c0c6, org.springframework.security.web.header.HeaderWriterFilter@263f04ca, org.springframework.security.web.csrf.CsrfFilter@54afd745, org.springframework.security.web.authentication.logout.LogoutFilter@41394595, org.springframework.security.web.savedrequest.RequestCacheAwareFilter@4a9419d7, org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@67af833b, org.springframework.security.web.authentication.AnonymousAuthenticationFilter@5769e7ae, org.springframework.security.web.session.SessionManagementFilter@5a021cb9, org.springframework.security.web.access.ExceptionTranslationFilter@fff25f1]
2022-01-03 16:39:08,513 INFO Initializing ExecutorService 'taskScheduler'
2022-01-03 16:39:08,526 INFO Exposing 2 endpoint(s) beneath base path '/actuator'
2022-01-03 16:39:08,591 INFO Tomcat started on port(s): 8848 (http) with context path '/nacos'
2022-01-03 16:39:08,593 INFO Nacos started successfully in stand alone mode. use embedded storage
2022-01-03 16:39:38,898 INFO Initializing Servlet 'dispatcherServlet'
2022-01-03 16:39:38,904 INFO Completed initialization in 6 ms
⑥ Web 控制台
Nacos 提供了友好的 UI 界面,启动成功后访问以下网址即可访问(用户名/密码均为nacos
):
集群部署
Nacos 集群的搭建的基本步骤如下
- ① 下载 Nacos 安装包
- ② SQL 初始化
- ③ 配置修改
- ④ 启动
- ⑤ 查看日志
集群模式部署前两步操作步骤与单机部署时一致,变动在于三点:
- 部署机器分布三个
- 配置文件有点变化
- 启动脚本有点变化
① 下载 Nacos 安装包
现在机器规划为三台,IP 分别为:
- 192.168.0.23
- 192.168.0.24
- 192.168.0.25
下载 Nacos 安装包分别上传到三个机器即可。
② SQL 初始化
略。
③ 配置修改
修改application.properties
文件:1
2
3
4
5
6### Count of DB: 注意下面的配置需要开放
db.num=1
### Connect URL of DB:
db.url.0=jdbc:mysql://127.0.0.1:3306/nacos?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true&useUnicode=true&useSSL=false&serverTimezone=UTC
db.user.0=root
db.password.0=root
复制cluster.conf.example
文件为cluster.conf
并修改:1
2
3
4# 配置多个集群地址
192.168.0.23:8848
192.168.0.24:8848
192.168.0.25:8848
④ 启动
现在不以单机模式启动,分别在三台机器的 Nacos 直接执行startup.sh
脚本即可。
当然,集群模式下 Nacos 的脚步内存给的可能还是有点大,可以适当调整下:
1 | #=========================================================================================== |
⑤ 查看日志
1 | ,--. |
⑥ Web 控制台
现在,以下三个地址均可访问 Nacos Web 控制台:
- http://192.168.0.24:8848/nacos/#/login
- http://192.168.0.25:8848/nacos/#/login
- http://192.168.0.26:8848/nacos/#/login
集成前提
Nacos 既可作为服务治理中心组件,也可作为配置中心组件,因此按不同的定位,集成的步骤存在细微差异。
若项目架构使用的为 Spring Cloud,想在其中使用 Nacos(不论是充当哪个组件),必须在微服务的 Maven 父模块pom
文件中引入下面的依赖:1
2
3
4
5
6
7<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-alibaba-dependencies</artifactId>
<version>2.2.6.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
服务治理
Nacos 的一个角色定位就是其可用充当微服务的服务治理组件。
快速入门
若想使用 Nacos 作为微服务应用的服务治理中心,集成需经以下步骤:
① 修改
pom.xml
文件,引入 Nacos Discovery Starter。1
2
3
4
5<!-- Nacos 服务治理 -->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>② 在应用的
/src/main/resources/application.yaml
配置文件中配置 Nacos Server 地址1
2
3
4
5
6
7spring:
application:
name: service-name # 应用名必须配置
cloud:
nacos:
discovery:
server-addr: 127.0.0.1:8848③ 在启动类使用
@EnableDiscoveryClient
注解,开启服务注册与发现功能1
2
3
4
5
6
7
8
9
public class ProviderApplication {
public static void main(String[] args) {
SpringApplication.run(ProviderApplication.class, args);
}
}
注意哦
:若使用了其他服务治理框架,不要忘了注释掉相应的依赖,否则会有冲突,如 Eureka.
概念
存储模型
对 Nacos 而言,一个服务可以有多个实例,比如用户服务,可以部署到不同服务器上::
- 42.20.11.1:8080
- 62.40.80.1:8080
- 45.10.33.1:8080
实例类型
Nacos 的服务实例分为两种类型:
- 临时实例:若实例宕机超过一定时间,会从服务列表剔除,默认类型
- 永久实例:若实例宕机,不会从服务列表剔除,也称为非临时实例
若想将一个服务实例为永久实例:
1 | spring: |
集群
假如这些实例分布于全国各地的不同机房,例如:
- 42.20.11.1:8080,在上海机房
- 62.40.80.1:8080,在上海机房
- 45.10.33.1:8080,在杭州机房
Nacos 可将同一机房内的实例划分为一个集群。
总而言之,在 Nacos 中,每种服务可以加入多个集群,每个集群下可以有多个实例,形成分级模型。
集群特性
由于同集群实例的网络延迟较低,本地访问速度更快,服务互相访问时,会尽可能访问本地集群,,只有当本集群内不可用时,才访问其它集群。
集群使用
若想对 Nacos 应用配置集群,需要使用nacos.discovery.cluster-name
属性。
下面是application.yaml
文件的一个示例:1
2
3
4
5
6
7
8spring:
application:
name: service-name # 应用名必须配置
cloud:
nacos:
discovery:
server-addr: 127.0.0.1:8848
cluster-name: SZ # 深圳机房
负载均衡
同集群优先
对默认情况下的负载均衡策略,并不能实现同集群优先访问
因此Nacos中提供了一个NacosRule
的实现,可以优先从同集群中挑选实例。
集群优先策略使用
① 若想集群优先策略,首先必须在配置中使用了集群配置:
1 | spring: |
② 修改application.yaml
文件的负载均衡策略:1
2ribbon:
NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule
权重
服务器性能差异
应用实际部署中会遇到这样的场景——服务器设备性能存在差异:部分实例所在机器性能较好,而另一些较差。
我们当然希望性能好的机器承担更多的用户请求,但是,默认情况下 NacosRule 是同集群内随机挑选,不会考虑机器的性能问题。
不过,Nacos 也提供了基于权重的配置,来控制访问频率,权重越大则访问频率越高。
权重修改
在 Nacos 控制台,在服务管理——服务列表——找到对应的的实例列表,选择一个服务点击详情,之后点击编辑,即可修改权重。
灰度发布
若将实例权重配置为 0,则该实例永远不会被访问,我们可以在灰度发布时慢慢地减少旧版应用的权重,最后平滑上线新版应用。
元数据
Nacos 通过数据(如配置和服务)描述信息,如服务版本、权重、容灾策略、负载均衡策略、鉴权配置、各种自定义标签,从作用范围来看,分为服务级别的元数据、集群的元数据及实例的元数据。
通常而言,业务应用可能需要进行灰度发布,灰度发布需要针对新上线的应用打一个标记,那么这个标记应当放在哪里呢?
放到对应 Nacos 实例的元数据中即可。
在 Nacos 控制台,在服务管理——服务列表——找到对应的的实例列表,选择一个服务点击详情,之后点击编辑,即可修改实例的元数据。
多环境隔离
Nacos 提供了命名空间(Namespace)来实现环境隔离功能。
- Nacos 中可以有多个 Namespace
- Namespace 下又可以有 Group、Service、Data
- 不同 Namespace 之间相互隔离,例如不同 Namespace 的服务互相不可见
命名空间
默认情况下,所有 Group、Service、Data 都在同一个名为 public 的 Namespace 下。
创建
我们可以点击页面新增命名空间按钮,添加一个 Namespace:
填写弹出的表单,就能在页面看到一个新的 Namespace:
之后在配置管理——配置列表和服务管理——服务列表中均可看到相关命名空间导航栏:
使用
若想给微服务配置 Namespace,只能通过修改配置来实现。
例如,修改用户服务的application.yaml
文件:
1 | spring: |
注意事项
若不同命名空间的应用想要访问,由于 Namespace 不同,会找不到对应服务,这样便达到了环境隔离的作用。
配置集
一组相关或者不相关的配置项的集合称为配置集。在系统中,一个配置文件通常就是一个配置集,包含了系统各个方面的配置。例如,一个配置集可能包含了数据源、线程池、日志级别等配置项。
Data ID
Data ID 通常用于组织划分系统的配置集。
一个系统或者应用可以包含多个配置集,每个配置集都可以被一个有意义的名称标识。
Data ID 通常采用类 Java 包(如 com.taobao.tc.refund.log.level)的命名规则保证全局唯一性。此命名规则非强制。
使用时一般根据应用名配置。
Group
Nacos 通过一个有意义的字符串(如 Buy 或 Trade )对配置集进行分组,从而区分 Data ID 相同的配置集。
若在 Nacos 上创建一个配置时未填写配置分组的名称,则其名称默认采用 DEFAULT_GROUP 。
配置分组的常见场景:不同的应用或组件使用了相同的配置类型,如 database_url 配置和 MQ_topic 配置。
Nacos VS Eureka
Nacos 和 Eureka 均为服务治理框架,都提供服务注册、服务拉取、心跳等待功能,但它们也存在一些差异。
相同点
- 都支持服务注册和服务拉取
- 都支持服务提供者心跳方式做健康检测
不同点
- Nacos 支持服务端主动检测提供者状态:
- 临时实例采用心跳模式:心跳不正常会被剔除
- 永久实例采用主动检测模式:心跳不正常则不会被剔除
- Nacos 支持服务列表变更的主动消息推送模式,服务列表更新更及时
- Nacos 集群默认采用 AP 方式,当集群中存在非临时实例时,采用 CP 模式
- Eureka采用AP方式
配置中心
Nacos 的另外一个角色定位就是其可用充当微服务的配置中心组件。
快速入门
若想使用 Nacos 作为微服务应用的配置中心,简单而言需要在两个地方配置:
- ① 在 Nacos 服务端建立属性文件,进行相应配置
- ② Spring Boot 应用引入 Nacos 配置中心组件,进行相应配置
Nacos 服务端的配置
若要在 Nacos 新增配置文件,需要进行以下步骤:
- ① 选择配置管理中的配置列表,点击最右边的
+
号 - ② 在弹出的表单中,填写配置信息
- Data ID:由
[服务名称]-[profile].[文件后缀]
三部分组成,如userservice-dev.yaml
- Group:分组,默认即可
- 配置格式:选择 yaml
- 配置内容:添加需要由 Nacos 管理的配置
- Data ID:由
Spring Boot 应用中的配置
Spring Boot 集成 Nacos 的配置中心组件时,需经以下步骤:
① 修改
pom.xml
文件,引入 Nacos Config Starter:1
2
3
4
5<!-- Nacos 配置管理 -->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>② 在应用的
/src/main/resources/
目录下新建bootstrap.yml
配置文件,进行如下配置:1
2
3
4
5
6
7
8
9spring:
application:
name: service-name # 应用名必须配置
cloud:
nacos:
discovery:
server-addr: 127.0.0.1:8848 # Nacos 地址必须配置
config:
file-extension: yaml # 文件后缀名必须配置③ 完成上述两步后,若想让应用会从 Nacos 中获取相应的配置并实现热更新,存在两个实现方案:
- 组合使用
@Value
和@RefreshScope
注解 - 直接使用
@ConfigurationProperties
注解功能配置
- 组合使用
以上过程简而言之:
- 首先根据
spring.cloud.nacos.server-addr
获取 Nacos 地址 - 其次拼接以下属性作为文件 id,来读取 Nacos 配置
${spring.application.name}
${spring.profiles.active}
${spring.cloud.nacos.config.file-extension}
Nacos 配置原理
若将 SpringBoot 项目的启动过程简单概括,大概需要经历以下过程:
- ① 读取本地
application.yml
相关配置文件 - ② 创建 Spring 容器
- ③ 根据配置的属性进行 Bean 的实例化
现在配置文件由 Nacos 管理,配置属性在 Nacos 中,那么进行 Bean 实例化时,其相应属性什么时候读取呢?
这个问题真令人脑壳痛。
幸运地是,Spring 引入了一种新的配置文件:bootstrap.yaml
文件,会在application.yml
之前被读取,远端 Nacos 的配置和本地的配置将进行合并,之后在进行相应步骤。
多环境
我们都知道 Spring Boot 的本地环境中是可以配置多环境的,Nacos 配置中心组件当然也集成了此功能。
多环境共享
对 SpringBoot 应用而言,本地的application.yml
会被其他环境共享配置。
而对 Nacos 来说,其[spring.application.name].yaml
文件也会被多个环境共享。
举个例子,若 Nacos 中存在以下配置文件:
[spring.application.name].yaml
,例如userservice.yaml
[spring.application.name]-[spring.profiles.active].yaml
,例如:userservice-dev.yaml
、userservice-test.yaml
userservice.yaml
文件中的属性将被userservice-dev.yaml
、userservice-test.yaml
共享。
多环境优先级
当 Nacos 和本地服务出现相同环境配置时,该采用本地配置还是 Nacos 中的配置呢?
这自然存在优先级高低之分:
- 若存在 Nacos 配置,则以 Nacos 配置为准,假设现配置了多个文件:
- 项目中配置了
application.yml
、application-dev.yml
两个文件 - Nacos 中配置了
userservice.yaml
、userservice-dev.yaml
两个文件 - 则已 Nacos 的两者为准
- 项目中配置了
- 若 Nacos 中配置了某服务的多个配置文件,
dataid
分别为userservice
、userservice.yaml
、userservice-dev.yaml
,则重复配置不断被依次读取的文件覆盖:- 首先拉取
userservice
文件 - 其次拉取
userservice.yaml
文件 - 最后拉取
userservice-dev.yaml
文件
- 首先拉取
换而言之,无论本地配置如何配置,若 Nacos 再次配置了,均优先采用 Nacos 中的配置,Nacos 多环境配置了重复属性,优先采用环境的配置。
注意哦
:配置文件后缀默认为properties
,可以配置为yaml
公共配置
微服务项目中,各个项目的数据库信息可能公用,在将服务集成到 Nacos 时,我们当然可以将数据库信息配置在不同服务的配置文件中,但 Nacos 也提供了另一个功能——公共配置。
公共配置即代表在 Nacos 中我们可以将各个项目中的相同的配置属性抽离到一份配置文件中,然后让其他服务文件继承即可。
要想开启此功能,需要使用 Nacos 的extension-configs
或shared-configs
属性,我们在项目的bootstrap.yaml
文件进行以下配置:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16spring:
profiles:
active: test
application:
name: user
cloud:
nacos:
config:
file-extension: yaml
shared-configs[0]:
# 继承公共配置配置
data-id: common.yaml
# 配置 Data Id 所在分组,缺省默认 DEFAULT_GROUP
group: DEFAULT_GROUP
# 配置 Data Id 在配置变更时,是否动态刷新,缺省默认 false
refresh: true
extension-configs 和 shared-configs 的区别
extension-configs
和shared-configs
有什么区别?
它们都可以抽离公共配置,只不过:
extension-configs
:代表本应用独享shared-configs
:代表可被多个应用共享
优先级
前面我们配置的shared-configs
是一个数组,这代表我们可以配置多份公共配置文件,那么此时多个配置的优先级是怎样的呢?
若配置了shared-configs
文件,比如:
shared-configs[0]
:common1.yaml
shared-configs[1]
:common2.yaml
shared-configs[2]
:common2.yaml
那么,数组下标越大,则文件优先级越高,即以common2.yaml
文件为准,extension-configs
文件同理。
若shared-configs
文件或extension-configs
的属性和 Nacos 的应用配置文件重复了,这些文件的配置优先级又是怎样的呢?
举个例子,现在配置了:
shared-configs
:shared_common.yaml
extension-configs
:extension_common.yaml
user-test.yaml
:应用配置文件
则优先级为应用配置文件最大,extension_common.yaml
次之,shared-configs
最小。
动态刷新
公共配置文件在配置变更时,默认是不支持动态刷新功能的,要想开启,需要配置以下属性(前面我们已经配置过):1
refresh: true
最佳实践
版本一致
在使用 Nacos 时,注意 SpringBoot 和 SpringCloud 对应版本保持一致,不然有时候会出现其他错误,详见
SpringBoot 与 Spring Cloud 版本对比
权限设置
默认情况下,Nacos 未开启权限校验,此情况下可绕过 Nacos 鉴权添加新用户,这将造成安全问题,因此在 Nacos 配置文件中,注意开启权限校验:1
2
3
4
5
6
7### 开启鉴权控制
nacos.core.auth.enabled=true
nacos.core.auth.caching.enabled=true
nacos.core.auth.enable.userAgentAuthWhite=false
### 鉴权使用的键值对,自定义修改即可
nacos.core.auth.server.identity.key=SecretKey01234121s2901234567890123456789012345678901234567890123456789
nacos.core.auth.server.identity.value=SecxretKey012345o67890121231sx
开启此配置中,Spring Boot 的bootstrap.yaml
文件注意新增 Nacos 帐号配置,否则应用无权访问:1
2
3
4
5
6spring:
cloud:
nacos:
# 鉴权
username: nacos
password: nacos
详见 https://github.com/alibaba/nacos/issues/4593
内存调优
Nacos 所用内存参数由启动命令startup.sh
中进行配置:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15#===========================================================================================
# JVM Configuration
#===========================================================================================
if [[ "${MODE}" == "standalone" ]]; then
JAVA_OPT="${JAVA_OPT} -Xms512m -Xmx512m -Xmn256m"
JAVA_OPT="${JAVA_OPT} -Dnacos.standalone=true"
else
if [[ "${EMBEDDED_STORAGE}" == "embedded" ]]; then
JAVA_OPT="${JAVA_OPT} -DembeddedStorage=true"
fi
JAVA_OPT="${JAVA_OPT} -server -Xms2g -Xmx2g -Xmn1g -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=320m"
JAVA_OPT="${JAVA_OPT} -XX:-OmitStackTraceInFastThrow -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${BASE_DIR}/logs/java_heapdump.hprof"
JAVA_OPT="${JAVA_OPT} -XX:-UseLargePages"
fi
若 Nacos 以standalone
模式启动,默认内存参数为-Xms512m -Xmx512m -Xmn256m
,若集群模式启动,则内存直接分配 2 个 G,一般情况下根本用不到这么多,可适当调小点。
具体设置多大,需要进行压测观察。
Dubbo 集成
版本 Bug
2.7.8 及以下版本 Dubbo 集成 Nacos 时,Nacos 将新增巨多 Dubbo 相关配置文件,并且有非常多 Nacos 线程,这是 Dubbo 组件的 Bug,建议将 Dubbo 版本升级到 2.7.9 及以上。
详细说明:
配置文件
Dubbo 集成 Nacos 时,Nacos 配置列表中出现很多以接口名为 dataid 的 Dubbo 的配置文件,这个可以通过以下配置关闭,但不知影响如何1
2
3
4
5
6dubbo:
registry:
address: nacos://127.0.0.1:8848?username=nacos&password=nacos
# 增加以下配置
use-as-metadata-center: false
use-as-config-center: false
详见 https://github.com/apache/dubbo/issues/7598
建议不要配置,因为这些都分配到 Nacos 配置中心的 Dubbo 分组中了,我们可以按条件筛选。
参考
文章信息
时间 | 说明 |
---|---|
2022-01-03 | 初版 |
2022-05-09 | 增加集群部署一节 |