微服务架构这个词这几年被聊得太多以至于很多团队一上来就奔着拆去了结果环境还没搭明白先把自己绕进了依赖地狱。QuickBlue AI 微服务应用底座这个项目我前前后后搭了三套环境从本地开发到联调测试踩的坑比写的代码还多。这篇就专门聊环境准备这一环——不是那种装个 JDK、配个 Maven 就完事的流水账而是把每个选择背后的理由、每个容易翻车的地方都摊开讲清楚。不管你是刚接触微服务的新手还是已经拆过几个服务的老手只要你要在本地把一套微服务底座跑起来、能启动、能联调这篇内容都能直接拿去用。1. 先想清楚QuickBlue AI 底座的环境准备到底在准备什么很多人对环境准备的理解停留在装软件层面觉得把 JDK、Maven、Docker 装上就完事了。但微服务底座的环境准备本质上是在准备一套能让多个服务独立启动、互相发现、协同工作的运行时契约。这个契约包括版本约定、网络拓扑、配置管理方式、服务注册与发现的机制以及数据层的隔离策略。QuickBlue AI 作为一个 AI 方向的微服务应用底座它的环境准备比普通业务微服务还要多一层——AI 能力通常以独立服务的形式存在涉及模型加载、推理资源分配、GPU 或 CPU 的算力调度这些都会反过来影响你本地环境的资源规划。1.1 底座型项目和普通业务项目的环境差异普通业务项目你 clone 下来配个数据库连接mvn spring-boot:run基本就能跑。底座型项目不一样它的定位是被其他服务依赖的基础设施所以它自身往往包含多个模块注册中心、配置中心、网关、认证授权、公共工具库、AI 能力封装层。这些模块之间是有启动顺序和依赖关系的。我第一次搭的时候习惯性地把网关先启动结果网关去注册中心注册失败因为注册中心还没起来。这种顺序问题在单体应用里根本不存在但在微服务底座里是家常便饭。所以环境准备的第一件事不是装软件而是画清楚服务依赖拓扑。QuickBlue AI 底座大致可以分成三层基础设施层注册中心、配置中心、核心能力层网关、认证、AI 推理服务、业务接入层各个业务微服务。启动顺序必须自下而上基础设施层先就绪核心能力层再启动最后才是业务层。这个顺序不是拍脑袋定的而是由服务注册与发现的机制决定的——下游服务启动时需要向上游注册中心报到如果注册中心没起来报到就失败了。1.2 本地环境与容器化环境的取舍逻辑这里有个绕不开的选择本地环境到底是全部用 Docker 跑还是部分用本地进程、部分用容器我的经验是混合模式最实用。注册中心、配置中心、数据库、消息队列这些重且稳定的组件用 Docker Compose 一把梭省心且环境一致而你自己正在开发调试的那个服务用本地 IDE 启动方便打断点、热部署、看日志。全容器化听起来很美但调试体验极差改一行代码要重新打镜像效率低到让人抓狂。全本地化也不行光是装 MySQL、Redis、Nacos 这些就能耗掉你半天还容易版本冲突。QuickBlue AI 底座我推荐的基础设施容器清单是这样的Nacos 做注册与配置中心、MySQL 存业务和配置数据、Redis 做缓存和会话、RabbitMQ 或 RocketMQ 做异步消息。这四个用 Docker Compose 编排一条命令起来。AI 推理服务如果依赖 GPU本地跑容器需要额外配置运行时这个后面单独说。1.3 版本矩阵为什么版本对齐比装软件更重要微服务环境里最隐蔽的坑是版本不兼容。Spring Cloud 和 Spring Boot 的版本是有严格对应关系的Nacos 客户端和服务端版本差太多也会出问题JDK 版本更是牵一发动全身。QuickBlue AI 底座如果基于 Spring Cloud Alibaba 体系那版本矩阵必须提前锁定。我见过太多人随便找了个教程Spring Boot 用 3.xSpring Cloud 用 2021.x结果启动直接报兼容性错误排查半天才发现是版本对不上。下面这张表是我实测下来比较稳的一套组合你可以直接参考组件推荐版本说明JDK17 LTSSpring Boot 3.x 的最低要求长期支持Spring Boot3.2.x与 Spring Cloud 2023.x 配套Spring Cloud2023.0.x对应 Spring Boot 3.2Spring Cloud Alibaba2023.0.1.x提供 Nacos、Sentinel 等集成Nacos2.3.x注册与配置中心MySQL8.0.x注意字符集用 utf8mb4Redis7.x缓存与会话Maven3.9.x构建工具提示版本矩阵一旦确定团队内所有成员必须严格对齐。建议在项目根目录放一个.tool-versions或README里明确写死版本号避免我这里能跑你那里报错的经典问题。2. 基础工具链的安装与那些容易忽略的配置细节工具链安装本身不难难的是那些默认配置在微服务场景下往往不合适。这一节我把 JDK、Maven、IDE、Docker 这几个必备工具的安装要点和配置陷阱讲透尤其是那些教程里不会提、但实际会卡住你的细节。2.1 JDK 17 的安装与环境变量陷阱JDK 17 是当前微服务项目的主流选择Spring Boot 3.x 强制要求 JDK 17 及以上。安装本身没什么好说的官网下载或者用包管理器都行。但有几个细节必须注意。第一JAVA_HOME一定要指向 JDK 根目录而不是bin目录很多人在这里配错导致 Maven 找不到编译器。第二PATH里要把%JAVA_HOME%\bin放在最前面避免系统里存在多个 JDK 时用错版本。第三如果你之前装过 JDK 8环境变量可能还残留着旧配置一定要清理干净。验证安装是否成功不要只看java -version还要看javac -version两者版本必须一致。我遇到过一次java是 17 但javac还是 8 的情况原因是 PATH 顺序问题编译时用的还是旧编译器报了一堆莫名其妙的语法错误。java -version javac -version echo $JAVA_HOME三个命令的输出要互相印证版本一致、路径正确才算真正装好。2.2 Maven 的镜像配置与本地仓库规划Maven 默认从中央仓库拉依赖国内网络环境下速度感人。配置阿里云镜像是基本操作但很多人只配了mirror没配profile导致某些特殊仓库的依赖还是走默认源。完整的settings.xml配置应该包含镜像、JDK 版本锁定、本地仓库路径三部分。本地仓库路径建议单独规划不要用默认的~/.m2/repository。原因有两个一是 C 盘空间容易被吃满微服务项目依赖动辄几个 G二是多个项目共用本地仓库时如果版本冲突清理起来很麻烦。我习惯给每个大项目组配独立的本地仓库通过-Dmaven.repo.local参数指定互不干扰。mirror idaliyunmaven/id mirrorOf*/mirrorOf name阿里云公共仓库/name urlhttps://maven.aliyun.com/repository/public/url /mirror注意mirrorOf用*会拦截所有仓库请求包括一些私服。如果团队有内部 Nexus要把私服地址排除在外否则内部依赖拉不下来。2.3 IDE 的微服务友好配置IntelliJ IDEA 是微服务开发的主流选择但默认配置对多模块项目并不友好。几个必须调整的地方第一开启自动导入 Maven 项目否则每次改 pom 都要手动刷新第二把编译器的堆内存调大微服务项目模块多默认的 512M 经常不够用建议调到 2048M第三配置好 JDK 版本在Project Structure里把项目 SDK 和语言级别都设成 17。还有一个容易被忽略的点IDEA 的运行仪表盘Services 窗口对微服务调试非常有用。它可以把多个 Spring Boot 服务集中管理一键启动、一键停止、查看端口占用。配置方式是在Run/Debug Configurations里把每个服务的启动类加进去然后在 Services 窗口里统一管理。这个功能用好了启动一套微服务就是点几下鼠标的事。2.4 Docker 与 Docker Compose 的安装要点Docker 在 Windows 上依赖 WSL2在 Mac 上用 Docker DesktopLinux 上直接装引擎。安装本身不复杂但有几个配置直接影响后续使用体验。第一镜像加速器必须配否则拉镜像慢到怀疑人生。第二Docker 的资源限制要调整默认给容器的内存可能不够跑 MySQL 和 Nacos建议至少分配 4G 内存。第三Docker Compose 的版本要跟上v2 版本的命令是docker compose中间有空格和 v1 的docker-compose不一样脚本里写错了会报命令找不到。version: 3.8 services: nacos: image: nacos/nacos-server:v2.3.0 environment: - MODEstandalone ports: - 8848:8848 - 9848:9848这是 Nacos 单机模式的最小配置注意 9848 端口也要暴露这是 Nacos 2.x 新增的 gRPC 通信端口只暴露 8848 会导致客户端连接失败。这个坑我踩过当时排查了半天才发现是端口没开。3. 基础设施容器的编排与启动顺序控制基础设施是微服务底座的地基地基不稳上面全白搭。这一节讲怎么用 Docker Compose 把 Nacos、MySQL、Redis、消息队列编排起来以及如何控制启动顺序避免服务之间互相等待导致的启动失败。3.1 Docker Compose 编排文件的结构设计一个清晰的 Compose 文件应该按功能分组用注释标明每个服务的用途。我习惯把基础设施放在一个docker-compose-infra.yml里业务服务如果需要容器化再单独编排。这样职责清晰也方便单独重启某一层。网络配置是关键。所有基础设施容器应该放在同一个自定义网络里这样容器之间可以用服务名互相访问不用记 IP。比如 MySQL 容器叫mysql那 Nacos 连接数据库时直接用jdbc:mysql://mysql:3306/...就行。这个自定义网络要在 Compose 文件顶部声明。networks: quickblue-net: driver: bridge数据持久化也不能忘。MySQL 和 Redis 的数据必须挂载到宿主机卷否则容器一删数据全没。Nacos 如果用内嵌数据库数据也在容器里生产环境必须换成 MySQL 存储。本地开发为了省事可以用内嵌但要知道这个限制。3.2 启动顺序depends_on 不够用怎么办Docker Compose 的depends_on只能保证容器启动顺序不能保证服务就绪。也就是说MySQL 容器起来了但数据库还没初始化完Nacos 就去连照样失败。这个问题在微服务环境里非常普遍。解决方案有两种。第一种是用健康检查加condition让 Compose 等到健康检查通过再启动下一个服务。第二种是在应用层做重试Nacos 客户端本身有重试机制但 MySQL 连接池不一定有。我推荐两者结合Compose 层面用健康检查控制大顺序应用层面加重试兜底。mysql: image: mysql:8.0 healthcheck: test: [CMD, mysqladmin, ping, -h, localhost] interval: 10s timeout: 5s retries: 5 nacos: depends_on: mysql: condition: service_healthy这样配置后Nacos 会等 MySQL 健康检查通过才启动避免了大半的启动失败问题。3.3 Nacos 的持久化配置与命名空间规划Nacos 默认用内嵌 Derby 数据库重启后配置还在但多节点部署时数据不共享。本地开发单机模式够用但如果你要模拟集群必须换成 MySQL 存储。换存储的步骤是先在 MySQL 里建nacos_config库执行 Nacos 自带的mysql-schema.sql然后在 Nacos 的application.properties里配好数据库连接。命名空间Namespace的规划也很重要。QuickBlue AI 底座至少要有三个命名空间dev、test、prod。本地开发用dev联调用test生产用prod。这样配置隔离清晰不会出现本地改了配置影响测试环境的情况。命名空间 ID 建议用有意义的名字不要用自动生成的 UUID否则时间长了根本记不住哪个是哪个。提示Nacos 的默认账号密码是nacos/nacos本地开发无所谓但如果测试环境暴露在局域网内一定要改密码否则任何人都能改你的配置。3.4 MySQL 初始化脚本与字符集设置MySQL 容器启动时可以挂载初始化脚本自动建库建表。这个功能很实用把init.sql挂到/docker-entrypoint-initdb.d/目录下容器首次启动就会执行。但要注意脚本只在数据目录为空时执行如果卷里已经有数据脚本不会跑。所以调试初始化脚本时要么删卷重来要么手动执行。字符集必须设成utf8mb4排序规则用utf8mb4_general_ci或utf8mb4_unicode_ci。默认的latin1存中文会乱码而且微服务里经常存 JSON 数据utf8mb4才能完整支持。建库语句要显式指定字符集不要依赖默认值。CREATE DATABASE quickblue DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;时区也要注意。容器默认可能是 UTC和本地时间差 8 小时导致日志时间对不上。启动 MySQL 时加--default-time-zone08:00参数或者在连接串里指定时区。4. 服务注册与发现的本地联调实战基础设施起来之后下一步是让各个微服务能注册上去、互相发现、正常调用。这一节讲服务注册的配置要点、联调时的常见问题以及怎么验证服务发现是否正常工作。4.1 服务注册配置bootstrap 与 application 的分工Spring Cloud 项目里bootstrap.yml和application.yml的分工经常让人困惑。简单说bootstrap加载更早用于配置中心连接、加密解密等需要在应用上下文初始化前完成的工作application加载稍晚用于业务配置。在 Nacos 作为配置中心的场景下Nacos 的连接信息要放在bootstrap.yml里否则应用启动时还没连上配置中心拉不到配置。# bootstrap.yml spring: application: name: quickblue-gateway cloud: nacos: discovery: server-addr: localhost:8848 namespace: dev config: server-addr: localhost:8848 namespace: dev file-extension: yamlspring.application.name是服务注册到 Nacos 的名字必须全局唯一。如果两个服务用了同一个名字Nacos 里会显示两个实例调用时负载均衡会出问题。命名规范建议用项目名-模块名的格式比如quickblue-gateway、quickblue-auth。4.2 服务发现的验证方法服务注册上去之后怎么确认它真的能被发现最直接的方法是打开 Nacos 控制台在服务管理-服务列表里看。能看到服务名和实例数说明注册成功。但注册成功不代表能调用成功还要验证服务间的调用链路。我常用的验证步骤是这样的先启动注册中心和配置中心再启动两个互相调用的服务比如网关和认证服务。然后在网关里配一条路由指向认证服务用curl或 Postman 发请求看能不能通。如果通说明服务发现和负载均衡都正常。如果不通看日志里有没有No instances available或Connection refused前者是服务没注册上后者是网络不通。curl http://localhost:8080/api/auth/health这条命令走网关访问认证服务的健康检查接口能返回 200 就说明链路通了。4.3 本地多实例启动的端口冲突处理微服务联调时经常需要同一个服务启动多个实例模拟负载均衡。但本地端口是有限的同一个服务启动两次端口就冲突了。解决办法是启动时用-Dserver.port参数指定不同端口或者在 IDEA 的 Run Configuration 里配多个配置每个用不同端口。java -jar quickblue-auth.jar --server.port8081 java -jar quickblue-auth.jar --server.port8082两个实例注册到 Nacos 后服务列表里会显示两个实例网关调用时会自动轮询。这个技巧在验证负载均衡和熔断降级时特别有用。注意多实例启动时如果服务里有定时任务或消息消费逻辑要加分布式锁或幂等处理否则任务会被执行多次。这个坑在联调阶段不容易发现上线后才暴露很危险。4.4 配置中心的动态刷新验证Nacos 配置中心的一大卖点是配置动态刷新改了配置不用重启服务。但这个功能需要额外配置才能生效。首先配置类要加RefreshScope注解其次Nacos 里的配置要和服务里的dataId对应上。dataId的默认规则是${spring.application.name}-${spring.profiles.active}.${file-extension}比如quickblue-gateway-dev.yaml。验证动态刷新的方法是在 Nacos 控制台改一个配置值然后在服务日志里看有没有刷新记录或者直接调接口看返回值变没变。如果没生效检查RefreshScope加没加、dataId对不对、配置格式是不是 YAML。这几个点排查完基本就能定位问题。5. AI 能力服务的资源规划与本地运行策略QuickBlue AI 底座和普通微服务底座最大的区别就是它要承载 AI 能力。AI 服务对资源的要求和普通业务服务完全不是一个量级本地环境准备时必须单独规划。5.1 AI 推理服务的资源需求评估AI 推理服务分两种情况一种是调用远程 API本地只做请求转发这种资源需求很小和普通服务没区别另一种是本地加载模型做推理这种对内存和算力要求很高。一个中等规模的模型加载到内存可能就要几个 G推理时还要额外的计算资源。本地开发机如果只有 16G 内存跑一个模型加上基础设施容器基本就满了。我的建议是本地开发阶段尽量用远程 API 或小模型做验证把大模型的推理放到专门的测试环境。如果必须本地跑要提前算好资源账基础设施容器占 4GIDE 和编译占 4G模型加载占 6G系统本身占 2G加起来 16G 刚好够但没有任何余量。这种情况要么加内存要么把模型服务单独放一台机器。5.2 GPU 环境的容器化配置如果 AI 服务需要 GPUDocker 的配置会复杂一些。首先宿主机要装好显卡驱动和 CUDA 运行时然后 Docker 要装 NVIDIA Container Toolkit最后启动容器时加--gpus all参数。这三步缺一不可任何一步没做容器里都看不到 GPU。docker run --gpus all -it quickblue-ai:latest验证 GPU 是否可用在容器里跑nvidia-smi能看到显卡信息就说明配置成功。如果报命令找不到说明 Toolkit 没装好如果报驱动版本不匹配说明宿主机驱动和 CUDA 版本对不上。提示GPU 容器的镜像体积通常很大拉取和构建都慢。建议把模型文件通过卷挂载不要打进镜像里否则镜像几个 G每次改代码重新构建都是折磨。5.3 AI 服务与业务服务的通信模式AI 服务和业务服务的通信通常有两种模式同步调用和异步消息。同步调用适合实时性要求高的场景比如用户提问立即返回答案异步消息适合耗时长的任务比如批量数据处理。QuickBlue AI 底座两种模式都要支持所以消息队列是必备组件。同步调用走 HTTP 或 gRPCgRPC 性能更好但调试麻烦HTTP 更通用。本地联调阶段建议先用 HTTP跑通之后再考虑换 gRPC。异步消息用 RabbitMQ 或 RocketMQ配置好交换机、队列、路由键业务服务发消息AI 服务消费。这里要注意消息的序列化格式JSON 通用但体积大Protobuf 高效但可读性差本地开发用 JSON 就够了。5.4 模型文件的本地管理模型文件通常很大不适合放在代码仓库里。本地管理模型文件有几个方案一是放在共享目录通过卷挂载到容器二是用对象存储服务启动时下载三是用模型管理工具比如 MLflow。本地开发推荐第一种简单直接。目录结构建议按模型名和版本号组织比如models/quickblue-nlp/v1/方便切换版本。模型加载是耗时的服务启动时加载可能要几十秒甚至几分钟。这个时间要算进启动超时配置里否则服务还没加载完就被判定为启动失败。Spring Boot 的spring.main.lazy-initialization可以延迟初始化但模型加载这种核心逻辑不建议延迟还是老老实实等它加载完。6. 环境验证与常见启动故障的排查链路环境搭完之后必须有一套验证流程确认每个组件都正常工作。这一节给出完整的验证清单以及常见故障的排查思路。6.1 分层验证清单验证要分层做从下往上一层不通不往上走。基础设施层验证 Nacos、MySQL、Redis、消息队列是否可访问服务注册层验证各服务是否注册到 Nacos配置管理层验证配置是否拉取成功业务链路层验证服务间调用是否正常。层级验证项验证方法预期结果基础设施Nacos访问控制台能登录服务列表可见基础设施MySQL客户端连接能连上库表存在基础设施Redisredis-cli ping返回 PONG服务注册各服务Nacos 服务列表实例数为预期值配置管理配置拉取服务日志无配置拉取失败日志业务链路服务调用curl 接口返回 200这张表建议打印出来每搭一次环境就过一遍能省下大量排查时间。6.2 启动失败的典型日志与对应原因微服务启动失败日志里通常有线索关键是要知道看哪里。Connection refused一般是目标服务没启动或端口不对No instances available是服务没注册上或注册了但健康检查没通过Config not found是配置中心的dataId或命名空间不对ClassNotFoundException或NoSuchMethodError基本是版本冲突。我遇到最多的是版本冲突尤其是 Spring Cloud 和 Spring Boot 版本不匹配。这种问题的日志往往很长关键信息藏在Caused by后面。排查时从最后一个Caused by往前看通常能找到根因。6.3 端口占用的快速定位端口占用是本地开发的常见问题。Windows 上用netstat -ano | findstr 端口号找进程 PID然后tasklist | findstr PID看是什么程序。Mac 和 Linux 上用lsof -i:端口号。找到之后要么杀掉进程要么换个端口。# Windows netstat -ano | findstr 8848 tasklist | findstr PID # Mac/Linux lsof -i:8848 kill -9 PID注意杀进程之前确认一下是不是重要程序别把系统服务杀了。我见过有人把 3306 端口的 MySQL 杀了还纳闷数据库怎么连不上。6.4 网络不通的排查思路容器之间网络不通先检查是不是在同一个网络里。docker network inspect 网络名能看到网络里的容器列表。如果容器不在同一个网络用docker network connect加进去。然后检查端口映射容器内部端口和宿主机端口是两回事docker ps能看到映射关系。宿主机访问容器服务用localhost:映射端口容器访问容器用服务名:容器端口。这两个规则搞混了就会连不上。我建议在 Compose 文件里给每个服务都配好端口映射本地调试时统一用宿主机端口访问省得记两套地址。7. 环境配置的版本管理与团队协作环境准备不是一个人的事团队协作时配置的版本管理直接决定了新成员的上手速度。这一节讲怎么把环境配置管好让新人一天之内就能跑起来。7.1 配置文件的版本化策略哪些配置该进代码仓库哪些不该进这个界限要划清楚。基础设施的 Compose 文件、初始化 SQL、Nacos 的配置导出文件这些应该进仓库因为它们是环境的一部分。而个人的 IDE 配置、本地路径、密钥这些不该进用.gitignore排除。Nacos 的配置建议定期导出存到仓库的config/目录下。Nacos 控制台支持导出配置为 ZIP解压后是 YAML 文件。这样配置变更也有版本记录出问题能回滚。7.2 一键启动脚本的编写把环境启动的步骤写成脚本新人 clone 下来执行一条命令就能起来这是最省事的做法。脚本要包含检查 Docker 是否运行、拉取镜像、启动 Compose、等待健康检查、输出访问地址。#!/bin/bash set -e echo 检查 Docker... docker info /dev/null 21 || { echo Docker 未运行; exit 1; } echo 启动基础设施... docker compose -f docker-compose-infra.yml up -d echo 等待服务就绪... sleep 30 echo 环境就绪Nacos 控制台: http://localhost:8848/nacos脚本里的sleep 30是简单粗暴的等待更好的做法是轮询健康检查接口直到返回成功再继续。但对于本地开发sleep够用了。7.3 新人上手的检查清单给新人一份检查清单比口头讲十遍都管用。清单内容包括装 JDK 17、装 Maven、配镜像、装 Docker、拉代码、执行启动脚本、导入 Nacos 配置、启动服务、验证接口。每完成一项打个勾卡在哪一步一目了然。这份清单我建议放在仓库的docs/目录下用 Markdown 写随时更新。新人遇到问题先对照清单自查解决不了再问能省下大量重复沟通。7.4 环境变更的同步机制环境配置改了怎么通知团队靠群里喊一声很容易漏。我的做法是环境相关的变更必须提 PR在 PR 描述里写清楚改了什么、为什么改、影响范围。合并后其他人拉最新代码重新执行启动脚本即可。这样变更可追溯也不会有人被落下。提示环境变更后记得清理旧的容器和卷否则新配置可能不生效。docker compose down -v会删除容器和卷慎用确认数据不需要保留再执行。8. 从本地到联调环境迁移的注意事项本地环境跑通只是第一步接下来要迁移到联调环境。联调环境和本地环境的差异往往是问题的高发区。8.1 地址与端口的重新映射本地环境里服务地址都是localhost端口也是固定的。到了联调环境地址变成域名或内网 IP端口可能被网关统一代理。这些变化要在配置里体现而且不能硬编码在代码里必须通过配置中心或环境变量注入。Nacos 的命名空间在联调环境要用test不能还用dev。数据库连接、Redis 地址、消息队列地址全都要换。这些配置在 Nacos 里按命名空间隔离切换环境时改一下spring.cloud.nacos.config.namespace就行。8.2 数据隔离与初始化联调环境的数据不能和本地混用必须独立。数据库要单独建Redis 的 key 前缀要区分消息队列的 topic 也要隔离。这些隔离措施在环境准备阶段就要规划好不能等出了问题再补。数据初始化脚本要能在联调环境重复执行不能有副作用。用INSERT ... ON DUPLICATE KEY UPDATE或者先判断再插入避免重复执行报错。8.3 日志与监控的接入联调环境要接入统一的日志收集和监控否则出了问题只能靠猜。日志建议用 ELK 或 Loki 收集监控用 Prometheus Grafana。这些组件在本地环境可以省略但联调环境必须有。服务启动时要把日志输出到标准输出由容器运行时收集不要写到容器内的文件里否则容器一删日志就没了。日志格式建议用 JSON方便解析和检索。8.4 环境差异的配置管理本地和联调的差异尽量用配置管理不要用代码分支。同一份代码通过不同的配置跑在不同环境这是微服务的基本原则。如果为了环境差异拉分支后期合并会非常痛苦。Nacos 的配置支持继承和覆盖可以定义一个公共配置各环境再定义差异配置。这样公共部分改一次所有环境生效差异部分各管各的维护成本最低。环境准备这件事说到底是把不确定性降到最低。每多一个没考虑到的细节后面就多一个半夜爬起来排查的故障。QuickBlue AI 底座的环境我搭了三遍每一遍都比上一遍顺不是因为技术变强了而是因为坑都踩过了。希望这篇内容能让你少走点弯路把时间花在写业务代码上而不是和环境搏斗。
建堆推导)