💡 前置知识：会 docker run，知道 Kubernetes 大概是个什么东西（不知道也行，反正看完你也不一定想知道）

〇、灵魂拷问：用了 Vercel 为什么还要用 Sealos？

如果你和我一样，前端已经愉快地部署在 Vercel 上了——零配置、自动 CI/CD、全球 CDN、Preview Deployment 一气呵成——你一定会产生一个哲学级别的疑问：

"既然 Vercel 这么爽，我后端能不能也这么爽？"

答案是：不能。但 Sealos 能让你接近那种爽感。

让我用一张图解释为什么 Vercel 管不了你的后端：

Vercel 擅长的是前端资产 + 轻量 Serverless，但你的 Go 服务、数据库、消息队列、任务调度这些"脏活累活"，它压根不想管。你当然可以用各种 DBaaS（Neon、Upstash、Supabase），但当你的技术栈长成下面这个样子的时候：

Go + Gin + Go-zero + PostgreSQL + Redis + MongoDB + Kafka + ES + Asynq + ...

你需要的不是一堆零散的 SaaS，而是一个统一的后端运行平台。

这就是 Sealos 的价值所在——Vercel for Backend（我自己封的，Sealos 官方别来找我要广告费）。

分工明确：Vercel 管前端渲染和静态资源分发，Sealos 管后端服务和数据层。各自做各自擅长的事，架构清晰，钱也花在刀刃上。

一、Sealos 是什么？（正经介绍环节）

Sealos 是一个以 Kubernetes 为内核的云操作系统。

如果这句话让你觉得不明觉厉，我翻译成人话：

Sealos = 给 Kubernetes 套了一层"人类能用"的壳

1.1 核心定位

你不需要懂 kubectl，不需要写 Deployment YAML，不需要理解 Service、Ingress、PV/PVC 这些让人头大的概念——Sealos 把这些全部封装成了图形化操作。

1.2 产品形态

Sealos 有两种使用方式：

对于我们这种"先跑起来再说"的项目，公有云是最优解。

二、Sealos 的核心优势（吹一波）

2.1 数据库管理：真正的杀手级功能

这是我选择 Sealos 的最大原因，没有之一。

在 Sealos 上部署一个 PostgreSQL 有多简单？三步：

1. 打开"数据库"应用
2. 选 PostgreSQL，选配置（CPU/内存/存储）
3. 点"部署"

然后你就得到了一个带有以下能力的数据库实例：

• ✅ 自动备份（可配置周期）
• ✅ 一键恢复
• ✅ 监控面板（连接数、QPS、慢查询）
• ✅ 在线扩缩容（CPU/内存/存储）
• ✅ 连接字符串自动生成

同样的事情，如果你用裸 K8s 来做，你需要：

Redis、MongoDB、Kafka 同理。Sealos 在数据库这块确实做到了"用云数据库的体验，付开源自建的价格"。

2.2 按量计费：用多少花多少

不像传统云服务器按月包年，Sealos 公有云是按实际资源使用量计费：

• CPU 按核时
• 内存按 GB 时
• 存储按 GB 天
• 网络按流量

这意味着你的开发环境可以在不用的时候缩到最小甚至暂停，晚上和周末不烧钱。对创业团队来说，这个模型非常友好。

2.3 应用部署：丝滑但有限度

部署一个容器化应用的流程：

你甚至不需要自己配置域名和 SSL 证书，Sealos 会自动分配一个 xxx.cloud.sealos.run 的域名并配好 HTTPS。

2.4 一句话总结优势

三、如何使用 Sealos（实操篇）

3.1 注册与准备

1. 访问 cloud.sealos.run
2. 注册账号（支持 GitHub/微信登录）
3. 充值（支持支付宝/微信，最低 10 块就能玩）

3.2 部署数据库（以 PostgreSQL 为例）

关键配置建议：

# 你的 Go 服务配置文件
database:
  host: "xxx.cloud.sealos.run"    # Sealos 分配的内网地址
  port: 5432
  user: "your_user"
  password: "your_password"        # 从 Sealos 控制台获取
  dbname: "your_db"
  sslmode: "require"               # 公网访问务必开启
  max_open_conns: 20               # 初期 20 够用
  max_idle_conns: 5

