微服务开发有个最容易被低估的环节SpringCloud脚手架怎么落地第一关不是业务代码而是开发环境能不能整整齐齐拉起来。我说个常见场景新成员拿到项目后先花半天装Nacos、装MySQL、装Redis装到一半发现本机某个端口被旧服务占了或者MySQL版本跟团队不一致最后的结局经常是“在我机器上明明是好的”。这种问题其实可以通过Docker栈整体解决——用一个docker-compose把微服务基础设施全部编排起来一条命令启动项目代码单独在IDE里跑两边通过localhost互联。这篇就是围绕这个思路带你把这套环境彻底搭明白。这篇内容适合谁看准备做SpringCloud脚手架的个人开发者或者小团队里负责搭建基础环境的人。核心目标是把基础设施建设做到“可复制、可重置、不污染本机”同时把SpringCloud多模块工程的依赖关系理顺。全文会用一套可以直接抄走的实践方案来讲包括组件选型、docker-compose配置、Spring Boot版本对应以及我搭环境时踩过的各种坑。1. 为什么微服务开发环境要交给 Docker1.1 手动安装环境的典型困境第一次搭微服务脚手架的时候我犯过一个特别蠢的错误为了迁就某个老项目的MySQL版本先在机器上装了个MySQL 5.7后来又给新项目装MySQL 8.0。两个服务为了抢3306端口折腾了半天最后把系统搞得很混乱。后来再做另一个产品发现不只是数据库Redis、RabbitMQ、Nacos这些基础组件全都面临同样的问题。更重要的是团队协作层面的麻烦。每个人的操作系统不一样有的用Win有的用macOS还有的用Linux发行版安装步骤完全不同。就算系统一致安装在默认路径下的配置差异也会导致各种幺蛾子。比如Nacos的启动脚本在某种内存配置下频繁宕机比如RabbitMQ缺了管理插件比如MySQL的字符集没配对导致中文乱码。这些跟业务代码毫无关系的问题却会消耗掉前期搭建脚手架的大量时间。Docker的介入把这一整块问题从“系统环境”变成了“文本文件”。所有基础设施运行在容器里数据通过卷持久化容器坏了直接重建与本机系统完全隔离。脚手架的价值是让新成员能快速上手如果一个项目连环境都不能一小时内跑起来那后面无论代码写得多优雅团队成员的第一体验都不会好。1.2 手动安装与Docker编排的对比我经常会看一些团队做基础设施选型一种是本机直接安装服务另一种是Docker Compose统一编排。两者的差距在实际使用中非常明显对比项本机手动安装Docker Compose编排安装成本每个组件单独下载、配置不同系统步骤不同一个compose文件一键拉起版本一致性全靠自觉容易版本漂移镜像版本固定所有人完全一致环境隔离服务直接暴露在本机相互冲突容器隔离端口和数据卷独立规划重置成本卸载残留非常多清理困难删除容器和卷即可干净利落资源占用开机自启的服务多长期占内存可以随时up和down不占常驻资源团队协作新成员靠文档摸索克隆项目后执行一条命令即可在这组对比里最核心的价值是“可复制性”。基础设施从“需要手工一件一件搭”变成“一份声明式文件”这跟代码本身是同一套思维用文件描述最终状态工具负责收敛差异。1.3 SpringCloud脚手架需要的基础设施池一个典型的微服务脚手架需要的绝不只是MySQL和Redis。根据业务形态的不同基础设施池会有所差异但按我个人的经验起步阶段至少要把下面这五类组件纳入开发环境注册与配置中心Nacos承担服务发现、服务配置、命名空间管理是微服务架构的中枢。关系型数据库MySQL 8.0业务数据的主存储在一开始就按utf8mb4统一字符集规划。缓存Redis承担会话、热点数据、分布式锁等场景。消息队列RabbitMQ用于异步通知、削峰填谷、最终一致性等开发阶段必须有环境验证。对象存储MinIO用来模拟文件、图片等静态资源的存储服务避免开发时直接依赖云对象存储。有条件的团队可能还会加Elasticsearch、SkyWalking、Kafka等但第一轮脚手架不需要太贪多。组件每多一个本地内存就多耗一部分排查链路的负担也会变大。先把这五类跑稳定后面需要的组件再用同样的编排思路往compose里加成本很低。2. 先把Docker和Compose踩实安装、加速与网络规划2.1 Docker安装后的镜像加速配置Docker的安装本身不复杂桌面版装好之后可以直接使用。但有一个细节必须在一开始就处理好镜像下载。不同网络环境下Docker Hub的访问体验差别很大经常出现pull镜像卡很久或者超时的情况。这不是玄学而是镜像仓库网络链路的问题需要在Docker配置里加上registry mirror。具体做法是修改Docker的配置文件在Linux环境通常是/etc/docker/daemon.json在桌面版则是通过图形界面的“Docker Engine”配置项修改。格式如下{ registry-mirrors: [ https://docker.mirrors.example.com ] }这里要提醒一句mirrors地址不是随便填的需要根据自己的网络环境选择合适的可用镜像地址。配置完之后执行docker info如果看到Registry Mirrors一栏有内容说明配置生效。这一步最好在做任何编排之前完成否则后面拉Nacos镜像时可能白白等很久。2.2 端口冲突检查与资源规划容器虽然都处于网络隔离中但它要把服务端口映射到宿主机所以依然会遇到端口占用问题。启动整个环境之前我建议先查一下这几个关键端口3306、6379、8848、9848、15672、5672、9000、9001。尤其3306和6379这两种服务在很多机器上可能已经被装过。可以用这样的命令检查lsof -i :3306 netstat -ano | grep 3306如果发现端口被占用有两个选择先停掉占用进程或者修改compose里宿主机侧的映射端口。比如把3306改成33061映射到容器内的3306应用配置同步调整。开发环境尽量保持与生产一致的端口语义所以最好清理掉旧的占用而不是反复改映射。另外内存规划也不能忽略。Nacos默认配置会预留较大的堆内存MySQL、Redis再叠加进去整套环境跑起来大约占2G到3G内存。如果你的开发机内存只有8G还要跑IDEA和本地编译可能会比较吃力。建议在Docker设置里调整资源限制把内存上限从默认的2G调高到4G并留意不要同时启动太多无关容器。2.3 网络与数据的统一规划Compose文件里我会固定使用一个自定义网络让所有容器都加入同一个bridge网络。这么做的好处是容器之间可以用服务名直接互相访问。虽然本地开发时Spring Boot跑在宿主机上并不需要容器间的通信但后续如果需要把部分微服务也容器化跑起来提前把网络规划好能省很多事。数据持久化方面三层结构要分开说容器是无状态的运行依赖镜像数据是有状态的通过卷持久化配置文件也可以作为卷挂载进去。我比较推荐用命名卷named volume而不是宿主机目录的直接挂载。命名卷的好处是数据位置由Docker统一管理删除容器时卷默认不会被删重置环境更安全。网络和卷的声明放在compose文件的底部这在后面的配置里可以直接看到。3. 基础设施编排Docker Compose 一键拉起3.1 完整Compose文件这里直接给出一份经过实际验证的docker-compose配置基于Docker Compose v2语法不需要写version字段。所有镜像版本我特意固定住了避免以后拉取时因为镜像tag变化导致行为不一致services: mysql: image: mysql:8.0.32 container_name: sc-mysql restart: unless-stopped ports: - 3306:3306 environment: MYSQL_ROOT_PASSWORD: root123 TZ: Asia/Shanghai command: - --character-set-serverutf8mb4 - --collation-serverutf8mb4_unicode_ci volumes: - mysql-data:/var/lib/mysql - ./init-sql:/docker-entrypoint-initdb.d:ro networks: - sc-net healthcheck: test: [CMD, mysqladmin, ping, -h, localhost, -proot123] interval: 10s timeout: 5s retries: 10 redis: image: redis:7.0.11 container_name: sc-redis restart: unless-stopped ports: - 6379:6379 command: [redis-server, --appendonly, yes] volumes: - redis-data:/data networks: - sc-net nacos: image: nacos/nacos-server:v2.2.3 container_name: sc-nacos restart: unless-stopped environment: MODE: standalone NACOS_AUTH_ENABLE: false ports: - 8848:8848 - 9848:9848 networks: - sc-net rabbitmq: image: rabbitmq:3.11-management container_name: sc-rabbitmq restart: unless-stopped ports: - 5672:5672 - 15672:15672 environment: RABBITMQ_DEFAULT_USER: mquser RABBITMQ_DEFAULT_PASS: mqpass networks: - sc-net minio: image: minio/minio:RELEASE.2023-04-07T18-55-22Z container_name: sc-minio restart: unless-stopped command: server /data --console-address :9001 ports: - 9000:9000 - 9001:9001 environment: MINIO_ROOT_USER: minioadmin MINIO_ROOT_PASSWORD: minioadmin volumes: - minio-data:/data networks: - sc-net networks: sc-net: driver: bridge volumes: mysql-data: redis-data: minio-data:把这份配置保存为docker-compose.yml然后放在微服务项目根目录下。我通常会把它放成一个独立目录/deploy/env与代码工程分开管理这样后续不管是新增中间件还是调整端口都在一个明确的位置操作。3.2 Nacos需要记住的两个端口Nacos的配置里最容易踩坑的是端口。8848是主HTTP端口而9848则是Nacos 2.x版本的gRPC通信端口服务注册时客户端和客户端之间有一部分通信走gRPC。如果只映射8848从Spring Cloud Alibaba启动服务时日志里通常会报连接失败类似“failed to req API”或端口不可用。在这一版compose里MODE设置成了standalone。这个是Nacos单机模式不需要额外依赖数据库存储配置开发阶段最省心。如果要用MySQL来持久化Nacos配置需要先初始化nacos-mysql.sql并配置数据库连接复杂度会上升一些。考虑到开发环境的定位配置中心我们后面完全可以靠git管理或者定期导出来备份所以默认用内置存储保证启动链路最短。NACOS_AUTH_ENABLE设为false是为了方便开发时调试不用每次带token访问。这个开关在生产环境必须打开但开发阶段关掉能减少很多干扰。3.3 MySQL和Redis的生产习惯从第一天就开始MySQL容器定义里有两个细节值得说。第一通过command显式指定了字符集和排序规则这能避免在Linux环境下安装MySQL就默认latin1而出现中文乱码的老问题。第二./init-sql目录会被挂载到容器的初始化脚本目录在容器首次启动时这个目录下的.sql文件会自动执行。也就是说微服务需要的建库语句、初始化数据、账号权限都可以提前放在这个目录里第一次启动就自动完成不需要再手动执行SQL脚本。Redis的配置里加上了--appendonly yes开启了AOF持久化。开发环境下Redis可能存储了一些缓存外的数据开启持久化能让容器重启后缓存不全部丢光做本地调试时体验好很多。数据卷挂载到/data这刚好是Redis容器里持久化文件的默认位置。无论是MySQL还是Redis都使用了restart: unless-stopped。这个重启策略保证开发机重启或者Docker服务重启后中间件能自动拉起来省去手动start一堆容器的麻烦。注意这个策略不代表容器永远不停止你手动执行docker compose stop还是会停掉的只是跟服务开机自启解绑了不需要开机自动启动所有东西。3.4 RabbitMQ和MinIO的作用与配置RabbitMQ的镜像选择了带management后缀的版本这个镜像里已经打包了Web管理插件。5672是AMQP协议端口供客户端应用连接15672是管理控制台的HTTP端口。打开http://localhost:15672输入创建的用户mquser和密码mqpass就能看到队列、连接、存活情况。开发阶段我会把消息消费失败的队列、死信队列等都从控制台里确认这个管理界面非常关键。MinIO的启动命令里server /data是启动对象存储服务的主命令--console-address :9001是把管理台终端绑定到9001端口。9000端口则是与S3兼容的对象存储API端口业务代码上传文件走的都是9000。开发环境下的默认账号minioadmin在日常开发时可以直接用这个账号连接但到了测试环境就一定要换掉默认凭据。我在MinIO数据卷上同样使用了命名卷。文件存储和数据库一样是无价的资产万一容器被误删命名卷里的数据还在不会跟着容器一起消失。3.5 一条命令启动并验证配置文件准备好后切换到docker-compose.yml所在目录执行docker compose up -d-d参数表示后台运行启动过程不会一直占着终端。第一次启动因为要pull镜像可能需要等几分钟之后再次启动就很快。启动完成后用下面的命令确认每个容器的状态docker compose ps docker compose logs -f nacos各组件就绪后可以访问以下控制台做人工确认服务开发地址默认账号Nacos配置中心http://localhost:8848/nacosnacos / nacosRabbitMQ管理台http://localhost:15672mquser / mqpassMinIO管理台http://localhost:9001minioadmin / minioadminMySQLlocalhost:3306root / root123到这里基础设施这层已经立起来了。只需要一条命令搭建一台新机器从零到跑起来全部中间件基本在十几分钟内能完成。4. Spring Cloud多模块脚手架工程初始化4.1 Maven工程目录划分基础设施准备好之后开始初始化脚手架代码工程。我建议按下面的方式划分模块sc-parent ├── sc-common ├── sc-gateway └── sc-service ├── sc-service-user └── sc-service-ordersc-parent是Maven父工程只做依赖版本管理不写业务代码。sc-common放公共工具类、统一返回体、全局异常、常量类这些被所有业务模块复用的部分。sc-gateway是网关模块对应Spring Cloud Gateway负责路由转发、跨域、统一鉴权。sc-service下面再按领域拆出一个个业务服务比如用户服务和订单服务。模块划分上有两个原则我始终坚持。第一common模块绝对不引入spring-boot-starter-web因为这个模块会被打成jar包给各个服务依赖引入web会带来多余的自动配置。第二网关模块尽量不引业务相关的客户端依赖保持专注否则网关启动时的自动装配会变得很臃肿。4.2 Spring Boot和Spring Cloud版本必须锁定版本组合是微服务脚手架里最让我头大的部分没有之一。Spring Boot、Spring Cloud、Spring Cloud Alibaba这三个东西的版本是强对应的乱配版本只会出现在编译报错或者启动失败的荒诞场面里。下面这张表是最常用的几个稳定组合Spring BootSpring CloudSpring Cloud AlibabaJDK参考2.7.182021.0.82021.0.5.08或113.0.72022.0.32022.0.0.0173.2.x2023.0.x2023.0.0.x17我这次以Spring Boot 2.7.18为主讲不是因为它最新恰恰相反是因为它最成熟稳定。很多线上项目的依赖包、本地调试插件都还停留在JDK 8生态而2.7.18依然兼容JDK 8不用升级编译环境。在父工程的pom里通过dependencyManagement统一管理这三个依赖集子模块里都不用写版本号。父pom关键配置如下properties spring.boot.version2.7.18/spring.boot.version spring.cloud.version2021.0.8/spring.cloud.version spring.cloud.alibaba.version2021.0.5.0/spring.cloud.alibaba.version /properties dependencyManagement dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-dependencies/artifactId version${spring.boot.version}/version typepom/type scopeimport/scope /dependency dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-dependencies/artifactId version${spring.cloud.version}/version typepom/type scopeimport/scope /dependency dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-alibaba-dependencies/artifactId version${spring.cloud.alibaba.version}/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement为什么一定要用BOM而不是自己写一堆version因为Spring Cloud这些体系内的依赖非常密集父级BOM已经把数百个依赖的版本都排列好了。自己手动指定某个依赖版本很容易出现与体系内部其他组件不兼容的情况。比如用了某个新版的OpenFeign结果跟spring-cloud-commons里的重试机制起了冲突。用BOM等于拿到了官方匹配过的版本集合。4.3 子模块依赖怎么给每个子模块的依赖必须克制。很多脚手架常见问题是每个模块都复制一份全部依赖最后导致整个系统里充满了无用的jar包。我给出两个具体的依赖组合示例。gateway模块的关键依赖dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-gateway/artifactId /dependency dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactId /dependency dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-loadbalancer/artifactId /dependency注意Spring Cloud Gateway需要基于WebFlux运行所以这里不能引入spring-boot-starter-web。按理说gateway模块还需要引入nacos-config来做动态配置但我建议开发阶段先不引入因为配置中心一旦启用本地配置文件的加载顺序就变了新成员第一次跑的时候很容易困惑。service-user模块的关键依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactId /dependency dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-config/artifactId /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency业务服务要连接MySQL和Redis这块依赖走上之后还需要数据源的具体配置。另外由于我们引入了nacos-configapplication.yml里的配置会被配置中心的数据覆盖具体怎么不踩坑在下一节说明。4.4 本地开发配置与容器环境的连接关系这里必须说清楚一个最容易混淆的点。我们的数据库、Redis、Nacos都在Docker容器里运行它们通过端口映射暴露在宿主机的localhost上。本地启动Spring Boot服务时它直接连宿主机端口所以配置写的地址一定是localhost而不是容器名称。在Spring Boot 2.7下如果要使用Nacos配置中心需要在classpath下放bootstrap.yml。这个文件名是Spring Cloud里启动引导阶段的配置文件它负责在应用主配置加载前先建立与Nacos的连接。配置文件内容如下spring: application: name: service-user cloud: nacos: discovery: server-addr: localhost:8848 config: server-addr: localhost:8848 file-extension: yaml然后在application.yml里写数据源和缓存连接spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/sc_main?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue username: root password: root123 redis: host: localhost port: 6379 rabbitmq: host: localhost port: 5672 username: mquser password: mqpass如果你的团队约定在同一台开发机上跑一套Docker基础环境那么这些配置基本就是公共配置。建议把这部分直接放入Nacos的共享配置里比如配置中心里的一个dataId叫common.yaml所有服务都通过shared-configs引入这个dataId确保每个服务都拿到一致的环境信息。另一个容易踩坑的点是MySQL连接串里的allowPublicKeyRetrievaltrue。MySQL 8.0默认使用caching_sha2_password认证插件如果客户端连接时没有安全传输通道就会因为无法获取公钥而报错。加上这个参数能避免开发阶段反复出现认证失败的问题。5. 常见问题与排查实录5.1 镜像拉取太慢或者直接失败表现是执行docker compose up -d后长时间卡在pull阶段或者直接报i/o timeout。方法有两个层面。第一先检查daemon.json里的registry-mirrors配置是否生效用docker info查看。第二确认镜像地址是否写对比如Nacos的规格就是nacos/nacos-server:v2.2.3不要用带latest的写法。latest虽然方便但镜像变动完全不可控以后环境的不可复现性会来自这里。如果镜像确实拉不下来还有一种临时对策在能联网的其他机器上把镜像导出再用docker load导入开发机。这个方式适合内网环境但前提是你的开发环境与外部之间确实有这个允许条件不能把“拉镜像”问题复杂化。5.2 Nacos能启动但服务注册一直失败服务配置写的是localhost:8848但一注册就报连接异常。这种情况九成是9848端口没映射。客户端在注册时会尝试建立gRPC通道默认端口号是主端口的偏移量。排查方法是看容器端口映射是否包含9848没有就把- 9848:9848加到Nacos服务定义下然后重启容器。还有一种可能是本地代理或者防火墙拦截了gRPC长连接。开发机上如果跑着全局网络代理必须把localhost和127.0.0.1的地址排除代理否则长连接会被代理打断。这一条在本地调试时很隐蔽因为普通HTTP访问正常只有长连接超时频繁。5.3 MySQL首次启动时初始化脚本没执行我把SQL脚本挂载到了./init-sql目录但第一次启动后发现表没建。原因多半是容器数据卷里已经有旧数据了。MySQL官方镜像的初始化脚本只会在数据目录为空时执行如果之前已经启动过并且写入过数据第二次挂载脚本不会重新执行。解决办法是先确认卷里是不是空数据如果不需要保留就用docker compose down -v把卷一并删掉再来一次全新启动。开发阶段的SQL脚本本身也可以反复修改但一旦数据卷有数据就要把脚本和迁移逻辑分开管理数据库结构后续的增量变更要用自动化迁移工具来做了。5.4 本地服务连不上Redis或MySQL先确认宿主机端口能通用nc -vz localhost 6379或者telnet测试。如果端口通但应用连接还是失败重点看应用日志里的具体异常。如果提示connection refused多半是Docker容器没起来或者端口映射不对。如果提示password error检查application.yml里的密码与compose环境变量是否一致。这里顺带提一个常见的坑如果你前面有旧版MySQL或者Redis服务占用了3306或者6379容器会启动失败因为端口映射失败。这时候docker compose ps会看到端口混乱的状态先处理冲突再回来重启容器。5.5 占用内存过高导致开发机卡顿一组中间件全起来大约占2G到3G内存如果再开两个IDEA窗口和浏览器资源确实比较紧张。我常用两个手段控制内存。第一在Docker Desktop的设置里给引擎减小内存分配同时注意不要减到太小MySQL和Nacos都吃内存。第二不用的服务单独stop比如暂时不用RabbitMQ时执行docker compose stop rabbitmq这个操作不会删掉容器下次用的时候start就能恢复。5.6 常见问题速查表现象根因处理方式镜像拉取卡住网络链路问题配置registry mirror固定镜像tagNacos服务注册报错9848端口未映射补充gRPC端口映射MySQL中文乱码字符集默认latin1command参数改为utf8mb4初始化SQL没生效数据卷非空清理卷后重新创建Redis连接认证失败前后端密码不一致对比compose与application.yml端口占用了其他进程占用lsof定位后释放或改映射服务能启动但重启后配置丢失Nacos持久化没做开发阶段做好配置导出备份写在最后从Docker环境编排到SpringCloud模块划分再到本地连接验证这套流程我前后实践过两轮。第一轮踩坑比较多主要精力花在排查各种奇怪的网络和版本问题上第二轮整理成标准方案后团队新成员只要把compose文件拉下来执行docker compose up -d然后按README里的连接信息启动自己的服务模块半小时内就能开始编码。我个人最大的体会是环境搭建这件事如果第一次不做得足够规范后面每个新成员都会在这里消耗时间而Docker只是工具真正难的是对组件端口、版本、持久化方式这些细节的统一规划。最后再给一个扩展建议等脚手架稳定运行后可以把同一份docker-compose配置集成到项目的持续集成流程里。打包阶段的自动化测试直接用这组容器环境执行既能保证测试环境的一致性又能让持续集成不依赖任何人本地的“神秘环境”。这套小改动看起来不起眼却能把微服务开发的前期成本压缩到极低剩下的时间就可以专心放在业务代码和架构演进上了。
微服务开发有个最容易被低估的环节SpringCloud脚手架怎么落地第一关不是业务代码而是开发环境能不能整整齐齐拉起来。我说个常见场景新成员拿到项目后先花半天装Nacos、装MySQL、装Redis装到一半发现本机某个端口被旧服务占了或者MySQL版本跟团队不一致最后的结局经常是“在我机器上明明是好的”。这种问题其实可以通过Docker栈整体解决——用一个docker-compose把微服务基础设施全部编排起来一条命令启动项目代码单独在IDE里跑两边通过localhost互联。这篇就是围绕这个思路带你把这套环境彻底搭明白。这篇内容适合谁看准备做SpringCloud脚手架的个人开发者或者小团队里负责搭建基础环境的人。核心目标是把基础设施建设做到“可复制、可重置、不污染本机”同时把SpringCloud多模块工程的依赖关系理顺。全文会用一套可以直接抄走的实践方案来讲包括组件选型、docker-compose配置、Spring Boot版本对应以及我搭环境时踩过的各种坑。1. 为什么微服务开发环境要交给 Docker1.1 手动安装环境的典型困境第一次搭微服务脚手架的时候我犯过一个特别蠢的错误为了迁就某个老项目的MySQL版本先在机器上装了个MySQL 5.7后来又给新项目装MySQL 8.0。两个服务为了抢3306端口折腾了半天最后把系统搞得很混乱。后来再做另一个产品发现不只是数据库Redis、RabbitMQ、Nacos这些基础组件全都面临同样的问题。更重要的是团队协作层面的麻烦。每个人的操作系统不一样有的用Win有的用macOS还有的用Linux发行版安装步骤完全不同。就算系统一致安装在默认路径下的配置差异也会导致各种幺蛾子。比如Nacos的启动脚本在某种内存配置下频繁宕机比如RabbitMQ缺了管理插件比如MySQL的字符集没配对导致中文乱码。这些跟业务代码毫无关系的问题却会消耗掉前期搭建脚手架的大量时间。Docker的介入把这一整块问题从“系统环境”变成了“文本文件”。所有基础设施运行在容器里数据通过卷持久化容器坏了直接重建与本机系统完全隔离。脚手架的价值是让新成员能快速上手如果一个项目连环境都不能一小时内跑起来那后面无论代码写得多优雅团队成员的第一体验都不会好。1.2 手动安装与Docker编排的对比我经常会看一些团队做基础设施选型一种是本机直接安装服务另一种是Docker Compose统一编排。两者的差距在实际使用中非常明显对比项本机手动安装Docker Compose编排安装成本每个组件单独下载、配置不同系统步骤不同一个compose文件一键拉起版本一致性全靠自觉容易版本漂移镜像版本固定所有人完全一致环境隔离服务直接暴露在本机相互冲突容器隔离端口和数据卷独立规划重置成本卸载残留非常多清理困难删除容器和卷即可干净利落资源占用开机自启的服务多长期占内存可以随时up和down不占常驻资源团队协作新成员靠文档摸索克隆项目后执行一条命令即可在这组对比里最核心的价值是“可复制性”。基础设施从“需要手工一件一件搭”变成“一份声明式文件”这跟代码本身是同一套思维用文件描述最终状态工具负责收敛差异。1.3 SpringCloud脚手架需要的基础设施池一个典型的微服务脚手架需要的绝不只是MySQL和Redis。根据业务形态的不同基础设施池会有所差异但按我个人的经验起步阶段至少要把下面这五类组件纳入开发环境注册与配置中心Nacos承担服务发现、服务配置、命名空间管理是微服务架构的中枢。关系型数据库MySQL 8.0业务数据的主存储在一开始就按utf8mb4统一字符集规划。缓存Redis承担会话、热点数据、分布式锁等场景。消息队列RabbitMQ用于异步通知、削峰填谷、最终一致性等开发阶段必须有环境验证。对象存储MinIO用来模拟文件、图片等静态资源的存储服务避免开发时直接依赖云对象存储。有条件的团队可能还会加Elasticsearch、SkyWalking、Kafka等但第一轮脚手架不需要太贪多。组件每多一个本地内存就多耗一部分排查链路的负担也会变大。先把这五类跑稳定后面需要的组件再用同样的编排思路往compose里加成本很低。2. 先把Docker和Compose踩实安装、加速与网络规划2.1 Docker安装后的镜像加速配置Docker的安装本身不复杂桌面版装好之后可以直接使用。但有一个细节必须在一开始就处理好镜像下载。不同网络环境下Docker Hub的访问体验差别很大经常出现pull镜像卡很久或者超时的情况。这不是玄学而是镜像仓库网络链路的问题需要在Docker配置里加上registry mirror。具体做法是修改Docker的配置文件在Linux环境通常是/etc/docker/daemon.json在桌面版则是通过图形界面的“Docker Engine”配置项修改。格式如下{ registry-mirrors: [ https://docker.mirrors.example.com ] }这里要提醒一句mirrors地址不是随便填的需要根据自己的网络环境选择合适的可用镜像地址。配置完之后执行docker info如果看到Registry Mirrors一栏有内容说明配置生效。这一步最好在做任何编排之前完成否则后面拉Nacos镜像时可能白白等很久。2.2 端口冲突检查与资源规划容器虽然都处于网络隔离中但它要把服务端口映射到宿主机所以依然会遇到端口占用问题。启动整个环境之前我建议先查一下这几个关键端口3306、6379、8848、9848、15672、5672、9000、9001。尤其3306和6379这两种服务在很多机器上可能已经被装过。可以用这样的命令检查lsof -i :3306 netstat -ano | grep 3306如果发现端口被占用有两个选择先停掉占用进程或者修改compose里宿主机侧的映射端口。比如把3306改成33061映射到容器内的3306应用配置同步调整。开发环境尽量保持与生产一致的端口语义所以最好清理掉旧的占用而不是反复改映射。另外内存规划也不能忽略。Nacos默认配置会预留较大的堆内存MySQL、Redis再叠加进去整套环境跑起来大约占2G到3G内存。如果你的开发机内存只有8G还要跑IDEA和本地编译可能会比较吃力。建议在Docker设置里调整资源限制把内存上限从默认的2G调高到4G并留意不要同时启动太多无关容器。2.3 网络与数据的统一规划Compose文件里我会固定使用一个自定义网络让所有容器都加入同一个bridge网络。这么做的好处是容器之间可以用服务名直接互相访问。虽然本地开发时Spring Boot跑在宿主机上并不需要容器间的通信但后续如果需要把部分微服务也容器化跑起来提前把网络规划好能省很多事。数据持久化方面三层结构要分开说容器是无状态的运行依赖镜像数据是有状态的通过卷持久化配置文件也可以作为卷挂载进去。我比较推荐用命名卷named volume而不是宿主机目录的直接挂载。命名卷的好处是数据位置由Docker统一管理删除容器时卷默认不会被删重置环境更安全。网络和卷的声明放在compose文件的底部这在后面的配置里可以直接看到。3. 基础设施编排Docker Compose 一键拉起3.1 完整Compose文件这里直接给出一份经过实际验证的docker-compose配置基于Docker Compose v2语法不需要写version字段。所有镜像版本我特意固定住了避免以后拉取时因为镜像tag变化导致行为不一致services: mysql: image: mysql:8.0.32 container_name: sc-mysql restart: unless-stopped ports: - 3306:3306 environment: MYSQL_ROOT_PASSWORD: root123 TZ: Asia/Shanghai command: - --character-set-serverutf8mb4 - --collation-serverutf8mb4_unicode_ci volumes: - mysql-data:/var/lib/mysql - ./init-sql:/docker-entrypoint-initdb.d:ro networks: - sc-net healthcheck: test: [CMD, mysqladmin, ping, -h, localhost, -proot123] interval: 10s timeout: 5s retries: 10 redis: image: redis:7.0.11 container_name: sc-redis restart: unless-stopped ports: - 6379:6379 command: [redis-server, --appendonly, yes] volumes: - redis-data:/data networks: - sc-net nacos: image: nacos/nacos-server:v2.2.3 container_name: sc-nacos restart: unless-stopped environment: MODE: standalone NACOS_AUTH_ENABLE: false ports: - 8848:8848 - 9848:9848 networks: - sc-net rabbitmq: image: rabbitmq:3.11-management container_name: sc-rabbitmq restart: unless-stopped ports: - 5672:5672 - 15672:15672 environment: RABBITMQ_DEFAULT_USER: mquser RABBITMQ_DEFAULT_PASS: mqpass networks: - sc-net minio: image: minio/minio:RELEASE.2023-04-07T18-55-22Z container_name: sc-minio restart: unless-stopped command: server /data --console-address :9001 ports: - 9000:9000 - 9001:9001 environment: MINIO_ROOT_USER: minioadmin MINIO_ROOT_PASSWORD: minioadmin volumes: - minio-data:/data networks: - sc-net networks: sc-net: driver: bridge volumes: mysql-data: redis-data: minio-data:把这份配置保存为docker-compose.yml然后放在微服务项目根目录下。我通常会把它放成一个独立目录/deploy/env与代码工程分开管理这样后续不管是新增中间件还是调整端口都在一个明确的位置操作。3.2 Nacos需要记住的两个端口Nacos的配置里最容易踩坑的是端口。8848是主HTTP端口而9848则是Nacos 2.x版本的gRPC通信端口服务注册时客户端和客户端之间有一部分通信走gRPC。如果只映射8848从Spring Cloud Alibaba启动服务时日志里通常会报连接失败类似“failed to req API”或端口不可用。在这一版compose里MODE设置成了standalone。这个是Nacos单机模式不需要额外依赖数据库存储配置开发阶段最省心。如果要用MySQL来持久化Nacos配置需要先初始化nacos-mysql.sql并配置数据库连接复杂度会上升一些。考虑到开发环境的定位配置中心我们后面完全可以靠git管理或者定期导出来备份所以默认用内置存储保证启动链路最短。NACOS_AUTH_ENABLE设为false是为了方便开发时调试不用每次带token访问。这个开关在生产环境必须打开但开发阶段关掉能减少很多干扰。3.3 MySQL和Redis的生产习惯从第一天就开始MySQL容器定义里有两个细节值得说。第一通过command显式指定了字符集和排序规则这能避免在Linux环境下安装MySQL就默认latin1而出现中文乱码的老问题。第二./init-sql目录会被挂载到容器的初始化脚本目录在容器首次启动时这个目录下的.sql文件会自动执行。也就是说微服务需要的建库语句、初始化数据、账号权限都可以提前放在这个目录里第一次启动就自动完成不需要再手动执行SQL脚本。Redis的配置里加上了--appendonly yes开启了AOF持久化。开发环境下Redis可能存储了一些缓存外的数据开启持久化能让容器重启后缓存不全部丢光做本地调试时体验好很多。数据卷挂载到/data这刚好是Redis容器里持久化文件的默认位置。无论是MySQL还是Redis都使用了restart: unless-stopped。这个重启策略保证开发机重启或者Docker服务重启后中间件能自动拉起来省去手动start一堆容器的麻烦。注意这个策略不代表容器永远不停止你手动执行docker compose stop还是会停掉的只是跟服务开机自启解绑了不需要开机自动启动所有东西。3.4 RabbitMQ和MinIO的作用与配置RabbitMQ的镜像选择了带management后缀的版本这个镜像里已经打包了Web管理插件。5672是AMQP协议端口供客户端应用连接15672是管理控制台的HTTP端口。打开http://localhost:15672输入创建的用户mquser和密码mqpass就能看到队列、连接、存活情况。开发阶段我会把消息消费失败的队列、死信队列等都从控制台里确认这个管理界面非常关键。MinIO的启动命令里server /data是启动对象存储服务的主命令--console-address :9001是把管理台终端绑定到9001端口。9000端口则是与S3兼容的对象存储API端口业务代码上传文件走的都是9000。开发环境下的默认账号minioadmin在日常开发时可以直接用这个账号连接但到了测试环境就一定要换掉默认凭据。我在MinIO数据卷上同样使用了命名卷。文件存储和数据库一样是无价的资产万一容器被误删命名卷里的数据还在不会跟着容器一起消失。3.5 一条命令启动并验证配置文件准备好后切换到docker-compose.yml所在目录执行docker compose up -d-d参数表示后台运行启动过程不会一直占着终端。第一次启动因为要pull镜像可能需要等几分钟之后再次启动就很快。启动完成后用下面的命令确认每个容器的状态docker compose ps docker compose logs -f nacos各组件就绪后可以访问以下控制台做人工确认服务开发地址默认账号Nacos配置中心http://localhost:8848/nacosnacos / nacosRabbitMQ管理台http://localhost:15672mquser / mqpassMinIO管理台http://localhost:9001minioadmin / minioadminMySQLlocalhost:3306root / root123到这里基础设施这层已经立起来了。只需要一条命令搭建一台新机器从零到跑起来全部中间件基本在十几分钟内能完成。4. Spring Cloud多模块脚手架工程初始化4.1 Maven工程目录划分基础设施准备好之后开始初始化脚手架代码工程。我建议按下面的方式划分模块sc-parent ├── sc-common ├── sc-gateway └── sc-service ├── sc-service-user └── sc-service-ordersc-parent是Maven父工程只做依赖版本管理不写业务代码。sc-common放公共工具类、统一返回体、全局异常、常量类这些被所有业务模块复用的部分。sc-gateway是网关模块对应Spring Cloud Gateway负责路由转发、跨域、统一鉴权。sc-service下面再按领域拆出一个个业务服务比如用户服务和订单服务。模块划分上有两个原则我始终坚持。第一common模块绝对不引入spring-boot-starter-web因为这个模块会被打成jar包给各个服务依赖引入web会带来多余的自动配置。第二网关模块尽量不引业务相关的客户端依赖保持专注否则网关启动时的自动装配会变得很臃肿。4.2 Spring Boot和Spring Cloud版本必须锁定版本组合是微服务脚手架里最让我头大的部分没有之一。Spring Boot、Spring Cloud、Spring Cloud Alibaba这三个东西的版本是强对应的乱配版本只会出现在编译报错或者启动失败的荒诞场面里。下面这张表是最常用的几个稳定组合Spring BootSpring CloudSpring Cloud AlibabaJDK参考2.7.182021.0.82021.0.5.08或113.0.72022.0.32022.0.0.0173.2.x2023.0.x2023.0.0.x17我这次以Spring Boot 2.7.18为主讲不是因为它最新恰恰相反是因为它最成熟稳定。很多线上项目的依赖包、本地调试插件都还停留在JDK 8生态而2.7.18依然兼容JDK 8不用升级编译环境。在父工程的pom里通过dependencyManagement统一管理这三个依赖集子模块里都不用写版本号。父pom关键配置如下properties spring.boot.version2.7.18/spring.boot.version spring.cloud.version2021.0.8/spring.cloud.version spring.cloud.alibaba.version2021.0.5.0/spring.cloud.alibaba.version /properties dependencyManagement dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-dependencies/artifactId version${spring.boot.version}/version typepom/type scopeimport/scope /dependency dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-dependencies/artifactId version${spring.cloud.version}/version typepom/type scopeimport/scope /dependency dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-alibaba-dependencies/artifactId version${spring.cloud.alibaba.version}/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement为什么一定要用BOM而不是自己写一堆version因为Spring Cloud这些体系内的依赖非常密集父级BOM已经把数百个依赖的版本都排列好了。自己手动指定某个依赖版本很容易出现与体系内部其他组件不兼容的情况。比如用了某个新版的OpenFeign结果跟spring-cloud-commons里的重试机制起了冲突。用BOM等于拿到了官方匹配过的版本集合。4.3 子模块依赖怎么给每个子模块的依赖必须克制。很多脚手架常见问题是每个模块都复制一份全部依赖最后导致整个系统里充满了无用的jar包。我给出两个具体的依赖组合示例。gateway模块的关键依赖dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-gateway/artifactId /dependency dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactId /dependency dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-loadbalancer/artifactId /dependency注意Spring Cloud Gateway需要基于WebFlux运行所以这里不能引入spring-boot-starter-web。按理说gateway模块还需要引入nacos-config来做动态配置但我建议开发阶段先不引入因为配置中心一旦启用本地配置文件的加载顺序就变了新成员第一次跑的时候很容易困惑。service-user模块的关键依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactId /dependency dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-config/artifactId /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency业务服务要连接MySQL和Redis这块依赖走上之后还需要数据源的具体配置。另外由于我们引入了nacos-configapplication.yml里的配置会被配置中心的数据覆盖具体怎么不踩坑在下一节说明。4.4 本地开发配置与容器环境的连接关系这里必须说清楚一个最容易混淆的点。我们的数据库、Redis、Nacos都在Docker容器里运行它们通过端口映射暴露在宿主机的localhost上。本地启动Spring Boot服务时它直接连宿主机端口所以配置写的地址一定是localhost而不是容器名称。在Spring Boot 2.7下如果要使用Nacos配置中心需要在classpath下放bootstrap.yml。这个文件名是Spring Cloud里启动引导阶段的配置文件它负责在应用主配置加载前先建立与Nacos的连接。配置文件内容如下spring: application: name: service-user cloud: nacos: discovery: server-addr: localhost:8848 config: server-addr: localhost:8848 file-extension: yaml然后在application.yml里写数据源和缓存连接spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/sc_main?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue username: root password: root123 redis: host: localhost port: 6379 rabbitmq: host: localhost port: 5672 username: mquser password: mqpass如果你的团队约定在同一台开发机上跑一套Docker基础环境那么这些配置基本就是公共配置。建议把这部分直接放入Nacos的共享配置里比如配置中心里的一个dataId叫common.yaml所有服务都通过shared-configs引入这个dataId确保每个服务都拿到一致的环境信息。另一个容易踩坑的点是MySQL连接串里的allowPublicKeyRetrievaltrue。MySQL 8.0默认使用caching_sha2_password认证插件如果客户端连接时没有安全传输通道就会因为无法获取公钥而报错。加上这个参数能避免开发阶段反复出现认证失败的问题。5. 常见问题与排查实录5.1 镜像拉取太慢或者直接失败表现是执行docker compose up -d后长时间卡在pull阶段或者直接报i/o timeout。方法有两个层面。第一先检查daemon.json里的registry-mirrors配置是否生效用docker info查看。第二确认镜像地址是否写对比如Nacos的规格就是nacos/nacos-server:v2.2.3不要用带latest的写法。latest虽然方便但镜像变动完全不可控以后环境的不可复现性会来自这里。如果镜像确实拉不下来还有一种临时对策在能联网的其他机器上把镜像导出再用docker load导入开发机。这个方式适合内网环境但前提是你的开发环境与外部之间确实有这个允许条件不能把“拉镜像”问题复杂化。5.2 Nacos能启动但服务注册一直失败服务配置写的是localhost:8848但一注册就报连接异常。这种情况九成是9848端口没映射。客户端在注册时会尝试建立gRPC通道默认端口号是主端口的偏移量。排查方法是看容器端口映射是否包含9848没有就把- 9848:9848加到Nacos服务定义下然后重启容器。还有一种可能是本地代理或者防火墙拦截了gRPC长连接。开发机上如果跑着全局网络代理必须把localhost和127.0.0.1的地址排除代理否则长连接会被代理打断。这一条在本地调试时很隐蔽因为普通HTTP访问正常只有长连接超时频繁。5.3 MySQL首次启动时初始化脚本没执行我把SQL脚本挂载到了./init-sql目录但第一次启动后发现表没建。原因多半是容器数据卷里已经有旧数据了。MySQL官方镜像的初始化脚本只会在数据目录为空时执行如果之前已经启动过并且写入过数据第二次挂载脚本不会重新执行。解决办法是先确认卷里是不是空数据如果不需要保留就用docker compose down -v把卷一并删掉再来一次全新启动。开发阶段的SQL脚本本身也可以反复修改但一旦数据卷有数据就要把脚本和迁移逻辑分开管理数据库结构后续的增量变更要用自动化迁移工具来做了。5.4 本地服务连不上Redis或MySQL先确认宿主机端口能通用nc -vz localhost 6379或者telnet测试。如果端口通但应用连接还是失败重点看应用日志里的具体异常。如果提示connection refused多半是Docker容器没起来或者端口映射不对。如果提示password error检查application.yml里的密码与compose环境变量是否一致。这里顺带提一个常见的坑如果你前面有旧版MySQL或者Redis服务占用了3306或者6379容器会启动失败因为端口映射失败。这时候docker compose ps会看到端口混乱的状态先处理冲突再回来重启容器。5.5 占用内存过高导致开发机卡顿一组中间件全起来大约占2G到3G内存如果再开两个IDEA窗口和浏览器资源确实比较紧张。我常用两个手段控制内存。第一在Docker Desktop的设置里给引擎减小内存分配同时注意不要减到太小MySQL和Nacos都吃内存。第二不用的服务单独stop比如暂时不用RabbitMQ时执行docker compose stop rabbitmq这个操作不会删掉容器下次用的时候start就能恢复。5.6 常见问题速查表现象根因处理方式镜像拉取卡住网络链路问题配置registry mirror固定镜像tagNacos服务注册报错9848端口未映射补充gRPC端口映射MySQL中文乱码字符集默认latin1command参数改为utf8mb4初始化SQL没生效数据卷非空清理卷后重新创建Redis连接认证失败前后端密码不一致对比compose与application.yml端口占用了其他进程占用lsof定位后释放或改映射服务能启动但重启后配置丢失Nacos持久化没做开发阶段做好配置导出备份写在最后从Docker环境编排到SpringCloud模块划分再到本地连接验证这套流程我前后实践过两轮。第一轮踩坑比较多主要精力花在排查各种奇怪的网络和版本问题上第二轮整理成标准方案后团队新成员只要把compose文件拉下来执行docker compose up -d然后按README里的连接信息启动自己的服务模块半小时内就能开始编码。我个人最大的体会是环境搭建这件事如果第一次不做得足够规范后面每个新成员都会在这里消耗时间而Docker只是工具真正难的是对组件端口、版本、持久化方式这些细节的统一规划。最后再给一个扩展建议等脚手架稳定运行后可以把同一份docker-compose配置集成到项目的持续集成流程里。打包阶段的自动化测试直接用这组容器环境执行既能保证测试环境的一致性又能让持续集成不依赖任何人本地的“神秘环境”。这套小改动看起来不起眼却能把微服务开发的前期成本压缩到极低剩下的时间就可以专心放在业务代码和架构演进上了。
