先聊點實在的。做了這么多年信息化系統(tǒng)我越來越覺得架構(gòu)設(shè)計和方案選型這件事本質(zhì)上不是技術(shù)競賽而是一套“在約束條件下做最優(yōu)決策”的方法論。很多團(tuán)隊一談架構(gòu)就喜歡追新什么熱上什么微服務(wù)、云原生、大模型中間件全往里塞結(jié)果系統(tǒng)上線三個月排查一個慢查詢要跨六個服務(wù)改一個字段要發(fā)四個版本。這賬怎么算都不劃算。所以這篇我不打算羅列那些理論框架而是想基于我實際經(jīng)歷的項目把信息化架構(gòu)設(shè)計里最核心的幾個原則、技術(shù)選型的完整思考路徑以及落地過程中的真實坑點一次性聊透。如果你正在主導(dǎo)一個系統(tǒng)的技術(shù)藍(lán)圖或者在為一套老系統(tǒng)做架構(gòu)升級這篇文章應(yīng)該能給你一些可以直接用的判斷標(biāo)準(zhǔn)。1. 整體架構(gòu)設(shè)計的核心思路與四大原則架構(gòu)設(shè)計這件事很多人一開始就搞錯了順序。上來就畫服務(wù)拆分圖、定技術(shù)棧這是在蓋空中樓閣。架構(gòu)設(shè)計的第一步永遠(yuǎn)是先搞清楚“這個系統(tǒng)服務(wù)誰、解決什么問題、在什么環(huán)境里活多久”。1.1 業(yè)務(wù)驅(qū)動還是技術(shù)驅(qū)動先想清楚“為誰設(shè)計”我見過太多技術(shù)團(tuán)隊把架構(gòu)設(shè)計做成了技術(shù)秀。明明一套單體應(yīng)用就能解決80%的問題非要拆成十幾個微服務(wù)內(nèi)部系統(tǒng)根本沒那么多并發(fā)非要把消息隊列、分布式事務(wù)全部鋪上。說到底架構(gòu)是業(yè)務(wù)的投影業(yè)務(wù)的復(fù)雜度才是架構(gòu)復(fù)雜度的上限。業(yè)務(wù)驅(qū)動說起來簡單做起來卻需要克制。你拿到需求后第一件事不該是去想用什么中間件而是去回答幾個問題這個系統(tǒng)的用戶量級是多少未來三年能漲到什么程度核心業(yè)務(wù)流程的鏈路有多長是否存在強(qiáng)一致性的要求團(tuán)隊的運(yùn)維能力能支撐多復(fù)雜的基建體系。這些答案直接決定了架構(gòu)的走向。我在做一套企業(yè)訂單管理系統(tǒng)的時候業(yè)務(wù)方一開始就提出要支持千萬級日訂單還要求99.99%的可用性。結(jié)果一調(diào)研真實場景是這家企業(yè)每天都訂單量才幾萬峰值也不會超過十萬。如果按千萬級去設(shè)計硬件成本、人力成本、復(fù)雜度成本全部白白翻幾倍。后來我堅持按十萬級去設(shè)計架構(gòu)但預(yù)留了接口擴(kuò)展能力用一套可配置的水平擴(kuò)展機(jī)制覆蓋了未來三年的增長預(yù)期。1.2 分層思想與關(guān)注點分離架構(gòu)的“收納箱”邏輯做架構(gòu)設(shè)計我一直強(qiáng)調(diào)一個概念好的架構(gòu)應(yīng)該像高效的收納箱每個箱子有明確的標(biāo)簽東西放在哪里一目了然拿取的時候不用翻箱倒柜。實現(xiàn)這種效果的核心手段就是分層。從橫向上看最經(jīng)典的層級劃分是接入層、應(yīng)用層、服務(wù)層、數(shù)據(jù)層。每層各司其職接入層只管協(xié)議解析和流量控制應(yīng)用層只管業(yè)務(wù)流程編排服務(wù)層提供原子化的業(yè)務(wù)能力數(shù)據(jù)層統(tǒng)一管理數(shù)據(jù)的讀寫和存儲。分層的意義不只是職責(zé)清晰更關(guān)鍵的是可以獨立擴(kuò)展和升級。有一次我們優(yōu)化一個系統(tǒng)的性能瓶頸排查下來發(fā)現(xiàn)是網(wǎng)關(guān)層做了一些業(yè)務(wù)邏輯處理導(dǎo)致CPU被大量計算占用。就是因為當(dāng)初分層不嚴(yán)格把本屬于服務(wù)層的邏輯塞到了接入層才埋下了這個雷。如果一開始就嚴(yán)格遵守分層原則這個問題的定位和修復(fù)會快得多。1.3 演進(jìn)式架構(gòu)沒人能一步設(shè)計出“完美的系統(tǒng)”過去我特別迷信“大設(shè)計”——總想一次性把架構(gòu)藍(lán)圖畫得完美無缺把所有邊界都劃清楚把所有變動都預(yù)判到?？涩F(xiàn)實是幾乎每次都會被業(yè)務(wù)打臉。需求在變、團(tuán)隊在變、技術(shù)在變沒有哪個架構(gòu)可以一勞永逸。后來我徹底轉(zhuǎn)向了演進(jìn)式架構(gòu)的思路。核心邏輯是你不需要在今天為未來五年的所有可能買單你只需要保證今天的方案是合理且干凈的并且它具備一個清晰的演進(jìn)路徑。任何一個模塊都可以在被替換、被升級、被拆分的時候不牽連整個系統(tǒng)這就是好架構(gòu)。這套思路落地到實踐里就是“兩層架構(gòu)思維”底層的基礎(chǔ)設(shè)施和核心技術(shù)棧要盡量穩(wěn)定選最成熟可靠的東西不要頻繁折騰上層的業(yè)務(wù)模塊和接口設(shè)計要輕量通過策略模式、插件機(jī)制、事件驅(qū)動這些手法讓業(yè)務(wù)變化可以低成本地落地。1.4 簡單性原則YAGNI原則不是口號是保命法則YAGNIYou Arent Gonna Need It原則在架構(gòu)設(shè)計里的含義很簡單不要為當(dāng)前不需要的功能做設(shè)計。但真正執(zhí)行起來會非常難受因為人都有路徑依賴遇到一個問題第一反應(yīng)就是把這個潛在場景全部覆蓋到。舉個典型的例子我們早期一個項目開發(fā)在數(shù)據(jù)庫設(shè)計階段就把分庫分表的方案做了按user_id做了哈希分片結(jié)果上線兩年連單表數(shù)據(jù)量一百萬都不到。每次業(yè)務(wù)查詢還得走中間件分布式事務(wù)的問題又多了一大堆。后來回滾到單庫單表整個系統(tǒng)性能反而提升了30%。這就是典型的提前優(yōu)化災(zāi)難。簡單性原則還體現(xiàn)在依賴管理上。有些團(tuán)隊為了做一個功能引入一個重量級框架只用了它10%的能力卻要承擔(dān)它100%的維護(hù)成本和升級風(fēng)險。我在技術(shù)評審里有一條鐵律任何新依賴的引入必須明確它能解決什么當(dāng)前存在的問題同時評估如果它被廢棄替代方案是什么。回答不了這兩個問題這個依賴就不該進(jìn)項目。2. 技術(shù)選型的方法論與實操要點選型這件事說難也難說簡單也簡單。難的是信息不對稱你很難知道一個框架在極端情況下到底怎么樣簡單的是只要你建立起一套理性的評估框架大部分選擇會自然浮現(xiàn)出來。2.1 選型到底在選什么不是選“最好的”而是選“最合適的”很多人在技術(shù)選型的時候有個誤區(qū)喜歡問“哪個框架最好”。這個問題的前提本身就有問題因為沒有脫離業(yè)務(wù)場景的“最好”。Redis再好你讓它做關(guān)系型數(shù)據(jù)存儲試試Kafka再強(qiáng)你讓它處理幾十毫秒級延遲的事務(wù)消息試試。所以選型的第一步是明確這個組件在系統(tǒng)里扮演什么角色它的核心職責(zé)和最關(guān)鍵的指標(biāo)是什么。消息中間件你就關(guān)注吞吐量和可靠性業(yè)務(wù)流程引擎你就關(guān)注可編排性和可維護(hù)性前端框架你就關(guān)注生態(tài)成熟度和團(tuán)隊上手成本。合適的另一個含義是匹配自身團(tuán)隊的技術(shù)積累。我之前在一個團(tuán)隊主導(dǎo)過一次技術(shù)棧升級經(jīng)過多方對比論證選了一個性能數(shù)據(jù)非常優(yōu)秀的服務(wù)端框架結(jié)果團(tuán)隊里沒人用過遇到問題在網(wǎng)上連經(jīng)驗帖都找不到?？蚣鼙旧頉]問題但和我們的團(tuán)隊能力不匹配這就不是合適的選型。選型應(yīng)該是在團(tuán)隊能掌控的范圍內(nèi)尋找效果最優(yōu)解。2.2 技術(shù)選型的多維評估體系社區(qū)、生態(tài)、成本、風(fēng)險一個都不能少在真正的選型評審中我會把候選技術(shù)放到以下幾個維度里做橫向?qū)Ρ?。第一是社區(qū)活躍度和治理成熟度。這個技術(shù)是哪個組織在維護(hù)多久發(fā)一個版本Issue響應(yīng)快不快如果這個項目只有兩三個人在維護(hù)哪怕其他維度再好也要非常慎重。因為你不知不覺間就把系統(tǒng)的關(guān)鍵命脈交到了別人手里。第二是生態(tài)完整度。選一個技術(shù)不只是選它本身而是選它周邊的整個生態(tài)。比如Java的服務(wù)端框架能對接多少種中間件前端框架的組件庫是否豐富數(shù)據(jù)層的ORM工具鏈?zhǔn)欠癯墒?。生態(tài)完整意味著你未來遇到的多數(shù)問題社區(qū)都已經(jīng)替你趟過坑了。第三是運(yùn)維成本和學(xué)習(xí)成本。引入一個技術(shù)變量就給團(tuán)隊增加了一份長期的知識負(fù)擔(dān)和運(yùn)維負(fù)擔(dān)。有些中間件功能強(qiáng)大但部署、調(diào)優(yōu)、排查問題都需要很深的專業(yè)積累對中小團(tuán)隊來說這個隱性成本可能遠(yuǎn)超它帶來的性能收益。第四是許可證和商業(yè)風(fēng)險。開源不等于免費(fèi)使用GPL協(xié)議對業(yè)務(wù)的傳染性、商業(yè)授權(quán)的費(fèi)用、供應(yīng)商鎖定問題都必須在選型評審里提前排查清楚。這塊很多人會忽視等企業(yè)法務(wù)找上門來就晚了。2.3 前端技術(shù)棧的選擇不只是“用React還是Vue”的問題熱詞里專門有一條“軟件前端技術(shù)棧介紹和選型”可見前端選型在信息化項目里的權(quán)重確實不小。但前端選型遠(yuǎn)不止在React和Vue之間二選一那么簡單它背后是一整套技術(shù)決策鏈。首先要判斷項目的產(chǎn)品形態(tài)。如果是強(qiáng)交互的復(fù)雜中后臺系統(tǒng)組件化框架幾乎是剛需這種情況下React和Vue的生態(tài)優(yōu)勢就很突出如果是內(nèi)容展示為主的官網(wǎng)類系統(tǒng)直接采用SSR方案或者靜態(tài)站點生成器會更劃算如果項目里大量涉及Canvas繪圖、WebGL這樣的重交互場景那技術(shù)選型就要圍繞渲染性能做考慮。其次要關(guān)注工程鏈路的配套能力。前端選型不只是選一個框架而是選一套構(gòu)建工具鏈、一套狀態(tài)管理方案、一套樣式方案、一套組件庫和一套代碼規(guī)范。比如選了React配套的React Router是路由標(biāo)配狀態(tài)管理在Redux Toolkit和Zustand之間要權(quán)衡CSS方案在Tailwind和CSS Modules之間要選擇。鏈路選完整了團(tuán)隊開發(fā)效率才有保障。2.4 選型的落地工具技術(shù)選型評分表與POC驗證評估維度說再多落地時離開了量化工具就容易變成各說各話。我自己在團(tuán)隊里推行了一套技術(shù)選型打分表把所有候選技術(shù)放到一個統(tǒng)一框架里打分減少主觀判斷的空間。打分表的結(jié)構(gòu)大致是業(yè)務(wù)匹配度占25分社區(qū)生態(tài)占20分團(tuán)隊能力契合度占20分運(yùn)維成本占15分性能指標(biāo)占10分長期風(fēng)險占10分。每個維度先由評審成員獨立打分再集中討論差異點。這比單純拍腦袋選型或者單純看技術(shù)熱度要靠譜得多。打分表出結(jié)果后還不能直接做決定。對于打分差距不大的候選方案必須做一輪POC概念驗證。這個POC不是為了證明技術(shù)能用而是為了驗證它在你的具體業(yè)務(wù)場景下表現(xiàn)如何。比如要選消息隊列就真實模擬你的消息量級和消費(fèi)場景看吞吐、看延遲、看堆積恢復(fù)能力。紙上談兵的結(jié)果再漂亮也不如實測數(shù)據(jù)說話。3. 實操案例一次信息化架構(gòu)方案的設(shè)計全過程理論講了一大堆不如帶你完整走一遍我近期主導(dǎo)的架構(gòu)設(shè)計項目。這是一套面向中型零售企業(yè)的信信息化統(tǒng)一管理平臺覆蓋客戶管理、訂單管理、庫存管理、數(shù)據(jù)分析四個核心域。我會把從需求分析到方案定稿的關(guān)鍵決策點都拆出來講。3.1 需求分析與架構(gòu)目標(biāo)定義這個項目剛啟動的時候業(yè)務(wù)方給了一堆功能需求看起來非常龐雜。我的第一步?jīng)]急著畫架構(gòu)圖而是把需求重新歸類剝離出幾個關(guān)鍵的架構(gòu)影響因子。第一用戶規(guī)模與并發(fā)特征。系統(tǒng)主要面向企業(yè)內(nèi)部員工和一部分外部供應(yīng)商日常在線用戶預(yù)計幾百人峰值并發(fā)不高但月末出報表時會有短時計算密集型的任務(wù)。這個判斷直接排除了復(fù)雜的微服務(wù)化方案和分布式計算框架。第二數(shù)據(jù)特征與一致性要求。訂單和庫存數(shù)據(jù)是核心資產(chǎn)要求強(qiáng)一致性交易鏈路不能出現(xiàn)數(shù)據(jù)偏差而報表和運(yùn)營分析數(shù)據(jù)允許秒級延遲這決定了數(shù)據(jù)架構(gòu)可以采用讀寫分離和異步同步?；谶@些判斷我給這個架構(gòu)定了三個核心目標(biāo)以較低的復(fù)雜度支撐未來三年業(yè)務(wù)增長核心鏈路的可靠性和數(shù)據(jù)一致性必須有保障系統(tǒng)具備良好的可維護(hù)性換人也能接手。這些目標(biāo)寫清楚之后后面所有的技術(shù)決策都有了參照系。3.2 分層架構(gòu)設(shè)計與模塊邊界劃分整體架構(gòu)上我采用了經(jīng)典的四層設(shè)計。接入層部署Nginx和API網(wǎng)關(guān)負(fù)責(zé)靜態(tài)資源的托管、請求路由、限流和簡單的安全校驗。應(yīng)用層是業(yè)務(wù)邏輯的核心按“模塊化單體”的思路組織每個業(yè)務(wù)域客戶、訂單、庫存、分析是獨立的Maven模塊通過Java的模塊化機(jī)制做物理隔離但部署上是一個統(tǒng)一的Spring Boot應(yīng)用。服務(wù)層承載跨業(yè)務(wù)域的通用能力包括統(tǒng)一認(rèn)證服務(wù)、文件服務(wù)、消息服務(wù)、任務(wù)調(diào)度服務(wù)。這些能力被抽象成基礎(chǔ)服務(wù)供各業(yè)務(wù)模塊調(diào)用。最底層是數(shù)據(jù)層包含MySQL主庫從庫、Redis緩存集群、Elasticsearch檢索服務(wù)以及定時任務(wù)的調(diào)度存儲。為什么在這個階段堅持“模塊化單體”而不是微服務(wù)邏輯很簡單系統(tǒng)的用戶規(guī)模和業(yè)務(wù)復(fù)雜度尚未達(dá)到需要物理拆分的程度而微服務(wù)帶來的部署復(fù)雜度、鏈路追蹤成本、分布式事務(wù)問題會直接吞噬掉開發(fā)效率。模塊化單體既能享受代碼層的邊界清晰又能保持運(yùn)維層面的簡單性等業(yè)務(wù)真的發(fā)展壯大了再按模塊邊界做服務(wù)化演進(jìn)也完全來得及。3.3 基礎(chǔ)設(shè)施與關(guān)鍵中間件的選型依據(jù)中間件選型是個考驗判斷力的環(huán)節(jié)。消息隊列我選了RabbitMQ而不是Kafka核心原因是業(yè)務(wù)場景以可靠投遞為主而非極致吞吐。庫存鎖定、訂單狀態(tài)變更這類消息對可靠性要求極高RabbitMQ的ACK機(jī)制和死信隊列在這一點上表現(xiàn)成熟。緩存選型沒有懸念Redis是當(dāng)前信息化系統(tǒng)的最優(yōu)解但版本和部署模式需要仔細(xì)斟酌。分布式定時任務(wù)這塊我先排除了自研方案也不推薦直接上大型分布式調(diào)度框架而是ElasticJob這個輕量級方案配合ZooKeeper做協(xié)調(diào)。它足夠簡單能滿足85%以上的定時任務(wù)場景出了問題也容易排查。唯一突破我“避免冷門技術(shù)”原則的是全文檢索用了Elasticsearch。原因是業(yè)務(wù)里正好有商品搜索、訂單模糊查詢這類場景ES的倒排索引優(yōu)勢無法被MySQL替代。但是為了避免ES引入的運(yùn)維復(fù)雜度我沒有讓業(yè)務(wù)直接寫ES而是統(tǒng)一封裝了一層數(shù)據(jù)同步服務(wù)由業(yè)務(wù)系統(tǒng)通過接口調(diào)用團(tuán)隊不需要每個人都會維護(hù)ES集群。3.4 數(shù)據(jù)存儲與一致性方案設(shè)計數(shù)據(jù)層的設(shè)計是整個架構(gòu)中最需要小心對待的部分。核心交易數(shù)據(jù)用MySQL InnoDB存儲訂單表和庫存表按業(yè)務(wù)維度設(shè)計了合理的索引和分區(qū)策略分析型數(shù)據(jù)通過同步服務(wù)寫入Elasticsearch和一套用于報表的只讀MySQL從庫實現(xiàn)讀寫分離。訂單庫存的一致性是整個系統(tǒng)最核心的強(qiáng)一致場景。我采用了本地消息表加消息隊列的重試機(jī)制在數(shù)據(jù)庫事務(wù)里先寫業(yè)務(wù)數(shù)據(jù)同時向本地消息表插入一條狀態(tài)為“待發(fā)送”的消息事務(wù)提交后再由異步任務(wù)把消息投遞給MQ。消費(fèi)端處理成功后回調(diào)更新消息狀態(tài)。這套方案避免了分布式事務(wù)的高復(fù)雜度同時能保證最終一致性在多數(shù)信息化場景下已經(jīng)足夠可靠。緩存一致性也是日常開發(fā)經(jīng)常踩坑的地方。我統(tǒng)一要求所有緩存更新采用“先更新數(shù)據(jù)庫再刪除緩存”的策略且緩存刪除失敗的場景通過消息隊列做補(bǔ)償。這套操作手法雖然老套但安全、穩(wěn)定非常經(jīng)得起生產(chǎn)環(huán)境的考驗。3.5 架構(gòu)方案評審與技術(shù)選型復(fù)盤方案定稿后我組織了一場架構(gòu)評審會除了技術(shù)團(tuán)隊內(nèi)部也請了運(yùn)維和業(yè)務(wù)側(cè)的同事。評審會上最大的爭議點在數(shù)據(jù)庫要不要做分庫分表運(yùn)維同事認(rèn)為按現(xiàn)在的基礎(chǔ)設(shè)施能力單庫扛住未來三年的業(yè)務(wù)量沒問題而團(tuán)隊里有同學(xué)擔(dān)心數(shù)據(jù)量增長后會成為瓶頸。最終的決定是不做分庫分表但通過下表加歷史數(shù)據(jù)歸檔把訂單表按月份分區(qū)控制單表數(shù)據(jù)量在億條以內(nèi)。理由是架構(gòu)上保持簡單數(shù)據(jù)庫一旦分片所有關(guān)聯(lián)查詢和事務(wù)的實現(xiàn)成本都會幾何級上升而系統(tǒng)的真實增長預(yù)期并沒有那么可怕。事實證明這個決策是對的系統(tǒng)上線一年多單表數(shù)據(jù)量離瓶頸還有很大距離。4. 架構(gòu)落地與演進(jìn)中的常見問題排查再完美的架構(gòu)設(shè)計落地過程中也一定會踩坑。這一節(jié)我把過去幾年在架構(gòu)實施里遇到的典型問題整理出來就當(dāng)是給大家的一份避坑手冊。4.1 過度設(shè)計三個最典型的“自嗨式”癥狀過度設(shè)計是架構(gòu)師最容易犯的職業(yè)病我在團(tuán)隊里總結(jié)過三個典型癥狀。第一個癥狀是分布式事務(wù)泛濫。一個內(nèi)部管理系統(tǒng)事務(wù)鏈路根本跨不了幾個服務(wù)卻非要用Seata或者Saga做全局事務(wù)管理。事務(wù)的復(fù)雜度跟著服務(wù)邊界走服務(wù)邊界是自己定的一開始就不該把服務(wù)切那么碎。第二個癥狀是過早抽象。代碼連三個實現(xiàn)類都沒有先把抽象工廠、策略模式、模板方法模式全鋪滿。抽象是為變化準(zhǔn)備的業(yè)務(wù)還沒變化就做抽象等于提前負(fù)債。我一般建議至少出現(xiàn)三個以上的相似場景再考慮統(tǒng)一的抽象。第三個癥狀是盲目追求性能指標(biāo)。為了在某次壓測里把QPS刷到好看上了一大堆緩存、異步化、連接池調(diào)優(yōu)結(jié)果真實業(yè)務(wù)場景的QPS連零頭都用不到。性能優(yōu)化永遠(yuǎn)應(yīng)該是問題驅(qū)動而不是指標(biāo)驅(qū)動。4.2 技術(shù)棧割裂一個系統(tǒng)里裝了“半個互聯(lián)網(wǎng)”服務(wù)多了以后一個很隱蔽的問題是技術(shù)棧分裂。我見過最夸張的系統(tǒng)一個項目里同時存在Spring Cloud和Dubbo兩套微服務(wù)框架一套老系統(tǒng)用Python寫業(yè)務(wù)模塊又用Java重寫了一遍前端一個后臺管理系統(tǒng)同時混著Vue2和Vue3的頁面。這種技術(shù)棧割裂的代價非常高昂。團(tuán)隊里每個人都要同時維護(hù)多套技術(shù)體系知識無法沉淀招聘也困難基礎(chǔ)設(shè)施無法統(tǒng)一日志、監(jiān)控、發(fā)布都要各搞一套。我的建議是在架構(gòu)評審中必須明確“技術(shù)棧紅線”新項目有嚴(yán)格的技術(shù)選型范圍老項目有明確的遷移路徑。穩(wěn)定壓倒一切盡量不要讓團(tuán)隊長期維護(hù)多個技術(shù)體系。4.3 可觀測性建設(shè)滯后排查問題全靠“試”很多系統(tǒng)上線初期一切正常等業(yè)務(wù)量上來后才開始出各種詭異問題。這時候如果監(jiān)控體系沒跟上排查問題就像大海撈針。早期我在架構(gòu)設(shè)計里不太重視可觀測性覺得這是運(yùn)維階段的事后來被生產(chǎn)環(huán)境坑過幾次徹底改變了這個認(rèn)知?，F(xiàn)在任何架構(gòu)方案可觀測性都是我評審的一票否決項。核心服務(wù)的接口必須有請求量、延遲、錯誤率的黃金指標(biāo)監(jiān)控數(shù)據(jù)庫有慢查詢監(jiān)控核心業(yè)務(wù)鏈路必須有Trace鏈路追蹤。日志必須全量采集并集中存儲至少保留三十天。沒有這些基礎(chǔ)設(shè)施你談架構(gòu)優(yōu)化、談性能調(diào)優(yōu)都是盲人摸象。4.4 團(tuán)隊能力與架構(gòu)復(fù)雜度的錯配再好的設(shè)計也怕“接不住”最后想聊一個很多人羞于直說的問題架構(gòu)方案再先進(jìn)如果團(tuán)隊交付能力跟不上終究是空中樓閣。有一年我們團(tuán)隊進(jìn)了一個做中臺架構(gòu)的牛人設(shè)計了一套非常漂亮的領(lǐng)域驅(qū)動設(shè)計加事件風(fēng)暴架構(gòu)各種限界上下文劃分得井井有條。結(jié)果落地的第一個迭代就卡住了團(tuán)隊大部分成員根本不懂DDD的戰(zhàn)術(shù)模式代碼怎么寫都別扭最后只能退回務(wù)實的分層模式。這個案例給我的教訓(xùn)是好的架構(gòu)是團(tuán)隊當(dāng)下能理解并持續(xù)維護(hù)的架構(gòu)。設(shè)計者要有用戶思維你的“用戶”就是后面的開發(fā)同學(xué)方案做出來他們看不懂、學(xué)不會這個方案的真正價值就要打個問號。推動團(tuán)隊技術(shù)能力建設(shè)應(yīng)該和架構(gòu)演進(jìn)同步進(jìn)行先培訓(xùn)后上線別讓方案走在團(tuán)隊前面太遠(yuǎn)。5. 架構(gòu)設(shè)計中的“軟實力”評審、溝通與長期維護(hù)聊完硬核的技術(shù)主題最后說一說架構(gòu)設(shè)計中那些看不見的“軟實力”。很多人覺得架構(gòu)師就是畫圖加選型其實頂多算三分之一的工作量。剩下的三分之二是靠評審機(jī)制、有效溝通和長期主義堆起來的。5.1 架構(gòu)評審會的正確打開方式架構(gòu)評審會最忌諱變成“答辯會”。提案人上來講PPT講完大家挑毛病最后要么不了了之要么拍腦袋定方案。我組織評審會有一套固定的流程會前提前三天把架構(gòu)文檔發(fā)給大家明確每個人的角色是審查者而不是聽眾會上先花十分鐘快速過背景和方案剩下時間全部用來討論風(fēng)險點和權(quán)衡點會議結(jié)束前必須輸出明確的結(jié)論和待辦事項。評審會上還有一個技巧讓最資深的幾個人先發(fā)言但事先跟他們打好招呼不要第一個表態(tài)否則剩下的人都會跟著站隊。我見過太多評審會因為某個權(quán)威的一句話把正常人云亦云地帶偏了。架構(gòu)評審要的是多維度的理性碰撞不是一言堂。5.2 寫給業(yè)務(wù)方的“架構(gòu)說明書”架構(gòu)師必須學(xué)會用業(yè)務(wù)語言和技術(shù)團(tuán)隊溝通這件事我花了好幾年才真正做好。業(yè)務(wù)方不懂什么是網(wǎng)關(guān)、什么是微服務(wù)但他們關(guān)心這些選擇是否影響項目排期、是否需要增加成本、能否支撐未來的業(yè)務(wù)擴(kuò)張。所以我會寫兩份文檔技術(shù)團(tuán)隊一份詳細(xì)的技術(shù)架構(gòu)說明業(yè)務(wù)方一份精簡的“架構(gòu)決策摘要”用他們聽得懂的語言說明這次架構(gòu)決策解決了什么問題減少了什么風(fēng)險帶來了什么價值。信息只有傳達(dá)到位才能獲得業(yè)務(wù)方的信任和支持。架構(gòu)工作不是關(guān)起門來的技術(shù)活它本身就是一種組織行為。5.3 從“架構(gòu)設(shè)計”到“架構(gòu)治理”讓好架構(gòu)活下來很多系統(tǒng)在執(zhí)行層都會犯一個通病架構(gòu)文檔畫得漂漂亮亮代碼卻早就和文檔脫節(jié)。好架構(gòu)不是設(shè)計出來就完事了它需要一套治理機(jī)制去維護(hù)。我在團(tuán)隊里推行了三個簡單動作效果非常明顯。第一統(tǒng)一代碼規(guī)范并在CI流水線里強(qiáng)制校驗不符合規(guī)范直接攔截。第二每季度做一次“架構(gòu)守護(hù)評審”對照設(shè)計文檔檢查核心模塊是否有越界調(diào)用、是否有繞開分層結(jié)構(gòu)的壞味道。第三核心模塊的重大改動必須有架構(gòu)評審記錄杜絕個人隨意推翻既定技術(shù)路線的情況。架構(gòu)治理的本質(zhì)是讓最優(yōu)方案從“一次性的設(shè)計決策”變成“長期可持續(xù)的工程文化”。我見過不少系統(tǒng)在一兩年后架構(gòu)腐化到無法維護(hù)根本原因不是當(dāng)初設(shè)計得不好而是沒有一套機(jī)制守護(hù)設(shè)計。這是很多團(tuán)隊最容易忽視也最值得重視的地方。