3.3 部署 Go 服务

第一步：准备 Dockerfile

FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o server ./cmd/server

FROM alpine:3.19
RUN apk --no-cache add ca-certificates tzdata
ENV TZ=Asia/Dubai
WORKDIR /app
COPY --from=builder /app/server .
COPY --from=builder /app/configs ./configs
EXPOSE 8080
CMD ["./server"]

第二步：构建并推送镜像

# 推送到 Docker Hub 或任何公开/私有镜像仓库
docker build -t yourusername/your-service:v1.0.0 .
docker push yourusername/your-service:v1.0.0

第三步：在 Sealos 控制台部署

进入「应用管理」→「新建应用」→ 填入：

• 镜像地址：yourusername/your-service:v1.0.0
• CPU：0.5 核（初期够用）
• 内存：512MB
• 端口：8080
• 副本数：1
• 环境变量：数据库连接信息等

点击部署，等待 30 秒，你的服务就上线了。

3.4 Vercel 前端对接 Sealos 后端

// Vercel 环境变量设置
// .env.production
NEXT_PUBLIC_API_BASE_URL=https://your-app.cloud.sealos.run

// API 调用示例
const api = axios.create({
  baseURL: process.env.NEXT_PUBLIC_API_BASE_URL,
  timeout: 10000,
});

在 Vercel 项目设置 → Environment Variables 中配置 NEXT_PUBLIC_API_BASE_URL 指向你的 Sealos 后端地址即可。

四、踩坑指南（放弃的艺术）

🕳️ 坑 1：内网互访的迷惑行为

Sealos 上同一命名空间的服务之间互访，用的是 K8s 内部 DNS：

# 格式：<service-name>.<namespace>.svc.cluster.local
# 但 Sealos 的命名空间是按用户隔离的，名字很迷幻
your-service.ns-abc123.svc.cluster.local

坑点：你可能想当然地用了外部域名（xxx.cloud.sealos.run）让服务之间互相调用——这会导致流量绕一圈公网再回来，延迟翻倍，还会产生额外的流量费用。

正确做法：服务间通信一律用内网地址。在 Sealos 控制台查看每个服务的内网访问地址。

🕳️ 坑 2：存储持久化的"惊喜"

Sealos 默认给你的是临时存储。如果你的服务需要持久化文件（比如上传的文件、日志文件），你必须手动挂载存储卷。 否则容器重启后数据直接消失，你连哭的地方都没有。

建议：数据库之外的文件存储，用 Sealos 的对象存储（类似 S3），别依赖本地文件系统。

🕳️ 坑 3：冷启动与健康检查

如果你的 Go 服务启动需要初始化数据库连接、加载配置等操作，默认的健康检查可能会在你的服务还没完全启动时就判定它"不健康"，然后 K8s 会不断重启它，形成死循环。

解决方案：配置合理的启动探针（startupProbe）：

# 给服务足够的启动时间
startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 10    # 等 10 秒再开始检查
  periodSeconds: 5           # 每 5 秒检查一次
  failureThreshold: 12       # 允许失败 12 次（共 60 秒启动时间）

在 Sealos 控制台的高级设置中可以配置这些参数。

🕳️ 坑 4：资源限制的"温柔一刀"

你设置了 CPU 0.5 核，内存 512MB，以为是"最低保障"？不，那是硬上限。 超了就会被 OOMKilled（内存溢出被杀）或 CPU 限流。

初期建议：

特别注意：Go 服务默认会使用所有可见的 CPU 核心来设置 GOMAXPROCS，但在容器里它看到的是宿主机的核心数。建议在代码中引入 automaxprocs：

import _ "go.uber.org/automaxprocs"  // 自动根据容器 CPU 限制设置 GOMAXPROCS

🕳️ 坑 5：自定义域名与 CORS

Vercel 前端域名是 your-app.vercel.app，Sealos 后端是 your-api.cloud.sealos.run——跨域问题必然出现。

