本文原始规划写于无版本标注的时期，本页在 2026-10-30 做了版本核对，并补上各组件当前状态。文中「CPU/内存配额」为估算值，实际部署请按压测结果调整。

零、2026-10 组件版本与状态基准

三个必须修正的认知（原文未涉及）：

• Docker Swarm 已进入维护模式。它不会消失，但不会有新特性。如果预期要长期演进，K3s（轻量 K8s）比 Swarm 更值得投入——单节点 512MB 内存就能跑，学习成本远低于完整 K8s
• Elasticsearch 的许可证是坑。8.x 起是 SSPL/Elastic License 双许可，云厂商不能直接提供托管服务。自建没问题，但若未来想托管给第三方，或被收购尽调，这是法务风险点。替代方案：OpenSearch（Apache 2.0）
• MinIO 的社区版在收缩。过去两年其部分管理功能移入商业版，长期自建需备选。轻量替代：Garage（Rust 写的，S3 兼容）、SeaweedFS

1. 初期阶段：快速验证，降低成本

目标

• 使用 Docker 部署关键服务，快速验证业务模式。
• 通过替代方案简化架构，降低初期成本。

服务架构

服务器配置

• 云服务器：
• CPU：4核。
• 内存：8GB。
• 存储：500GB SSD。
• 带宽：5Mbps。
• 成本：约 ¥400/月。

部署方式

• 使用 Docker Compose 管理所有服务。
• 为每个容器设置资源限制（CPU 和内存），避免资源争用。
• 使用 Docker 卷 持久化数据（如 MySQL、Redis、MinIO 等）。

优点

• 低成本：通过替代方案，初期成本降至最低。
• 快速启动：Docker 化部署可以快速启动项目。
• 灵活性高：可以根据业务需求灵活调整服务配置。

2. 中期阶段：恢复 Docker 部署，提供完整服务

目标

• 使用 Docker 部署完整服务，恢复对 PostgreSQL、MongoDB、RabbitMQ/Kafka、Elasticsearch/Kibana 的支持。
• 为业务增长提供更强大的功能支持。

服务架构

服务器配置

• 云服务器：
• CPU：8核。
• 内存：16GB。
• 存储：1TB SSD。
• 带宽：10Mbps。
• 成本：约 ¥1000/月。

优点

• 功能完整：恢复对关键服务的支持，满足业务增长需求。
• 灵活性高：Docker 化部署便于管理和扩展。
• 成本可控：使用云服务器部署，成本相对较低。

3. 后期阶段：迁移到云服务版本

目标

• 将关键服务迁移到云服务版本，提供更高的性能和可用性。
• 减少运维负担，专注于业务发展。

服务架构

优点

• 高性能：使用阿里云服务提升性能和可用性。
• 可扩展性：支持更大的用户量和更复杂的业务需求。
• 专业支持：阿里云提供技术支持，减少运维负担。

4. 成本估算

5. 可行性分析

(1) 初期阶段

• 优点：
• 低成本，快速启动，适合业务验证。
• 管理简单，减少运维负担。
• 挑战：
• 替代方案可能无法完全满足复杂需求。
• 需要定期备份数据，确保数据安全。

(2) 中期阶段

• 优点：
• 功能完整，满足业务增长需求。
• 灵活性高，便于管理和扩展。
• 挑战：
• 需要投入更多资源进行管理和维护。
• 数据迁移和配置调整可能带来一定风险。

(3) 后期阶段

• 优点：
• 高性能，高可用性，支持更大规模业务。
• 减少运维负担，专注于业务发展。
• 挑战：
• 成本较高，需要根据业务需求合理规划。
• 数据迁移和系统集成可能带来一定风险。

6. 总结

分阶段推进的价值在于：能在控制成本的同时逐步验证业务需求，而不是一次性把预算投在还没被证明的假设上。具体建议：

1. 初期：使用 Docker 部署关键服务，通过替代方案简化架构，快速验证业务模式。
2. 中期：恢复 Docker 部署，提供完整服务，满足业务增长需求。
3. 后期：迁移到云服务版本，提供更高的性能和可用性，支持更大规模业务。

通过这种方式，可以在控制成本的同时，确保业务的稳定性和可扩展性。

后期阶段的核心动作是把 MySQL 迁移到 PolarDB、MinIO 迁移到 OSS，并加购一台 4C8G 服务器 使用 k3s 创建集群，在业务发展的同时逐步恢复 Docker 部署，提升系统的性能和可用性，详细方案见下一节。

三、后期阶段落地方案（PolarDB + OSS + k3s）

落地目标

• MySQL 迁移到 PolarDB：提升数据库性能和可用性。
• MinIO 迁移到 OSS：提供更高性能和可用性的对象存储。
• 加购一台4C8G 服务器：扩展系统资源，支持更多服务。
• 使用 k3s 创建集群：实现容器编排，提升系统管理和扩展能力。
• 恢复 Docker 部署：补齐缺失的服务，提供完整功能支持。

2. 具体步骤

(1) MySQL 迁移到 PolarDB

