下载的地址: https://github.com/alibaba/nacos/releases/tag/2.2.3
部署需要修改什么
打jar包的时候，先进行的是bootscrap 然后是application，所以说在bootscrap有的可以不在application
1.先创建多个配置文件
2.修改数据库的密码
application 配置那个文件生效
spring: cloud: nacos: discovery: server-addr: 110.41.51.65:10020 namespace: 8a61ef37-2daa-402f-8b1d-5363629c5c87 # 服务注册的命名空间，建议和配置中心保持一致这个文件可以直接删除，因为我们已经有了bootscrap.yml
application-dev
不用修改
application-prod
3.在dependence同级写一个profiles 是你的要使用的本地的这个
<profiles> <profile> <id>dev</id> <properties> <profile.name>dev</profile.name> </properties> </profile> <profile> <id>prod</id> <properties> <profile.name>prod</profile.name> </properties> </profile> </profiles>4.在bootscrap.yml 中修改一下 <profile.name>prod</profile.name>的
@profile.name@jar包用这个命令
nohup java -jar product-service-1.0-SNAPSHOT.jar > logs/product-9090.log &1.nohup
意思：不挂断，关了终端也继续跑你关掉 Xshell、关掉电脑，服务不会停。
2.java -jar xxx.jar
意思：启动 SpringBoot 服务就是运行你的商品服务product-service。
3.> logs/product-9090.log
意思：把日志输出到这个文件里不在屏幕上乱跳，全部存进文件。
4.&
意思：后台运行你还能继续输别的命令，不卡住终端。
别的类引用处理办法
在别的类里直接引用别的参数就是特殊的jar包
1. 两种 JAR 包的核心区别
| 类型 | 生成方式 | 能否被依赖 | 用途 |
|---|---|---|---|
| 可执行 JAR(Fat Jar) | Spring Boot 默认打包 (package) | ❌不可 | 直接运行 (java -jar)，包含所有依赖 |
| 普通 JAR(普通模块打包) | 标准 Maven 打包 | ✅可 | 作为公共模块，被其他服务引入 |
核心痛点：Spring Boot 默认打包的可执行 JAR，内部结构被加密 / 压缩了，其他项目无法引用它里面的类或工具。如果不想报错，必须把公共的代码 / 工具单独抽成一个普通模块。
2. 为什么要做这种配置？（红框配置的作用）
你需要在公共模块的pom.xml里加上这段配置，目的是：打一次包，同时生成两种 JAR：
- 正常的普通 JAR：可被其他服务依赖引用
- 可执行 JAR：自己可以独立运行
配置代码（红框里的核心）：
<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <classifier>exec</classifier> <!-- 关键：生成可执行 JAR 的分类器 --> </configuration> </plugin> </plugins> </build>效果：打包后，你会看到两个文件：
xxx.jar👉普通 JAR（干净，可被依赖）xxx-exec.jar👉可执行 JAR（带所有依赖，可运行）
3. 最佳实践：单独抽离成公共模块
千万不要把公共代码放在父工程里！正确的架构是：
spring-cloud-demo ├── common-util (公共模块：放工具类、实体类、通用配置) │ └── pom.xml (配置上述插件，只打普通 JAR) ├── order-service (业务模块：依赖 common-util) │ └── pom.xml └── product-service (业务模块：依赖 common-util) └── pom.xml这样做的好处：
- 代码复用：所有服务都能用 common-util 里的代码
- 版本统一：升级一次，所有服务同步
- 避免冲突：解决了 Spring Boot 可执行 JAR 无法被依赖的经典问题
4. 总结
- 可执行 JAR= 服务的 “成品”，专门用来运行
- 普通 JAR= 服务的 “工具箱”，专门用来给别人引用
- 正确做法= 把通用的东西抽成一个独立的普通模块，然后各个服务去引用它
方案1：修改 product-service 的 POM（推荐）
在product-service/pom.xml中修改 Spring Boot Maven 插件配置：
<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <!-- 删除或注释掉 classifier 配置 --> <!-- <classifier>exec</classifier> --> <!-- 或者明确指定不生成 classifier --> <classifier></classifier> </configuration> </plugin> </plugins> </build><configuration> <!-- <classifier>exec</classifier> --> </configuration>方案2：修改 order-service 的依赖
在order-service/pom.xml中修改依赖，指定 classifier：
<dependency> <groupId>com.ytvc</groupId> <artifactId>product-service</artifactId> <version>1.0-SNAPSHOT</version> <classifier>exec</classifier> <!-- 添加这个 --> </dependency>配置文件的静态信息要放过
<resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> <includes> <include>**/**</include> </includes> </resource> </resources>Nacos与Eureka的区别 共同点: - 都支持服务注册和服务拉取 区别: 1. 功能 Nacos除了服务发现和注册之外,还提供了配置中心,流量管理和DNS服务等功能. 2. CAP理论 Eureka遵循AP原则, Nacos可以切换AP和CP模式,默认AP. Nacos 根据配置识别CP或者AP模式. 如果注册Nacos的Client的节点是临时节点, 那么Nacos对这个Client节点的效果就是AP, 反之是CP. AP和CP可以同时混合存在. 3. 服务发现 Eureka: 基于拉模式. Eureka Client会定期从Server拉取服务信息, 有缓存, 默认每30秒拉取一次. Nacos: 基于推送模式. 服务列表有变化时实时推送给订阅者, 服务端和客户端保持心跳连接. 服务启动:Nacos与Eureka的区别
共同点:
- 都支持服务注册和服务拉取
区别:
1. 功能
Nacos除了服务发现和注册之外,还提供了配置中心,流量管理和DNS服务等功能.
2. CAP理论
Eureka遵循AP原则, Nacos可以切换AP和CP模式,默认AP.
Nacos 根据配置识别CP或者AP模式. 如果注册Nacos的Client的节点是临时节点, 那么Nacos对这个Client节点的效果就是AP, 反之是CP. AP和CP可以同时混合存在.
3. 服务发现
Eureka: 基于拉模式. Eureka Client会定期从Server拉取服务信息, 有缓存, 默认每30秒拉取一次.
Nacos: 基于推送模式. 服务列表有变化时实时推送给订阅者, 服务端和客户端保持心跳连接.
