1.4 产品地图：COS、CI、CDN、SCF 各管什么

场景：五个产品摆在面前，谁干啥

决定上云之后，控制台里齐刷刷列着五个产品：对象存储 COS、数据万象 CI、内容分发网络 CDN、云函数 SCF、云监控。起初我把它们当一回事看，以为都要写大量代码对接，越看越焦虑——五个 SDK、五份文档、五套密钥，这活儿听着就头大。摸清了才发现，它们是流水线上的五个工位，各管一段，大部分配置在控制台点一点就生效，真正需要写代码的地方少得可怜。

这五个产品不是并列关系，而是接力关系：文件从上传到被下载，一路上每个产品接一棒。分清谁是存储、谁处理、谁加速、谁触发、谁盯盘，是后面所有章节能读下去的前提。这一篇先把地图画全，后面每一章都是对某个工位的展开。我在这张地图上花的两个小时的梳理，后来省去了团队新成员两天的问路时间，这笔时间投资非常划算。

还有一类产品我没放进地图，因为它们要么是可选项、要么被主线流程掩盖了：消息队列 CMQ 用在审核结果的异步回传上；API 网关负责给云函数的事件触发做一层防护；云数据库存的是元数据而不是文件。选产品有一条朴素的判断标准：凡是碰字节的，不是存就是传或者处理，就必有对应产品；只碰元数据的，用普通的数据库就行。本书只展开主线五件套，其余产品会在用到时顺带提及。

方案：一张分工图

我把五个产品的职责按文件的生命周期串起来，每个产品只负责自己那一段，职责重叠的地方恰恰是最容易出错的地方：

对应的官方文档入口，我浏览器书签里常年开着，调试问题时第一步就是来这里翻关键字。这几份文档的检索效率比搜索引擎高得多，尤其是报错码：

还有一个容易混淆的问题：同样的功能，什么时候用 COS 原生能力，什么时候交给 CI？我也列过一张表：

配置：它们之间的调用关系

CI 是架在 COS 之上的处理服务，很多功能是开通 CI 后在 COS 的桶配置里冒出来的，这正是很多人分不清两个产品的原因——你以为在配 COS，其实账单走的是 CI。它们之间的关系大致是这样，后端在整条链里只订阅最终结果：

// 上传完成后，SCF 被 COS 事件触发，调用 CI 的处理能力
// 后端只订阅最终结果，全程异步
触发源: COS 上传完成事件 (cos:ObjectCreated:*)
处理者: SCF 函数，读取元数据，按类型选择 CI 能力
执行者: CI 处理作业，图片走图片处理、视频走转码
观察者: 云监控，收集 SCF 运行时长与 COS 请求量

理解这条链之后，很多事情顺理成章：加个新文件类型预览，不用改后端，写个 SCF 函数处理新格式；想压缩存储成本，不用写定时任务，配 COS 生命周期规则自动转归档；图片想加水印，不用自己写图像库，CI 一个参数搞定。云产品之间的接缝比我想的紧，多数时候我写的是配置而不是代码，这也是 1.3 架构草图 里协调层能落到实处的原因——后端薄，是因为活儿都被云接走了。

踩坑：三个常混淆的概念

第一，CI 和 COS 的计费是分开的。CI 按处理次数和输出规格收费，开桶时顺手开了 CI 全部能力，结果一批用不到的审核和转码也在空转计费，月底一看账单多出莫名一项。用不到的能力不要开，需要时再开，开通是即时的，关掉却不退已经收过的钱。

第二，CDN 的缓存和 COS 的版本是两套时钟。文件更新后刷新 CDN 缓存有延迟，用户可能下到旧版本，而且这个旧版本可能在很多边缘节点上存活很久。重要文件我手动刷新，并且客户端下载时以文件指纹做版本号，从 URL 层面绕开缓存，这一招在 4.2 CDN 加速一节细讲。

第三，SCF 不保证只执行一次。同一个上传事件可能触发多次函数执行，函数必须设计成幂等的：用事件 ID 去重，重复执行不产生副作用。我在这上面吃过一次重复发通知的亏，同一个文件被处理了两遍，用户收到两条上传成功短信，排查了半天才发现是重试机制。

