单体工程

本小节主要介绍橙单企业版单体工程，在开发和测试环境中的启动过程，至于生产环境，企业需要视自身的运维条件而自行决定。

中间件服务启动

打开工程目录下的 README.md 文件，查看该工程所需的第三方中间件服务列表，如 Redis 和 Minio 等。我们推荐使用 docker-compose 命令启动所有依赖的中间件服务，具体操作见如下命令行。

# 从生成后的工程根目录，切换到 docker-compose 文件所在的子目录。
cd ./zz-resource/docker-files
# 第一次启动。-d方式启动，日志不会输出到控制台。
docker-compose up -d
# 推荐使用stop命令停止已启动的服务。
docker-compose stop
# 再次启动
docker-compose start
# 彻底停止服务，容器的运行时状态将全部丢失。
docker-compose down
# 由于是-d方式启动，查看启动日志命令为
docker-compose logs

如本机没有安装 docker，可参考 中间件环境章节 中的相应小节，采用本地手动安装的方式，配置和启动第三方中间件服务。

JDK17 注意事项

使用 JDK17+ 版本时，需要为服务启动项 VM Options 添加选项 --add-opens java.base/java.lang.reflect=ALL-UNNAMED。

应用服务启动

在开发环境中配置启动项，下图为 IntelliJ IDEA 中的配置截图，配置完成后点击 Debug/Run 按钮即可启动。

生产部署注意事项

• 单体服务也需要支持最基本的高可用和负载均衡，因此通常会在不同的主机部署多份单体业务服务，再由 Nginx 负责请求转发的负载均衡。在配置多份业务服务时，一定一定要修改雪花算法的 workId 配置项，否则会导致两个业务服务计算出相同的主键 ID，后果极为严重。

# 最合适的方式是不修改配置值，而是在服务启动的命令行参数中覆盖 yaml 中的缺省值。
nohup java -jar xxx.jar --sequence.snowflakeWorkNode=1 &

• 如果相同主机启动多个业务服务实例，需要在命令行参数中指定不同的监听端口，否则会导致端口冲突，后启动的服务将无法正常启动。如果是多台主机，每台主机仅部署一个业务服务实例，就不存在该问题，有条件的情况还是推荐多主机部署，避免主机的单点故障。

# 最合适的方式是不修改配置值，而是在服务启动的命令行参数中覆盖yaml中的缺省值。
nohup java -jar xxx.jar --server.port=8888 --sequence.snowflakeWorkNode=1 &

微服务工程

本小节主要介绍橙单企业版微服务工程，在开发和测试环境中的启动过程，至于生产环境，企业需要视自身的运维条件而自行决定。

中间件服务启动

打开工程目录下的 README.md 文件，查看该工程所需的第三方中间件服务列表，如 Nacos、Kafka、Redis、Seata 和 Minio 等。这里还可以查看他们的启动顺序，以及正常启动后服务管理控制台的访问方式。在日常开发调试阶段，我们推荐使用 docker-compose.yml 文件启动所有依赖的中间件服务，具体操作见如下命令行。

# 从生成后的工程根目录，切换到 docker-compose 文件所在的子目录。
cd ./zz-resource/docker-files
# 第一次启动。-d方式启动，日志不会输出到控制台。
docker-compose up -d
# 推荐使用stop命令停止已启动的服务。
docker-compose stop
# 再次启动
docker-compose start
# 彻底停止服务，容器的运行时状态将全部丢失。
docker-compose down
# 删除Kafka、Redis、Zookeeper中，因为强行停止所致的错乱数据。
./clear-data.sh
# 由于是-d方式启动，查看启动日志命令为
docker-compose logs

启动脚本注意事项

在生成后工程的 zz-resource/docker-files 子目录中，存在两个 docker-compose 配置文件，具体差别如下。

• docker-compose.yml。在开发调试阶段，为了降低系统资源的占用率，仅需启动该 docker-compose.yml 文件即可，该文件仅启动必须依赖的中间件服务，如 Nacos、Redis、Kafka、Seata、Zookeeper 和 Minio 等。