• 迁移步骤： 1. 在阿里云控制台创建 PolarDB 实例。 2. 使用mysqldump导出 MySQL 数据，并导入 PolarDB。 3. 更新应用配置，将数据库连接指向 PolarDB。
• 优点：
• 提供更高的性能和可用性。
• 支持自动备份和高可用性。
• 成本：约 ¥600/月（2核4GB，100GB 存储）。

(2) MinIO 迁移到 OSS

• 迁移步骤： 1. 在阿里云控制台创建 OSS 存储桶。 2. 使用ossutil同步 MinIO 中的数据到 OSS。 3. 更新应用配置，将存储服务切换到 OSS。
• 优点：
• 提供更高性能和可用性的对象存储。
• 支持自动备份和跨地域复制。
• 成本：按量付费（假设 ¥200/月）。

(3) 加购一台4C8G 服务器

• 配置：
• CPU：4核。
• 内存：8GB。
• 存储：500GB SSD。
• 带宽：5Mbps。
• 成本：约 ¥400/月。
• 用途：
• 与现有服务器组成 k3s 集群，提升系统资源和管理能力。

(4) 使用 k3s 创建集群

• 部署步骤： 1. 在两台服务器上安装 k3s，分别作为 Master 和 Worker 节点。 2. 配置 k3s 集群，确保节点之间通信正常。 3. 使用 kubectl 管理集群，部署服务。
• 优点：
• 轻量级 Kubernetes，适合中小规模集群。
• 提供容器编排能力，便于管理和扩展服务。

(5) 恢复 Docker 部署

• 补齐服务：
• PostgreSQL、MongoDB、RabbitMQ/Kafka、Elasticsearch/Kibana、GitLab/Jenkins、Prometheus、Kong/Traefik、Airflow 等。
• 部署方式：
• 使用 k3s 管理所有服务，确保高可用性和扩展性。
• 为每个服务配置资源限制（CPU 和内存），避免资源争用。
• 使用持久化存储（如云盘或 Docker 卷）确保数据安全。

3. 服务架构

4. 成本估算

5. 优点

• 高性能：PolarDB 和 OSS 提供更高的性能和可用性。
• 可扩展性：k3s 集群支持灵活扩展，满足业务增长需求。
• 功能完整：恢复对关键服务的支持，提供完整功能。
• 成本可控：通过分阶段扩展，控制成本。

6. 注意事项

• 数据迁移：在迁移 MySQL 和 MinIO 时，确保数据的一致性和完整性。
• k3s 管理：熟悉 k3s 的基本操作，确保集群正常运行。
• 监控与日志：使用 Prometheus 和 Grafana 监控集群状态，集中管理日志。
• 备份策略：定期备份重要数据，确保数据安全。

四、备选方案：4 台 4C8G 自建集群

主线选 k3s 的原因：单管理面更省内存；4 台自建集群方案留给需要物理隔离或多环境隔离的场景，基于 Docker Swarm 编排，规划如下：

节点类型

1. 管理节点（4C8G）：用于部署 Swarm 管理节点、Traefik、Prometheus、GitLab 等核心服务。
2. 数据库节点（4C8G）：用于部署 MySQL、Redis、MongoDB、PostgreSQL 等数据库服务。
3. 业务节点1（4C8G）：用于部署 Elasticsearch、Kibana、RabbitMQ、Airflow 等应用服务。
4. 业务节点2（4C8G）：用于部署业务容器（PHP、Python、Golang、Java、Node.js）。

资源分配

管理节点（4C8G）

数据库节点（4C8G）

业务节点1（4C8G）

业务节点2（4C8G）

详细说明

1. 管理节点（4C8G）

• Swarm Manager：轻量级，用于管理 Docker Swarm 集群。
• Traefik：作为反向代理和负载均衡器，占用资源较少。
• Prometheus：用于监控集群，占用中等资源。
• GitLab：资源密集型，用于代码管理和 CI/CD。

2. 数据库节点（4C8G）

• MySQL：高性能关系型数据库，占用较多资源。
• Redis：高性能内存数据库，占用资源较少。
• MongoDB：高性能 NoSQL 数据库，占用较多资源。
• PostgreSQL：高性能关系型数据库，占用较多资源。

3. 业务节点1（4C8G）

• Elasticsearch：存储密集型搜索服务，占用较多资源。
• Kibana：轻量级可视化工具，占用资源较少。
• RabbitMQ：消息队列服务，占用中等资源。
• Airflow：任务调度工具，占用资源较少。

4. 业务节点2（4C8G）

• PHP、Python、Golang、Java、Node.js：业务容器，根据实际需求分配资源。

总结

整体节奏：初期单机 Docker 快速验证，中期按需恢复完整服务，后期迁移到 PolarDB + OSS + k3s 集群（约 ¥1200/月，见上文详表）；需要物理隔离或多环境隔离时，再评估 4 台 4C8G 自建集群的备选方案。分阶段推进的意义在于控制成本的同时逐步验证业务需求，确保业务的稳定性和可扩展性。

延伸阅读

• 微服务基础设施——单机 MVP 到迁云的节点规划
• 开发环境（asdf+docker）——开发环境里的集群实践