做了快十年程序員見過不少架構——有的簡潔到讓人覺得「這也算架構」有的精巧到讓人讀不懂。好的架構不是設計出來的是在每個階段做了正確的決策才長出來的。四階段框架我把一個項目的演進拆成四個階段能跑 → 跑得準 → 跑得穩 → 跑得快。它們是遞進的時間線每進入一個新階段上一個階段的能力還得保持。但每個階段的核心矛盾不同你要盯住的東西也不同。階段核心問題架構焦點能跑這東西能不能 work簡單優先砍掉一切不必要的跑得準結果對嗎業務驅動用數據驗證跑得穩炸了怎么辦引入復雜度容錯、監控、灰度跑得快扛得住嗎只在瓶頸處動手優化這個框架有一個大前提項目不確定性高。你不知道要做什么、不知道能不能做成、不知道用戶會不會用。這時候階段演進是攢認知的過程一步到位等于盲人摸象。但如果需求很明確——業務方已經把需求拆到字段級別數據量、并發量都有預估——你還按「能跑」來就是浪費大家時間。確定性高的項目前期設計要重該想清楚的要想清楚該預留的擴展點要預留好。區別不在于原則本身在于每條原則的權重0→1 探索型確定性交付型簡單優先★★★ 死守復雜度是負債★★ 保持節省但要預留擴展點業務驅動★★★ 業務反饋驗證方向★★★ 同樣重要但業務目標是已知的先跑通再優化★★★ 先攢認知★ 需求已經清楚設計時就可以優化核心不變做當下信息量下最合理的決策。信息少的時候不瞎猜信息多的時候不偷懶。能跑先證明想法不成立「能跑」階段最容易犯的錯是想太多。表結構還沒定就開始琢磨分庫分表流量還沒來就把消息隊列、微服務、K8s 全套安排上。這個階段只有一個目標用最小的成本證明這個方向值得繼續。怎么做三個字砍、硬、短?？晨彻δ?。一個 MVP 需要的功能比你想象中少得多。用戶管理先用 admin 賬號頂著。權限先不做。通知先不做。硬硬編碼可以寫死配置可以。別在「能跑」階段追求靈活性靈活性是給「跑得穩」階段準備的。短代碼短文件少依賴輕。一個能跑的原型1000 行代碼能搞定的事不要搞成 10 個微服務。「簡單優先」不是偷懶——每多引入一個組件就多一個可能出錯的點就多一份調試時的茫然。簡單意味著更少意外。案例早年做過一個數據同步工具技術選型時在 Spark Streaming 和 Flink 之間糾結了很久。最后兩個都沒用——用 shell cron 先跑了一周發現瓶頸在源端 API 限流跟計算引擎沒關系。如果直接上流處理框架這個真相要等到上線后才發現而那時已經搭進去一整套基礎設施。退出信號當你開始問「這樣寫對不對」而不是「能不能跑」的時候該進入下一階段了。跑得準別自己騙自己「能跑」證明了能做出來。「跑得準」要證明的是做出來的東西是對的。這個階段技術人最容易掉進的坑用技術指標替代業務指標。QPS 上去了延遲下來了覺得自己干得不錯。但業務側說「數據對不上」?！概艿脺省沟暮诵氖前褬I務結果當成唯一的驗證標準。不是單元測試過了就算對不是代碼 review 過了就算對——是業務方看了結果點頭才算對。具體怎么做端到端對賬不是中間環節的日志對得上是源端和終端的數對得上。中間環節再多都對兩頭差一條就是不準。業務方驗收不要自己定了正確標準然后自己做裁判讓業務方來驗收。別迷信測試測試覆蓋的是你知道的邏輯線上出問題往往是你不知道的邏輯。測試只是兜底不是驗證。退出信號業務方不再來找你對賬了。跑得穩該花的復雜度要花到了這個階段系統已經在跑了、結果也對了。但你還睡不踏實。這才是真正開始談架構的階段。前面的「能跑」和「跑得準」是在攢認知——你知道了系統的瓶頸在哪、業務的核心鏈路是什么、什么數據不能丟、什么延遲不能超?！概艿梅€」的核心矛盾是你要引入復雜度保可靠性但又不能把系統搞死。幾個必須花的復雜度容錯。任何操作都要想「失敗了怎么辦」。重試回滾降級不是每個環節都要三樣都做但每個環節至少要有一個兜底路徑?？捎^測。日志、指標、告警這三樣是「跑得穩」的基礎建設。沒有可觀測性系統炸了你都不知道炸在哪。灰度/金絲雀。敢直接全量切說明你對系統還不夠了解。灰度發布不是膽小是給自己留退路。但也有不能花的復雜度不要為了「萬一」做架構。一個日活幾百的內部系統上微服務、分庫分表、多活容災——這些復雜度花出去帶來的不是可靠性是維護負擔。案例一個數據入湖鏈路單機跑沒問題但數據量上來后就怕掛。方案是加 checkpoint 機制——掛了能從斷點續跑不用從頭來。多寫了幾十行代碼換來的是凌晨三點不用爬起來手動重跑。退出信號你能安心睡覺了。跑得快別提前優化性能優化有一條鐵律只在瓶頸處動手?！柑崆皟灮故侨诵缘膯栴}——你知道了某個地方可以更快手就癢。你剛寫完一段代碼腦子里已經在想「這個循環能不能少遍歷一次」。忍住。「跑得快」的正確姿勢先 profiling再動手。你不知道瓶頸在哪之前所有的優化都是在正確的地方浪費時間。用火焰圖用慢查詢日志用 metrics——找到真正的熱點。優化有成本。代碼更快的代價往往是更難讀。一個for循環變成三個map/filter鏈式調用快了 5% 但三個月后沒人看得懂。這個買賣做不做看 5% 在那個場景下值不值。基礎設施優先。很多性能問題不靠改代碼解決——加個緩存、加個索引、調個連接池參數——效果比摳代碼邏輯大得多。案例一個數據查詢接口慢第一反應是優化 SQL折騰了半天。后來發現瓶頸不在 SQL在每次查詢都要從 S3 拉文件。加了本地緩存延遲從秒級降到毫秒級。退出信號沒人再抱怨慢了。原則之間的關系簡單優先、業務驅動、先跑通再優化——這三條原則貫穿四階段但不是每條都平等地作用于每個階段。能跑跑得準跑得穩跑得快簡單優先★★★ 死守★★ 保持★ 讓位于可靠性★★ 克制優化欲業務驅動★ 先跑再說★★★ 唯一標準★★ 業務鏈路優先★★ 優化業務熱點先跑通再優化★★★ 就是 MVP—★ 穩定了再談性能★★★ 但別提前三條原則在你心里不是一個固定權重。不同階段的優先級不一樣這才是「權衡」的真正含義。收尾架構能力不是你畫了多少張圖、用了多少種中間件決定的。是你在正確的時間做了正確的退讓決定的?！改芘堋箷r你退讓了完美「跑得準」時你退讓了技術自負「跑得穩」時你退讓了簡單「跑得快」時你退讓了優化欲。每個階段都有一個你死守的東西和一個你主動放下的東西。知道什么時候該守什么、放什么比知道多少種設計模式都重要。架構不是一次性的決策是持續四階段的循環。下一個需求來了又是從「能跑」開始。