• docker-compose-full.yml。该配置文件包含所有第三方中间件服务的启动项。相当于 docker-compose.yml + ELK + Grafana + Prometheus 等。因此该文件的启动，将会占用更多的系统资源。

# 第一次启动
docker-compose -f docker-compose-full.yml up -d
# 停止
docker-compose -f docker-compose-full.yml down

JDK17 注意事项

使用 JDK17+ 版本时，需要为服务启动项 VM Options 添加选项 --add-opens java.base/java.lang.reflect=ALL-UNNAMED。

应用服务启动

在开发环境中，为每个微服务启动项配置 main class，下图为 IntelliJ IDEA 中的配置截图，配置后点击 Debug/Run 按钮即可启动。

应用服务启动-SkyWalking

通过该方式启动的微服务，所有调用过程都会通过 SkyWalking Agent 进行实时采集，并发送到 SkyWalking 服务器。最后通过 SkyWalking 的控制台进行可视化查询，具体步骤如下。

• 启动 SkyWalking 服务。由于 docker-compose-full.yml 文件中并不包含 SkyWalking 服务器的启动项，因此需要在主机中手动安装该服务，具体安装方式可参考 中间件环境章节。
• 在 SkyWalking 的解压目录下，将 agent 目录拷贝到生成后工程的 zz-resource 目录下。
• 将 zz-resource/agent/optional-plugins 目录下的 apm-spring-cloud-gateway-2.x-plugin-$VERSION.jar，拷贝到  zz-resource/agent/plugins 目录，以保证 Spring Cloud Gateway 的数据可被正常采集。
• 在开发环境中，配置 VM options 选项，下图以 IntelliJ IDEA 为例，其中 upms 为服务名。这里需要注意的是，下图左侧红框标记的部分，是我们推荐的启动项配置方式。为同一服务不同场景，配置多个启动项。

• 修改日志采集级别。打开 zz-resource/agent/config 目录下的 agent.config 文件，修改 logging.level 的缺省值。在下图中，我们建议将缺省值 debug 改为 INFO (如果已经是 INFO，则无需修改)，以便减少向 SkyWalking 中输出太多无用的测量信息。

• 完成上述配置后，Debug/Run 带有 SkyWalking 的启动项即可。

应用服务启动-PinPoint

• 先启动 PinPoint 服务，具体操作请参考 中间件环境章节。
• 下载 pinpoint-agent-2.4.2.tar.gz。Download
• 解压下载后的文件，并拷贝到工程的 zz-resource/ 目录下。
• 打开 zz-resource/pinpoint-agent-2.4.2/pinpoint-root.config 文件，设置 pinpoint.profiler.profiles.active=release。
• 打开 zz-resource/pinpoint-agent-2.4.2/profiles/release/pinpoint.config 文件。
• 设置 profiler.log4j2.logging.transactioninfo=true，以便在 log4j2 中输出 PinPoint 的 traceId。
• 设置 profiler.sampling.counting.sampling-rate=1、profiler.sampling.percent.sampling-rate=100，将采样率设置为 100%，修改的目的是便于大家学习 PinPoint 控制台操作。
• 在开发环境中，配置 VM options 选项，下图以 IntelliJ IDEA 为例，其中 upms 为服务名。
• 完成上述配置后，Debug/Run 带有 PinPoint 的启动项即可。这里需要注意的是，下图左侧红框标记的部分，是我们推荐的启动项配置方式。为同一服务不同场景，配置多个启动项。

多租户工程

在阅读该小节之前，请先仔细阅读上面的「微服务启动」小节，因为多租户工程是建立在微服务工程基础之上的，租户系统中的相关业务服务，均为微服务模块，启动方式可参考上述微服务启动项，这里只是给出与多租户相关的租户管理服务的启动。

• 租户管理服务 tenant-admin。在开发环境中，选择该服务的启动类文件 TenantAdminApplication.java，右键选择 DEBUG/RUN 菜单即可启动，见下图。 

• 租户同步服务 tenant-sync。在开发环境中，选择该服务的启动类文件 TenantSyncApplication.java，右键选择 DEBUG/RUN 菜单即可启动，见下图。 

移除Kafka

