大家好，我是小富。

《十万个why》系列持续更新中

这个问题知乎上讨论过很多次，但大部分回答都在列能力清单：要懂分布式、要懂中间件、要懂设计模式、要有全局视野……说得都对，但等于没说。

我自己从写 CRUD 到开始参与系统架构设计，中间踩过不少坑，也见过不少技术很强但始终做不了架构决策的人。总结下来，写代码和做架构之间差的不是某几项具体技术，而是思维方式完全不同。

写代码是在解题，做架构是在出题

普通开发拿到的是一个明确的任务：这个接口的入参是什么、出参是什么、业务规则是什么，写完跑通测试就行。本质上是在解一道别人出好的题。

架构师面对的是一个模糊的问题：系统要支撑未来一年的业务增长，怎么设计？没有标准答案，没有明确的输入输出，你得自己定义问题的边界，自己拆解子问题，自己选方案，还得说服别人你的方案是合理的。

这两件事对能力的要求差别非常大。

写代码考验的是把一个确定的逻辑翻译成机器能执行的指令，这件事做多了会越来越熟练。但做架构考验的是在信息不完整的情况下做决策，而且要为这个决策的后果负责。很多人写了十年代码依然做不了架构，不是技术不够，是从来没有练过在模糊条件下做判断的能力。

只见树木不见森林

大部分开发者的日常工作范围就是自己负责的那几个模块。订单模块的人知道订单怎么建、怎么改、怎么查，但不清楚库存服务的扣减策略，不了解支付回调的重试机制，更不知道物流系统的对接方式。

在自己的模块里你是专家，但跳出来看整个系统的数据流转、服务依赖、性能瓶颈在哪，很多人是说不清楚的。

架构师必须能说清楚。

一个请求从用户点击按钮开始，经过网关、到哪个服务、查了哪些库、调了哪些下游、哪些是同步哪些是异步、哪些环节可能超时、超时了怎么降级——这条链路上的每个节点他不需要能写出具体代码，但必须知道它是怎么运转的、瓶颈在哪里。

这种全局视角不是靠看架构图就能获得的，是靠在实际项目中主动越界去了解其他模块、其他服务、其他团队在做什么。但大部分人的习惯是把自己的活干完就行了，边界之外的事情不关心。

日积月累下来，技术深度有了，但广度一直没有展开。

技术选型不是选最好的，是选最合适的

初级开发看到一个新技术，第一反应是"这个技术好不好"。架构师看到一个新技术，第一反应是"这个技术在我这个场景下用不用得起"。

举个实际的例子。消息队列选型，Kafka 吞吐量高、RocketMQ 功能全、RabbitMQ 生态成熟。如果只从技术角度看，Kafka 性能最好，选 Kafka 没毛病。

但架构师要考虑的是：团队里有没有人运维过 Kafka 集群？出了问题谁来排查？当前的业务量真的需要 Kafka 这个级别的吞吐吗？如果日消息量就几十万条，上 Kafka 是不是杀鸡用牛刀，RabbitMQ 就够了？而且 RabbitMQ 团队里有三个人用过，Kafka 没人碰过，上了之后谁来兜底？

最终的选择可能是技术上不是最优的，但综合团队能力、维护成本、业务规模之后是最合理的。

架构决策的本质是在约束条件下做取舍，不是在理想环境里挑最好的技术。 很多技术很强的人做不了架构师，就是过不了这一关——他心里只有技术上的最优解，没有考虑过现实约束。

做架构要能预判未来，但不能过度设计

架构师要比普通开发多想一步：现在的设计能不能撑住半年后的业务量？如果用户量翻十倍，哪个环节会先扛不住？

但这个"多想一步"是有边界的。想太远就会陷入过度设计。

我见过一个项目，日活才几千人，架构师上来就设计了分库分表、多级缓存、消息队列异步解耦、分布式事务框架，整套方案能撑千万级用户。技术上没有问题，但团队只有五个人，光是维护这套架构就占掉了大部分精力，业务功能反而做不动了。

