架构不是设计出来的

做了快十年程序员见过不少架构——有的简洁到让人觉得「这也算架构」有的精巧到让人读不懂。好的架构不是设计出来的是在每个阶段做了正确的决策才长出来的。四阶段框架我把一个项目的演进拆成四个阶段能跑 → 跑得准 → 跑得稳 → 跑得快。它们是递进的时间线每进入一个新阶段上一个阶段的能力还得保持。但每个阶段的核心矛盾不同你要盯住的东西也不同。阶段核心问题架构焦点能跑这东西能不能 work简单优先砍掉一切不必要的跑得准结果对吗业务驱动用数据验证跑得稳炸了怎么办引入复杂度容错、监控、灰度跑得快扛得住吗只在瓶颈处动手优化这个框架有一个大前提项目不确定性高。你不知道要做什么、不知道能不能做成、不知道用户会不会用。这时候阶段演进是攒认知的过程一步到位等于盲人摸象。但如果需求很明确——业务方已经把需求拆到字段级别数据量、并发量都有预估——你还按「能跑」来就是浪费大家时间。确定性高的项目前期设计要重该想清楚的要想清楚该预留的扩展点要预留好。区别不在于原则本身在于每条原则的权重0→1 探索型确定性交付型简单优先★★★ 死守复杂度是负债★★ 保持节省但要预留扩展点业务驱动★★★ 业务反馈验证方向★★★ 同样重要但业务目标是已知的先跑通再优化★★★ 先攒认知★ 需求已经清楚设计时就可以优化核心不变做当下信息量下最合理的决策。信息少的时候不瞎猜信息多的时候不偷懒。能跑先证明想法不成立「能跑」阶段最容易犯的错是想太多。表结构还没定就开始琢磨分库分表流量还没来就把消息队列、微服务、K8s 全套安排上。这个阶段只有一个目标用最小的成本证明这个方向值得继续。怎么做三个字砍、硬、短。砍砍功能。一个 MVP 需要的功能比你想象中少得多。用户管理先用 admin 账号顶着。权限先不做。通知先不做。硬硬编码可以写死配置可以。别在「能跑」阶段追求灵活性灵活性是给「跑得稳」阶段准备的。短代码短文件少依赖轻。一个能跑的原型1000 行代码能搞定的事不要搞成 10 个微服务。「简单优先」不是偷懒——每多引入一个组件就多一个可能出错的点就多一份调试时的茫然。简单意味着更少意外。案例早年做过一个数据同步工具技术选型时在 Spark Streaming 和 Flink 之间纠结了很久。最后两个都没用——用 shell cron 先跑了一周发现瓶颈在源端 API 限流跟计算引擎没关系。如果直接上流处理框架这个真相要等到上线后才发现而那时已经搭进去一整套基础设施。退出信号当你开始问「这样写对不对」而不是「能不能跑」的时候该进入下一阶段了。跑得准别自己骗自己「能跑」证明了能做出来。「跑得准」要证明的是做出来的东西是对的。这个阶段技术人最容易掉进的坑用技术指标替代业务指标。QPS 上去了延迟下来了觉得自己干得不错。但业务侧说「数据对不上」。「跑得准」的核心是把业务结果当成唯一的验证标准。不是单元测试过了就算对不是代码 review 过了就算对——是业务方看了结果点头才算对。具体怎么做端到端对账不是中间环节的日志对得上是源端和终端的数对得上。中间环节再多都对两头差一条就是不准。业务方验收不要自己定了正确标准然后自己做裁判让业务方来验收。别迷信测试测试覆盖的是你知道的逻辑线上出问题往往是你不知道的逻辑。测试只是兜底不是验证。退出信号业务方不再来找你对账了。跑得稳该花的复杂度要花到了这个阶段系统已经在跑了、结果也对了。但你还睡不踏实。这才是真正开始谈架构的阶段。前面的「能跑」和「跑得准」是在攒认知——你知道了系统的瓶颈在哪、业务的核心链路是什么、什么数据不能丢、什么延迟不能超。「跑得稳」的核心矛盾是你要引入复杂度保可靠性但又不能把系统搞死。几个必须花的复杂度容错。任何操作都要想「失败了怎么办」。重试回滚降级不是每个环节都要三样都做但每个环节至少要有一个兜底路径。可观测。日志、指标、告警这三样是「跑得稳」的基础建设。没有可观测性系统炸了你都不知道炸在哪。灰度/金丝雀。敢直接全量切说明你对系统还不够了解。灰度发布不是胆小是给自己留退路。但也有不能花的复杂度不要为了「万一」做架构。一个日活几百的内部系统上微服务、分库分表、多活容灾——这些复杂度花出去带来的不是可靠性是维护负担。案例一个数据入湖链路单机跑没问题但数据量上来后就怕挂。方案是加 checkpoint 机制——挂了能从断点续跑不用从头来。多写了几十行代码换来的是凌晨三点不用爬起来手动重跑。退出信号你能安心睡觉了。跑得快别提前优化性能优化有一条铁律只在瓶颈处动手。「提前优化」是人性的问题——你知道了某个地方可以更快手就痒。你刚写完一段代码脑子里已经在想「这个循环能不能少遍历一次」。忍住。「跑得快」的正确姿势先 profiling再动手。你不知道瓶颈在哪之前所有的优化都是在正确的地方浪费时间。用火焰图用慢查询日志用 metrics——找到真正的热点。优化有成本。代码更快的代价往往是更难读。一个for循环变成三个map/filter链式调用快了 5% 但三个月后没人看得懂。这个买卖做不做看 5% 在那个场景下值不值。基础设施优先。很多性能问题不靠改代码解决——加个缓存、加个索引、调个连接池参数——效果比抠代码逻辑大得多。案例一个数据查询接口慢第一反应是优化 SQL折腾了半天。后来发现瓶颈不在 SQL在每次查询都要从 S3 拉文件。加了本地缓存延迟从秒级降到毫秒级。退出信号没人再抱怨慢了。原则之间的关系简单优先、业务驱动、先跑通再优化——这三条原则贯穿四阶段但不是每条都平等地作用于每个阶段。能跑跑得准跑得稳跑得快简单优先★★★ 死守★★ 保持★ 让位于可靠性★★ 克制优化欲业务驱动★ 先跑再说★★★ 唯一标准★★ 业务链路优先★★ 优化业务热点先跑通再优化★★★ 就是 MVP—★ 稳定了再谈性能★★★ 但别提前三条原则在你心里不是一个固定权重。不同阶段的优先级不一样这才是「权衡」的真正含义。收尾架构能力不是你画了多少张图、用了多少种中间件决定的。是你在正确的时间做了正确的退让决定的。「能跑」时你退让了完美「跑得准」时你退让了技术自负「跑得稳」时你退让了简单「跑得快」时你退让了优化欲。每个阶段都有一个你死守的东西和一个你主动放下的东西。知道什么时候该守什么、放什么比知道多少种设计模式都重要。架构不是一次性的决策是持续四阶段的循环。下一个需求来了又是从「能跑」开始。