第四个坑是把监控当摆设。云监控开了但没配告警，出了事全靠用户反馈，等我去查的时候指标曲线已经过去好几小时，现场都凉了。监控的价值不在看大盘，在告警把人叫醒。后来我把告警按严重程度分了三档，分别发给值班群、个人微信和电话，这一点在 5.3 监控告警里展开成了一整套实践。

第五个坑是文档和控制台不同步。产品的控制台改版频繁，文档里的入口路径偶尔滞后，有一次我照着旧文档找了半小时的功能开关，最后在控制台的新位置摸到。养成一个习惯：找不到入口时先看文档顶部的版本时间，再看控制台是否有功能迁移提示，别和旧截图较劲。

再聊几句产品组合的常见误用。第一种误用是把 COS 当数据库使，往里塞结构化数据再做范围查询，每次列举都按请求次数计费，性能和成本双输。第二种误用是让 CDN 缓存用户私密内容，签名一旦被边缘节点缓存，权限体系就形同虚设。第三种误用是什么都往云函数里塞，一个简单的图片裁剪也要绕一次 SCF，徒增冷启动时延。每个产品都有它最舒服的位置，把它摆在错误的位置上，既浪费钱又抱怨产品不好用。

接着说回这幅地图本身。画完之后我把它打印出来贴在工位旁，每加一个云能力就更新一格，旁边标注对应的计费方式。时间久了，这张图变成了团队的成本地图：看一眼就知道每个功能的月度开销，评审新功能时顺带估算新增成本，再也没有出现过上线一个月才知道功能很贵的情况。技术决策一旦和成本绑定，讨论质量会肉眼可见地提高。

最后讲一个真实的小插曲。有一次 CI 转码作业全部失败，我在桶配置里翻了两个小时没头绪，最后发现是 CI 的开通授权过期需要重新绑定，而这条信息只在控制台一个不起眼的提示条里。从那以后，我把每个产品的开通状态、授权状态、计费状态做成了每月一次的巡检清单，五分钟扫一遍。云产品帮你省了运维，但没帮你省掉确认它还活着这件事，工具越先进，检查它的人越要勤快。这一切的根基，是先理解每个产品的边界，这正是本篇地图存在的意义。

顺带回答一个常被问的问题：全家桶是不是都要开？不是。我们团队真正每天依赖的是 COS 和 CI，CDN 只在公开分享多的月份才明显，SCF 只有三个函数在跑，云监控主要用来看额度。先用一两个把主链路跑通，再按需引入，这是我给所有人的建议。盲目开通用不到的产品，只会让账单和故障面同时变大。

新人文档我们写了一份一页纸产品对照表：每个产品一行，写着它管什么、不管什么、碰到问题找谁。新人入职第一天读这一页，第二天就能明白为什么图片压缩不归 COS 管。

产品边界踩得最狠的一次是把视频转码需求提给了 COS，沟通一圈才发现必须走 CI 的媒体处理。云端产品的文档体系庞大，读文档先读边界，这句话成了我们团队的学习口诀。

产品的地图感还会影响排期。知道每个能力属于哪个产品，估时就有了参照物：同类能力在别处值多少工时。我们的排期评审会上，产品地图是挂在墙上的常驻道具，比任何甘特图都管用，也是跨团队沟通的通用语言，值得每个新项目效仿，一页纸省下无数次解释。

小结

五个产品五种角色：COS 存、CI 处理、CDN 速、SCF 动、监控看。分清边界之后，写代码变成了画配置，上线速度比自建快了一个量级。后面每一章展开讲一个工位，读的时候随时回来看这张地图，就不会迷路。

给准备照做的读者一个落地顺序建议，不要一上来五个全配：先把 COS 桶建好跑通上传下载，这是骨架；然后加临时密钥把权限收紧，这是安全；再接 SCF 做回调处理，这是自动化；CDN 和监控等流量起来了再加，它们是加速器和仪表盘。一套系统不必第一天就完整，但第一天就必须正确——越是后加的组件，越容易因为兼容早期决定而别扭。我见过太多项目把监控留到最后，结果上线半年才发现某次故障的监控数据根本没采到，优化无从谈起。

延伸阅读

• 2.1 直传设计：客户端绕过后端
• 3.2 图片处理：CI 缩略图与水印
• 5.1 云函数回调：上传后处理与清理
• 腾讯云踩坑集合