// Gin CORS 配置
func CORSMiddleware() gin.HandlerFunc {
    return func(c *gin.Context) {
        c.Header("Access-Control-Allow-Origin", "https://your-app.vercel.app")
        c.Header("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS")
        c.Header("Access-Control-Allow-Headers", "Content-Type, Authorization")
        c.Header("Access-Control-Allow-Credentials", "true")

        if c.Request.Method == "OPTIONS" {
            c.AbortWithStatus(204)
            return
        }
        c.Next()
    }
}

后续绑定自定义域名后，记得同步更新 CORS 配置。

🕳️ 坑 6：日志收集的"真空地带"

Sealos 控制台能看到实时日志（kubectl logs 的封装），但是：

• 不支持日志持久化（容器重启后日志丢失）
• 不支持日志搜索（没有 ELK/Loki 那种全文搜索）
• 不支持多容器日志聚合

初期方案：让 Go 服务把关键日志同时写到 PostgreSQL 的日志表里。虽然土，但有效。后续 Phase 2 再上 ELK 或 Loki。

// Zap 多输出配置
core := zapcore.NewTee(
    zapcore.NewCore(encoder, zapcore.AddSync(os.Stdout), level),  // 标准输出（Sealos 控制台可见）
    zapcore.NewCore(encoder, zapcore.AddSync(dbWriter), level),   // 写入数据库（持久化）
)
logger := zap.New(core)

🕳️ 坑 7：数据库连接数的隐形炸弹

Sealos 托管的 PostgreSQL 默认 max_connections 不高（通常 100 左右）。如果你的 Go 服务没有配 pgbouncer，连接池设置又过大，很容易打满。

Phase 0 建议：Go 服务端的 max_open_conns 设 20，max_idle_conns 设 5。够用了，别贪。

五、演进式架构：我的实战规划

"先活下来，再活得好"——这是我做技术选型的第一原则。下面是我项目从上线到规模化的完整演进路线。

5.1 全局架构演进图

5.2 Phase 0：MVP 最小可用版

目标：用最少的组件跑通核心业务，快速上线验证。

核心原则：PostgreSQL 能干的事，全让 PostgreSQL 干。

PG 替代方案详解：

资源与成本：

5.3 Phase 1：微服务拆分

触发条件：

• ✅ 有了付费用户
• ✅ 单体代码超过 5 万行，改一个功能怕影响全局
• ✅ 需要多人协作开发不同模块

关键决策：Go-zero 服务发现用 K8s 原生模式，不部署独立 Etcd。

# go-zero K8s 服务发现配置
# 省掉 3 节点 Etcd 集群 = 省 1.5C3G = 省 ¥200+/月
UserRpc:
  Target: k8s://ns-your-namespace/user-rpc-svc:9000

新增组件：

资源与成本：~8C / 16GB，月费约 ¥600-1000

5.4 Phase 2：规模化

触发条件：

• ✅ 日活过千
• ✅ 数据量 PG 单表超百万
• ✅ 出现性能瓶颈

新增组件：

资源与成本：~16C / 32GB，月费约 ¥1200-2000

5.5 Phase 3：平台化（终态）

六、成本对比：Sealos vs 传统云

以 Phase 0（MVP）为例：

省了 69%。 这不是抠门，这是理性消费（自我安慰.jpg）。

七、总结：该入门还是该放弃？

入门的理由：

• 数据库托管体验拉满，对得起"云操作系统"的名号
• 按量计费对初创极其友好
• 零 K8s 知识门槛，鼠标点点就能部署
• Vercel + Sealos 组合拳是前后端分离项目的甜蜜点

想放弃的时刻：

• 复杂网络策略配置时会怀念裸 K8s 的灵活性
• 日志和监控方案相对简陋，需要自己补全
• 遇到问题时文档和社区不如主流云厂商成熟
• 私有化部署的运维坡度还是不小

最终结论：

Sealos 不是银弹，但它是当前中小项目在"自建 K8s 太重"和"云厂商太贵"之间，最优的平衡点。

先入门，用到放弃那天再说。反正到那时候，你的项目大概率已经有钱换更好的方案了。 😏

「从入门到放弃」系列 —— 用最真诚的态度，写最不负责任的技术文章。