2、架构决策入门：什么是架构？架构决策对产品的影响（性能、稳定性、维护成本）

好，咱们正式开始聊架构。很多产品经理一听到「架构」两个字，就觉得是程序员的事，离自己很远。其实不然。我个人的习惯是，把架构理解成「产品的骨架」。你想想看，一个人没有骨架，肉是立不起来的。产品也一样，没有合理的架构，功能再多也是空中楼阁。

说白了，架构就是一套有意识的、提前做好的设计决策。它决定了系统里各个模块怎么分工、怎么通信、怎么容错。你可能会问：「这东西跟我产品经理有什么关系？」关系大了。我见过太多产品，功能设计得天花乱坠，结果上线后一用就崩，或者改个需求要花三个月。根子往往就出在架构上。

2.1 架构的本质：约束与权衡

什么是架构？我自己的定义很简单：架构是在一系列约束条件下，对系统结构做出的关键性决策。这些约束条件包括：

• 业务约束：用户量多大？数据量多大？峰值流量多少？
• 技术约束：团队擅长什么语言？现有系统是什么？
• 时间约束：多久必须上线？
• 成本约束：服务器预算多少？运维人力多少？

架构决策，本质上就是在这些约束里做权衡。没有完美的架构，只有最合适的架构。

举个例子。我在项目中遇到过一款社交产品，初期为了快速上线，团队选择了「单体架构」。所有功能写在一个代码库里，部署在一台服务器上。这个决策在当时是对的，因为用户量小，团队只有3个人。但后来用户涨到100万，单体架构扛不住了——改一个功能要全量发布，出一次故障影响所有用户。这就是典型的「架构债」。

2.2 架构决策对产品性能的影响

性能，是用户最直观的感受。页面加载慢、接口超时、视频卡顿，这些都是性能问题。架构决策直接影响性能，我挑三个最典型的点来说：

2.2.1 读写分离

很多产品初期只有一个数据库，读和写都走同一个库。用户少的时候没问题，用户一多，读请求就把数据库拖垮了，写操作也跟着变慢。这时候架构上就要做读写分离：主库负责写，从库负责读。

// 伪代码示例：读写分离的配置
// 主库：处理写操作（insert, update, delete）
master_db = new Database("master_host:3306")

// 从库：处理读操作（select）
slave_db = new Database("slave_host:3306")

// 业务代码中区分
function createOrder(orderData) {
    return master_db.insert("orders", orderData)  // 写操作走主库
}

function getOrder(orderId) {
    return slave_db.select("orders", orderId)     // 读操作走从库
}

这个决策对产品的影响是什么？读性能提升数倍，但数据一致性会有一点点延迟。你想想看，用户刚下完单，刷新页面没看到订单，可能就是因为读到了从库，而主库的数据还没同步过来。产品经理需要知道这个「坑」，在用户体验上做补偿，比如加个「订单处理中」的状态提示。

2.2.2 缓存策略

缓存是提升性能的「银弹」，但用不好也是「毒药」。我记得有个电商项目，团队把所有商品详情都缓存了，结果运营改了个价格，用户看到的还是旧价格，投诉电话被打爆。

架构上常见的缓存策略有：

策略	说明	性能影响	产品注意点
Cache-Aside	先读缓存，缓存没有就读数据库，再回写缓存	读性能高，写性能一般	缓存失效时，瞬间压力会打给数据库
Write-Through	写数据时同时写数据库和缓存	写性能略低，但数据一致性高	适合对数据一致性要求高的场景
Write-Behind	先写缓存，异步写数据库	写性能极高，但有丢数据风险	适合日志、点赞等非关键数据

嗯，这里要注意：缓存不是万能的。产品经理在提需求时，如果涉及到「实时性」要求很高的数据（比如库存、余额），一定要跟技术团队确认缓存策略，否则上线后就是事故。

2.3 架构决策对稳定性的影响

稳定性，说白了就是「系统别挂」。我见过最惨的一次，是某直播平台做秒杀活动，架构上没做限流，结果瞬间流量把整个集群打崩了，活动挂了2小时，损失几百万。

架构上保障稳定性的常见手段：

• 限流：控制单位时间内的请求量，防止系统被冲垮。
• 降级：非核心功能暂时关闭，保证核心功能可用。
• 熔断：当某个服务连续失败时，直接切断调用，避免雪崩。
• 冗余部署：多机房、多实例，一台挂了另一台顶上。

举个例子。假设你的产品有个「导出报表」功能，数据量很大，导出一次要跑5分钟。如果架构上不做异步处理，用户点一下导出，服务器就卡住5分钟，其他用户都进不来了。这就是稳定性问题。正确的做法是：把导出任务丢到消息队列里，后台慢慢跑，用户收到通知后再下载。这个决策，产品经理需要懂，因为你要在需求文档里明确「导出是异步的，用户需要等待通知」。

2.4 架构决策对维护成本的影响

维护成本，是产品上线后最容易被忽视的「隐形杀手」。很多产品经理只关心「上线」，不关心「上线后怎么改」。结果呢？每次改需求，技术团队都要加班，改一个字段要动10个文件，测试要回归3天。

架构决策对维护成本的影响，主要体现在：

• 模块化程度：模块之间耦合度高不高？改一个功能会不会影响其他功能？
• 扩展性：加一个新功能，需要改多少现有代码？
• 可测试性：能不能单独测试某个模块？还是必须全量回归？
• 可观测性：出问题时，能不能快速定位到是哪个模块的问题？

我建议产品经理在评审技术方案时，多问一句：「如果三个月后我们要加一个XX功能，这个架构需要改多少？」如果技术团队回答「要改很多」，那就要警惕了。这往往意味着架构的扩展性不好，未来的维护成本会很高。

我曾经参与过一个后台管理系统，初期为了省事，所有业务逻辑都写在一个「万能Service」里。结果呢？后来要加一个「权限控制」功能，发现每个方法都要改，改了整整两周，还改出了好几个bug。这就是典型的「架构债」——前期省下的时间，后期要加倍还回去。

2.5 总结：产品经理需要关注的三个架构问题

好了，说了这么多，你可能觉得有点抽象。我帮你提炼一下，作为产品经理，你在跟技术团队讨论架构时，只需要关注三个核心问题：

1. 性能：这个架构能支撑多少用户？峰值流量下会不会慢？
2. 稳定性：如果某个服务挂了，整个系统会崩吗？有没有降级方案？
3. 维护成本：以后改需求方便吗？加一个新功能要多久？

这三个问题，就是架构决策对产品最直接的影响。你不需要懂每一行代码怎么写，但你需要知道每个决策背后的「代价」是什么。记住：架构没有银弹，只有权衡。而产品经理，就是那个帮团队做出「最不坏」权衡的人。

下一章，我会带你深入聊一聊「常见的架构模式：单体、微服务、Serverless」，看看它们各自适合什么场景，以及产品经理该怎么选。咱们到时候见。