本地Docker Compose微服务转Heroku等PaaS生产环境部署问题咨询

刚好之前帮团队把Docker Compose部署的微服务迁到Heroku，给你分享几个实用的替代方案，都是踩过坑后验证有效的：

方案1：环境变量传递服务访问地址（最常用、零额外成本） #

本地Docker Compose里你用user-service这种服务名直接访问，本质是利用了Docker的内部DNS解析。到Heroku上，你可以把每个微服务单独部署成独立的Heroku App，然后通过环境变量把服务的访问地址传递给依赖它的服务：

• 比如用户服务部署后会得到一个公网URL：https://your-user-service.herokuapp.com，你给前端服务设置环境变量：heroku config:set USER_SERVICE_URL=https://your-user-service.herokuapp.com
• 代码里把原来硬编码服务名的地方，改成读取环境变量。比如Node.js里原来的fetch('http://user-service:3000/api/users')，改成fetch(${process.env.USER_SERVICE_URL}/api/users)
• 数据库不用自己部署容器，直接用Heroku提供的托管插件（比如Postgres、MongoDB），这些插件会自动给你的服务生成DATABASE_URL这类环境变量，代码直接读取这个变量连接数据库就行。

方案2：Heroku Private Spaces 内部网络（适合需要私有通信的场景） #

如果你的团队有预算，Heroku Private Spaces提供了私有内部网络，同一个Space里的App可以通过内部域名通信，和本地Docker Compose的体验几乎一致：

• 把所有微服务部署到同一个Private Space，每个服务会得到一个内部域名，格式是your-app-name.herokuapp.internal
• 代码里直接用这个内部域名访问，比如http://user-service.herokuapp.internal:${process.env.PORT}，不需要暴露公网URL，安全性更高。
• 注意：内部访问也要用Heroku分配的$PORT端口，不能用本地硬编码的端口。

方案3：轻量服务发现工具（适合复杂微服务架构） #

如果你的服务数量很多，不想手动维护环境变量，可以用Consul这类服务发现工具：

• 在Heroku上部署一个Consul服务器App，每个微服务启动时，把自己的服务地址注册到Consul
• 其他服务需要调用时，先查询Consul的API获取目标服务的地址，再发起请求
• 这种方式需要额外维护Consul服务，适合服务数量超过5个以上的复杂架构。

• 端口适配：所有Heroku上的Web服务必须监听$PORT环境变量指定的端口，代码里要写app.listen(process.env.PORT || 3000)这类逻辑，不能硬编码端口。
• 跨域处理：如果前端是独立的Heroku App，调用后端服务时会遇到跨域问题，需要在后端配置CORS，允许前端的域名访问，或者用Heroku的反向代理插件统一域名。
• 环境变量管理：用Heroku CLI的heroku config:set命令或者Dashboard的配置页面统一管理环境变量，避免硬编码在代码里。

内容的提问来源于stack exchange，提问作者kpxn