项目上线半年后日活涨到了一万，离千万还差一千倍，但系统的运维复杂度已经远超团队的承受能力，最后不得不砍掉了一大半中间件回到相对简单的架构。

好的架构不是功能最多的架构，是恰好够用、能随业务增长逐步演进的架构。 这种分寸感需要时间和经验去培养，它不是读几本架构书就能获得的。

技术方案要能落地，不是画个图就完了

这一点是区分"能聊架构"和"能做架构"的分水岭。

很多人聊架构的时候头头是道，微服务怎么拆、服务网格怎么做、CQRS 怎么落、DDD 怎么分层，全都能说。但让他把方案推到落地，就卡住了。

因为落地要面对的全是脏活。

数据库怎么平滑迁移，不停机？老接口和新接口怎么并行，过渡期多长？这个方案需要其他团队配合改造，人家的排期排得进去吗？上线之后灰度策略怎么定，出了问题怎么回滚？

这些问题在架构图上是看不到的。画图的时候一切都很干净，方块和箭头之间的连线代表的是一次完美的 RPC 调用。但实际落地的时候，每一条线背后都是联调、适配、兼容、妥协。

能画出漂亮架构图的人很多，能把图变成线上稳定运行的系统的人很少。后者才是架构师。

沟通能力不是加分项，是必选项

这可能是很多纯技术人员最不愿意接受的一点。

架构师的日常工作里，写代码的时间可能不到 30%，大量时间在开会、写方案文档、跟不同团队对齐技术方案、向上汇报技术决策的依据。

你设计了一套方案，要让产品经理理解为什么这个需求要分两期做，第一期只能支持到什么程度。要让后端团队理解服务拆分的边界为什么这么划，每个服务的职责是什么。要让运维团队理解为什么这次需要新增两台机器，资源申请的依据是什么。要让老板理解为什么这次技术改造需要两个月不产出新功能。

每个人的立场和关注点都不一样，你得用对方能听懂的语言把同一个方案翻译成不同的版本。

很多技术很强的人做不了架构师就倒在这里。他觉得方案是对的就够了，别人听不懂是别人的问题。但现实是你的方案再好推不动也是零。技术决策需要共识，共识需要沟通，沟通能力不够就没有共识，没有共识方案就落不了地。

怎么从开发往架构方向走

说了这么多差距，不是为了劝退。这些能力不是天赋，都可以刻意练习。

主动越界。 自己的模块做完之后，去看看上下游的模块是怎么实现的。系统出了跨服务的问题，主动参与排查，哪怕不是你的模块。慢慢地你就能建立起对整个系统的全局认知。

多问 why。 项目里用了 Kafka 你就想想为什么用 Kafka 不用 RocketMQ。用了 Redis 做缓存就想想为什么不用本地缓存。这些选型背后的取舍逻辑，才是架构决策的真正内容。

参与技术方案的讨论。 哪怕你现在不是方案的决策者，旁听一下技术评审会议也好。听听架构师怎么分析问题、怎么权衡利弊、怎么回应别人的质疑，这些比看书有用得多。

试着为自己的改动多想一层。 每次写代码的时候多想一下：如果流量涨了十倍这里会不会出问题？如果这个下游服务挂了我的接口会怎样？这种习惯养成了，就是架构思维的起点。

说在最后

写代码和做架构之间差的不是更多的技术，是思维方式的切换。从"怎么实现这个功能"到"这个系统应该长什么样"，从"这个技术怎么用"到"该不该用这个技术"，从"把活干完"到"让整个团队能持续高效地干活"。

这个切换不会自然发生，需要你主动走出自己的舒适区，去承担一些超出当前职责的事情。等你开始操心整个系统的事情而不只是自己那几个接口的时候，你就已经在往架构师的方向走了。