Kakfa 的启动通常会占用一定的系统资源，然而从其功能上讲，在开发阶段对 Kafka 的依赖还是非常有限的，完全可以暂时移除。此外，在了解 Kafka 的具体功能之后，也可以根据实际需求自行判断是否永久性移除对 Kafka 的依赖。在橙单默认生成的微服务和多租户工程中，Kafka 的主要功能包含以下两点。

• 收集 logback 日志并同步到 ELK，以便开发者对日志内容进行全文检索，便于线上问题的快速定位。
• 收集用户操作审核日志，并交由 Kafka 的消费者服务 operation-log-consumer 统一批量插入到操作日志表，更多内容可参考开发文档 操作日志章节。

移除ELK同步

• 在所有微服务模块的 logback-spring.xml 中移除 Kafka Appender 的定义。

• 在工程的 pom 中移除对 kafka 的依赖。

移除操作日志批量插入

• 移除日志模块对 Kafka 的依赖。

• 在操作日志采集的 AOP 中，注释掉所有对 KafkaTemplate 的引用，具体见下面两张截图中的三处修改。

• 修改所有业务服务的 common-log 模块配置项，将 common-log.operation-log.useKafka 设置为 false。注意，一定要在 nacos 中修改该配置项才能生效。

• 在工程中移除对 operation-log-consumer 模块的包含，也无需启动该服务。

移除docker-compose配置

如果使用工程中默认生成的 docker-compose 文件启动所有依赖中间件，则需要注释掉 Kafka 的启动镜像配置。如果是自行独立部署 Kafka 服务，可忽略下图操作。

中间件环境迁移

本小节主要介绍如何修改橙单默认生成的中间件配置项，以便迁移到生产环境。

Redis

• 在 application-dev.yaml 中修改 Redisson 的相关配置。

• 在 application-dev.yaml 中修改 sa-token 的 redis 配置项。注意，在当前文件中需要修改两处。

Kafka

• 如果您在另外一台主机启动下图所示的 docker-compose.yml 文件，请务必将 Kafka 对外服务的 IP 改为当前主机的物理 IP，具体见下图。

• 在所有业务服务及操作日志消费者服务中，修改 Kafka 的地址信息，见下图及文字注释。

• 修改工程目录的 pom.xml 文件，将 kafka.log-server-addr 的变量值，改为迁移后 Kafka 的主机名和端口号，以此修改用于日志采集的 Kafka 地址信息。下图仅以 log4j2.xml 为例，logback 可自行参考。更多技术细节可以参考 开发部署章节的后台编译小节。

Nacos

• 修改工程目录的 pom.xml 文件，将注册中心和配置中心相关的变量值，改为迁移后 Nacos 的主机名和端口号，修改后即可替换每个微服务的 bootstrap.yml 中指定的地址和端口信息。更多技术细节可以参考 开发部署章节的后台编译小节。

• Nacos，作为我们的注册中心和配置中心使用。在每个业务服务中都会包含一个 bootstrap.yml 的服务启动配置文件。全部业务服务的该配置文件均需修改。

Seata

Seata 作为我们缺省的分布式事务框架使用，仅当在生成器中配置了支持 Seata 的选项时，才会生成相关的配置信息。在每个业务服务中都会包含一个 bootstrap.yml 的服务启动配置文件。全部业务服务的该配置文件均需修改。

RocketMQ

如工程中没有依赖 RocketMQ，可直接忽略。

Zookeeper

这里我们仅仅给出了 ZooKeeper 在用于分布式 ID 生成器的时候，需要修改的 ZooKeeper 地址。

Minio

如工程中没有依赖 Minio，可直接忽略。

ELK

无需修改业务任务的任何配置文件，因为 ELK 是通过 Logstash 组件从 Kafka 中搬运数据到 ElasticSearch 中的。因此仅仅修改 Logstash 的管道配置文件即可。至于 ELK 的地址，可在 docker-compose-full.yml 中修改，也可以独立主机安装。下图仅仅给出 Logstash 的管道配置文件修改示例。

结语

赠人玫瑰，手有余香，感谢您的支持和关注。选择橙单，效率乘三，收入翻番。