运维与集成
这一课你将能做到
- 配置 GitHub Actions 实现代码推送后自动部署 Worker
- 使用 Workers Analytics、Logpush、Tail 日志构建可观测体系
- 集成 Pages Functions、Service Bindings、Cron Triggers 构建完整应用
为什么要学
写完代码只是开始。真正的工程化需要：代码推送自动部署、线上错误实时告警、性能数据可视化、定时任务自动执行。没有这些，你的 Worker 就是「能跑但不敢上生产」的玩具。
人话：运维与集成就是把「开发环境能跑」变成「生产环境稳定跑」。CI/CD 让你每次 git push 自动上线；监控让你第一时间知道哪里挂了；Service Bindings 让多个 Worker 像微服务一样互相调用；Cron Triggers 让你能跑定时任务。
先建立图像
开发工作流:
[git push] ──> [GitHub Actions] ──> [wrangler deploy] ──> [生产环境]
│
├──> [部署到 staging]
└──> [部署到 production]
可观测体系:
[Worker 运行] ──> [console.log] ──> [wrangler tail / Logpush]
│
├──> [Datadog / Sentry]
└──> [BigQuery / R2]
应用集成:
[Pages Functions] <──> [Service Bindings] <──> [其他 Worker]
│ │
└──> [KV / D1 / R2 / Queue] <──────────────┘
定时任务:
[Cron Trigger] ──> [每天 0 点] ──> [清理过期数据 / 生成报表]
跟着做
步骤 1：GitHub Actions 自动部署
创建 .github/workflows/deploy.yml：
name: Deploy Worker
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- run: npm ci
- name: Deploy
uses: cloudflare/wrangler-action@v3
with:
apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
在 GitHub Repo → Settings → Secrets 中添加 CLOUDFLARE_API_TOKEN 和 CLOUDFLARE_ACCOUNT_ID。
步骤 2：多环境部署
- name: Deploy to Staging
if: github.ref == 'refs/heads/develop'
uses: cloudflare/wrangler-action@v3
with:
apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
command: deploy --env staging
- name: Deploy to Production
if: github.ref == 'refs/heads/main'
uses: cloudflare/wrangler-action@v3
with:
apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
command: deploy --env production
步骤 3：配置 Logpush 导出日志
Dashboard → Workers & Pages → 你的 Worker → Logs → Logpush：
- 目的地：R2 / Datadog / S3 / BigQuery
- 字段：选择
@timestamp、message、level、url
- 过滤：
level >= error（只导出错误日志）
步骤 4：Service Bindings 调用其他 Worker
[[services]]
binding = "AUTH_SERVICE"
service = "auth-worker"
environment = "production"
export interface Env {
AUTH_SERVICE: Fetcher;
}
export default {
async fetch(request: Request, env: Env): Promise<Response> {
// 直接调用另一个 Worker，不经过公网
const authResponse = await env.AUTH_SERVICE.fetch('https://auth/verify', {
method: 'POST',
headers: request.headers,
});
if (!authResponse.ok) {
return new Response('Unauthorized', { status: 401 });
}
return new Response('OK');
},
} satisfies ExportedHandler<Env>;
步骤 5：Cron Triggers 定时任务
[triggers]
crons = ["0 0 * * *"] # 每天 0 点（UTC）
export default {
async scheduled(event: ScheduledEvent, env: Env, ctx: ExecutionContext): Promise<void> {
// 清理 30 天前的日志
await env.DB.prepare('DELETE FROM logs WHERE created_at < ?')
.bind(Date.now() - 30 * 24 * 3600 * 1000)
.run();
// 生成日报
const report = await generateDailyReport(env);
await env.REPORT_QUEUE.send(report);
},
} satisfies ExportedHandler<Env>;
步骤 6：Pages Functions 与 Next.js 集成
Pages Functions 允许你在 Cloudflare Pages 上运行 Worker 代码。适合把 Next.js 的 API Routes 迁移到边缘：
// functions/api/hello.ts
export const onRequest: PagesFunction = async (context) => {
return Response.json({ message: 'Hello from Pages Functions!' });
};
部署后，https://your-site.pages.dev/api/hello 就能访问。
讲清楚要点
- CI/CD 是工程化的基础：手动
wrangler deploy 适合学习，生产环境必须自动化。GitHub Actions + Wrangler Action 是官方推荐方案。
- 多环境隔离：staging 和 production 用不同的
wrangler.toml 配置（不同的数据库、KV、队列），通过 --env 参数切换。
- Service Bindings 是内部调用：不经过公网，延迟更低、更安全。适合微服务架构：auth-worker、api-worker、notification-worker 互相调用。
- Cron Triggers 有精度限制：最小粒度是 1 分钟，且可能有几秒延迟。不适合秒级定时任务。
- Logpush 是生产必备：
console.log 只适合本地调试。生产环境用 Logpush 导出到专业日志平台（Datadog、Sentry、BigQuery），支持告警、分析、长期存储。
你可能会懵的地方
-
GitHub Actions 的 API Token 怎么生成？
Dashboard → My Profile → API Tokens → Create Token → Edit Cloudflare Workers 模板。权限：Account.Workers Scripts:Edit、Account.Workers Routes:Edit。
-
Service Bindings 和直接 fetch 有什么区别？
Service Bindings 走 Cloudflare 内部网络，不经过公网，延迟更低（<1ms vs 几十 ms），且不产生外部请求费用。直接 fetch 会走公网，有延迟和费用。
-
Cron Triggers 错过了执行时间怎么办？
Cloudflare 会尽量补执行，但不保证。关键任务建议用 Queues + 定时检查，确保至少执行一次。
-
Pages Functions 和 Workers 怎么选？
Pages Functions 适合「静态站点 + 少量 API」的场景（如博客评论、表单提交）；Workers 适合「纯 API 服务」的场景。Pages Functions 可以访问 KV、D1、R2，但功能比 Workers 少。
-
怎么监控 Worker 的性能？
Dashboard → Workers & Pages → 你的 Worker → Metrics。可以看到请求数、错误率、CPU 时间、内存使用。也可以集成第三方 APM（如 Datadog、New Relic）。
错法对照
| 错法 | 问题 | 正解 |
|---|
生产环境手动 wrangler deploy | 容易出错，无审计记录 | 用 GitHub Actions 自动部署 |
| 在代码里硬编码环境差异 | 部署到错误环境 | 用 wrangler.toml 的 [env.xxx] 隔离 |
用 console.log 做生产日志 | 无法检索、无告警、有性能开销 | 用 Logpush 导出到专业平台 |
用 fetch 调用同账号的其他 Worker | 走公网，延迟高、有费用 | 用 Service Bindings 内部调用 |
| Cron 表达式写错导致任务不执行 | 任务静默失败 | 用 crontab.guru 验证表达式；加日志确认执行 |
卡点急救
- GitHub Actions 部署失败
Authentication error：检查 API Token 权限是否足够；检查 Token 是否过期；检查 Account ID 是否正确。
- Service Bindings 返回 404：检查
service 和 environment 是否匹配目标 Worker 的部署；检查目标 Worker 是否已部署到对应环境。
- Cron Triggers 不执行：检查
crons 表达式格式；检查 Worker 是否已部署；用 Dashboard 的「触发器」面板查看下次执行时间。
面试常问
-
Workers 的 CI/CD 最佳实践？
GitHub Actions + Wrangler Action 自动部署；多环境隔离（staging/production）；部署前跑类型检查和单元测试；部署后自动跑冒烟测试。
-
Service Bindings 的底层原理？
基于 Cloudflare 的内部服务发现机制。两个 Worker 在同一个 Account 下，通过 Service Binding 建立直接的网络连接，不经过公网，延迟极低。
-
怎么实现 Worker 的蓝绿部署？
用 wrangler deploy --env blue 和 wrangler deploy --env green 部署两个版本，通过 Cloudflare Load Balancer 或 Worker 路由切换流量。验证无误后下线旧版本。
自测三问
- 为什么生产环境要用 GitHub Actions 而不是手动部署？
- Service Bindings 和直接
fetch 调用其他 Worker 的核心区别是什么？
- 如果要在每天凌晨 3 点清理过期数据，你会怎么配置 Cron Trigger？
小结一句话
运维与集成是 Workers 工程化的最后一公里：CI/CD 自动化部署、Logpush 构建可观测体系、Service Bindings 实现微服务通信、Cron Triggers 处理定时任务，四者结合让边缘应用真正具备生产级能力。
延伸