1.2 选型方法论与成本权衡

1.2 选型方法论与成本权衡

本节摘要：理解了分层之后，面对一个具体需求怎么选出合适的产品？本节给出一套可操作的选型方法论：先定层（用 IaaS 自建还是用 PaaS 托管），再在同层产品间比较，最后权衡成本和运维代价。成本核算是重点——很多人只看单价（这台 CVM 多少钱一小时），忽略了运维人力、故障损失、扩展成本这些隐性代价，结果选了看似便宜实则总账更贵的方案。本节讲怎么算总账，以及"自己管"和"托管服务"在不同规模下的成本交叉点。

学习目标

阅读完本节，你应当能够：

1. 用"先定层、再比产品、后权衡成本"三步法做选型
2. 列出选型要考虑的几个核心维度（成本、运维、灵活性、可靠性、性能）
3. 说明隐性成本（运维人力、故障损失）怎么影响总账
4. 理解"自建"和"托管"的成本随规模变化的交叉点
5. 避免几个常见的选型陷阱（过度设计、只看单价、忽视迁移成本）

问题与直觉

假设你的团队要部署一个新服务。技术选型会上，有人主张"用 CVM 自己装 MySQL，便宜"，有人主张"用托管 TDSQL，省事"。谁对？

答案是：看规模和团队能力。如果是个小项目、团队里有懂 MySQL 运维的人，自建可能够用且省钱。但如果业务会长大、团队没有专职 DBA，托管的 TDSQL 虽然单价贵些，但省下的运维人力和避免的故障损失，总账可能更划算。

这类决策在云上天天发生，而且很多人做错——要么过度设计（小项目用了企业级高配方案，浪费钱），要么只看单价（选了便宜的自建方案，结果运维踩坑、故障频发）。问题出在没有一套系统方法，凭感觉选。本节就是把选型这件事拆成可操作的步骤。

核心原理

2.1 选型三步法

我把选型拆成三步，按顺序做：

第一步：定层。先决定用哪层。判断标准是"我愿意自己管多少"。如果想快速上线、不想运维某个组件，优先找它的 PaaS 托管服务；如果需要特殊定制（特定版本的中间件、特定的内核参数）或者托管服务满足不了，退回 IaaS 自建；如果是通用需求且有成品应用，直接用 SaaS。

第二步：比产品。定了层之后，同层往往有多个候选产品。比如存储有对象存储 COS、文件存储 CFS、块存储 CBS——都"存数据"，但访问方式和场景不同（后面章节细讲）。这一步是横向对比候选产品的性能、可靠性、功能、价格。

第三步：权衡成本总账。这一步最容易被忽略，也最容易踩坑。不能只看产品的标价，要算总账（下面专门讲）。

2.2 选型的核心维度

对比候选产品时，从这几个维度看：

这几个维度往往冲突——高可靠的方案通常更贵，高灵活的通常运维更累。没有全维度最优的产品，要根据自己的优先级排序。

2.3 成本总账怎么算

这是选型里最关键的认知：标价不等于总成本。一个产品的总账包括三部分：

显性价格：产品本身的计费。CVM 按小时计费、COS 按 GB 月存储费加请求费、TDSQL 按实例规格。这部分容易查到，但要注意计费维度（有些产品有隐藏的请求费、流量费）。

隐性运维成本：自己管的组件需要人力运维——装、配、监控、升级、排障。一个自建 MySQL 集群，至少需要一个兼职 DBA 的精力。托管 TDSQL 把这部分省了，但多收的服务费本质上就是"花钱买运维"。

故障损失：可靠性低的方案出故障时损失大。自建数据库如果没做好高可用，宕机几小时可能造成业务损失远超省下的钱。托管服务的高可用是厂商背书的，这部分风险被转移。

举个具体例子对比"自建 MySQL on CVM"和"托管 TDSQL"，假设中等规模业务：

在人力成本高的地区（一线城市工程师贵），托管的隐性节省明显；在人力便宜或团队有富余运维能力时，自建的显性节省更实在。

工程实践要点

3.1 自建与托管的成本交叉点

自建和托管哪个划算，强烈依赖规模。一般规律：

小规模：托管划算。托管服务的溢价分摊到少量实例上不多，而自建需要固定投入运维精力（不管跑多少实例都要管）。小项目用托管，省心又省钱。

大规模：自建可能反超。规模大了之后，托管的溢价累加成巨款，而自建的运维精力可以摊薄（一套运维流程管几百个实例）。这就是为什么大厂（Netflix、字节）很多组件自建——规模大到自建更经济。

这个交叉点在哪没有固定答案，取决于具体产品、人力成本、故障容忍度。但判断方向是清楚的：业务还在验证期或规模不大，用托管；业务跑通且规模大了、有专职运维团队，再考虑自建。

💡 关键直觉：别为了"省那点托管费"而过早自建。我见过很多创业团队一上来就自建 MySQL、Redis、消息队列，理由是"省钱"，结果业务没跑起来，光运维踩坑就耗掉几个月，核心业务反而没精力做。先用托管把业务跑通，等规模和收入证明自建划算时再迁移，这是更稳的路径。

3.2 几个常见选型陷阱

