Railway Docker 服务单实例并发不足时，官方建议如何扩容？
8月 7, 2026
说明：本文由 Codex 根据 Railway 官方公开文档整理，属于 AI 生成/整理内容，非作者原创。产品规则可能变化，请以文末官方文档为准。
结论：为同一个 Railway Service 增加 Replicas（副本），做水平扩展。 这也是 Railway 在生产就绪清单中明确建议的做法：至少配置 2 个副本，使一个实例崩溃或被长请求占用时，另一个实例仍可继续处理请求。
这里的“Docker 服务”无论来自 Dockerfile 还是 Docker 镜像，本质上都是 Railway 的 Service；不需要为扩容手工复制成多个独立 Service，也不需要另搭公网负载均衡器。Railway 会基于同一部署镜像创建多个实例，并对公网流量分流。
先分清两种扩容#
- 纵向扩容（vertical autoscaling）：Railway 默认会在订阅计划允许的 vCPU 和内存上限内为单个服务扩容。
- 横向扩容（Replicas）：当单实例的并发或可用性不够时，在服务设置中手动增加副本数。每个副本都是同一部署的独立实例；副本数不是按 CPU 或内存阈值自动增减的 HPA。
对于“单台扛不住并发”这个问题，官方对应的主要方案是第二种。
流量如何分发#
单区域中有多个副本时，Railway 会将该区域的公网流量随机分发到各个副本。多区域部署时，会先把用户路由到最近区域，再在该区域内随机分发。因此，普通 HTTP 服务通常不必额外部署自己的公网负载均衡器。
多区域的主要价值是降低跨地域延迟和提高地域容灾能力；如果数据库仍在单一区域，跨区域副本的数据库访问仍可能有延迟。因此，先在同一区域把副本从 1 增至 2，通常是验证并发扩展的更稳妥起点。
扩容前必须满足的条件#
Railway 当前不支持 sticky sessions。请求可能落到任意副本，所以应用不能依赖本机内存中的会话、用户状态、任务锁或缓存。
实践上应当把共享状态外置，例如：
- 登录会话、共享缓存、分布式锁放到 Redis 或数据库；
- 上传或生成的文件放到对象存储；
- 长耗时任务通过队列交给独立 worker 处理，并做好幂等；
- 检查数据库连接池上限，避免副本增加后总连接数超过数据库承受范围。
后面四项是基于“无粘性会话 + 多实例”的工程设计推论，不是 Railway 对具体中间件的唯一指定方案。
还有一条硬限制：挂载 Railway Volume 的 Service 不能使用 Replicas。 如果当前服务把可写状态放在 Volume 中，需要先把这部分状态拆到合适的外部存储，才能水平扩展。
怎么操作#
在 Dashboard 中进入目标 Service 的 Settings，在 Scale / Regions 中把同一区域的副本数设为 2（或按压测结果继续提高）。副本创建、删除和区域调整会作为 staged change 应用；新副本使用已有部署镜像，缩容的副本会被优雅排空。
也可以在已关联到目标项目和环境的命令行中执行：
# 在 eu-west 区域运行 2 个副本
railway scale eu-west=2
# 指定服务和生产环境
railway scale --service api --environment production eu-west=2该命令会更新副本配置，无需单独触发一次重新部署。Railway CLI 目前支持的总副本数最多为 50（跨所有区域）；实际可用数量仍受套餐限制。整理时的官方套餐上限为：Free 1、Hobby 6、Pro 42、Enterprise 50 个副本，因此 Free 计划不能把一个服务从 1 个副本横向扩到 2 个。
一个实用的落地顺序#
- 先看 Metrics、应用日志和数据库指标，确认瓶颈确实是应用实例的 CPU、内存或并发，而不是慢查询、外部 API 或连接池。
- 把 Web/API 服务改为无状态，并提供能反映“已就绪”的健康检查。
- 同一区域先扩到 2 个副本，压测并观察错误率、延迟、数据库连接数和资源消耗。
- 只有在用户分布或容灾目标需要时，再考虑多区域副本和数据库读副本等架构调整。
官方参考#
整理日期：2026-08-07。