过度设计：小项目用了企业级方案。比如一个内部工具，用了个三可用区高可用、多副本的企业级数据库——配置远超需求，钱白花。先评估真实需求（这个服务挂了影响多大、能容忍多久恢复），按需选配，别盲目上高配。

只看单价：只比 CVM 每小时多少钱，忽略网络流量费、请求费、存储费这些附加成本。有些产品单价低但附加费高（比如对象存储的请求费在频繁访问场景累加惊人）。算总账要把所有计费维度加起来。

忽视迁移成本：选了一个方案，用了发现不合适想换，结果数据迁移、代码改造代价巨大。尤其要警惕强锁定方案——数据导出难、API 是私有的，换厂商成本极高。优先选兼容标准的方案（MySQL 协议、K8s 标准、S3 兼容的对象存储）。

盲目追新：云厂商常推新产品，听起来很先进。但新产品稳定性、文档、社区案例都不如成熟产品。生产环境优先用成熟稳定的产品，新产品先在非核心场景试。

# 概念性：选型决策记录模板
class SelectionDecision:
    def __init__(self, requirement):
        self.requirement = requirement
        self.layer = None          # IaaS / PaaS / SaaS
        self.candidates = []       # 候选产品列表
        self.dimensions = {}       # 各维度评分
        self.total_cost = {}       # 总账分解
        self.choice = None
        self.reason = ""           # 为什么这么选

    def evaluate(self):
        # 1. 定层
        self.layer = self._decide_layer()
        # 2. 比产品（各维度打分）
        for p in self.candidates:
            self.dimensions[p] = self._score(p)
        # 3. 算总账
        for p in self.candidates:
            self.total_cost[p] = self._compute_total(p)
        # 4. 综合决策
        self.choice = self._decide()
​

3.3 预留弹性，避免锁死

选型时还要考虑"未来怎么变"。业务会长大、需求会变、厂商可能涨价或停服。几个做法降低未来被动：

数据可导出：选的产品要能方便导出数据到标准格式。数据库要支持标准协议导出，对象存储要兼容标准 API。这样想迁移时有路可走。

架构解耦：业务代码尽量通过抽象层访问云服务（比如用标准库而非厂商私有 SDK），换厂商时改动小。

多云准备：关键业务可以考虑多云部署或至少保留多云迁移能力，避免单一厂商风险。但这会增加复杂度，要权衡。

⚠️ 常见坑：Serverless 类产品（云函数 SCF）的迁移成本容易被低估。它的运行模型（事件触发、冷启动、执行时长限制）和传统服务差别大，一旦深度用了，迁移到别的方案（CVM 或容器）要重写很多逻辑。用之前想清楚：这个功能会不会长大到需要迁出 Serverless 模型？如果会，从一开始就用更通用的方案可能更稳。

要点沉淀

• 选型三步法：先定层（IaaS/PaaS/SaaS）、再比产品、后权衡成本总账。
• 核心维度有六个：性能、可靠性、成本、灵活性、生态、迁移成本，往往冲突，按优先级排序。
• 标价不等于总成本：总账包括显性价格、隐性运维人力、故障损失风险三部分，后两部分常被忽略。
• 自建和托管有成本交叉点：小规模托管划算（运维摊不开），大规模自建可能反超（运维摊薄），别为省钱过早自建。
• 避免四个陷阱：过度设计、只看单价、忽视迁移成本、盲目追新。
• 预留弹性：数据可导出、架构解耦、必要时多云准备，避免被锁死。
• Serverless 迁移成本易被低估：用之前想清楚功能会不会长大到需要迁出。

下一章我们进入具体产品，从最底层的 IaaS 开始——计算、存储、网络这些底层资源类产品怎么选怎么用。

算总账的两个实例演练

把方法论落到两个具体决策上，体感会更实在。第一个例子：一个日活五万的社区站，图片存储选对象存储还是自建分布式存储。对象存储单价看似比自建贵，但总账要算三笔：自建至少要一个工程师的百分之三十精力管硬盘故障、扩容和数据冗余（人力成本折算每月数千到上万）；自建集群的可用性大概率到不了对象存储的十一个九（丢图事故的商誉损失）；对象存储还能直接挂 CDN 加速，自建要另搭。三笔加完，除非规模大到 PB 级且流量成本占比畸高，托管几乎总是赢。第二个例子反着来：一家视频公司每天转码十万小时素材，用云转码的月账单是自建转码集群的三倍——因为转码是纯计算密集、调度逻辑自己有、机器可以买断跑满，这个场景自建反超。两条判据浮出来：运维复杂度高、规模小，往托管靠；计算密集、利用率能打满、已有专业团队，自建有翻身机会。

收获清单

（上面三步法和六个维度的完整清单见前文，这里补三条实操提醒。）选型文档别写"最终选 X"，要写"在 A、B、C 三个前提下选 X"——前提变了结论自动失效，后来者能判断要不要推翻重来。二，给每个关键服务设一个"迁移演练日"：每半年实际导出一次数据、跑一次备用方案的冒烟测试，纸上谈兵的可替换性不算数。三，把云账单纳入周会：成本漂移（实例忘了关、存储只增不减、预留实例到期转按量）是渐进式的，等月度账单炸了才发现就晚了。