老僧三十年前未參禪時，見山是山，見水是水。及至後來，親見知識，有個入出，見山不是山，見水不是水。而今得個休歇處，依前見山只是山，見水只是水。
—唐代青原惟信禪師
參禪的三重境界在 IT 技術圈同樣適用，初學者感嘆每個產品都如此精妙絕倫，追逐著最強的 IDE；老司機喜歡自比管樂指點江山，嘲諷著最好的語言。
當一切迴歸平淡，搞 IT 就是一份思想延伸和語言翻譯工作，其中技術架構師就是一份古樸甚至無趣的工作。
我將架構師的工作總結出五條核心道理，這五條經驗簡單直白又深奧通透，算是對我 12 年 IT 工作的一個總結。
架構技術像機器人哄小孩一樣簡單
需求優化最重要：少查少寫少依賴，Less is more
一個 IT 系統是多角色多模塊分層分級的，像 OSI 模型上層應用簡單依賴下層支撐，SOA 設計中同級角色也只看對方的接口。
各角色分工明確方便快速實現業務，但是給架構優化也埋下大坑，底層的盲目支撐是巨大資源浪費，平級調度協作也沒任何彈性。
前端一個小邏輯需求會導致後端大規模聯動，不同服務也沒權限理解對方的內存數據，各個角色的工程師都只看自己的工作範圍，這是正常又無奈的現狀。
我們要搞架構設計最重要的就是砍需求，將上層應用的需求優化刪減，讓同級的業務能容錯。
上層需求優化，即前端對後端少輸入少查詢多容錯，而同級容錯可以看做應用間的需求優化。
比如兩個服務可以冪等重試就是好解耦，而 A 系統會等 B 系統等到死鎖就是架構悲劇。
某電商 ERP 系統的用戶點一次查詢按鈕，後臺系統就鎖庫查詢一次；實操過程中系統越慢用戶就重複點查詢按鈕，而並行查詢越多後臺速度就更慢。
這種環境要搞架構優化，首先要理解自然人並不要求實時數據，ERP 客戶端限制每 15 秒才能點一次查詢按鈕，在 Web 接入層限制每個 Session 每分鐘只能查詢一次，還可在數據庫鏈接類庫上做一層控制策略。
多媒體服務工程師最好的情人節禮物會是一個完美的播放器：
- 它可以自助容錯選擇 CDN
- 可以主動預緩存下一分鐘的點播內容
- 可以完成私有解密編碼工作
- 可以和廣告系統解耦獨立加載
- 可以在卡頓時更換線路和存儲日誌
- 廣告日誌和卡頓日誌都低速適時後臺上傳
抓住核心訴求，不該要的東西都不要
群集設計通用規則：前端複製後端拆，實時改異步，三組件互換
前端複製後端拆，實時改異步，IO-算力-空間可互換——要做架構就要上群集，而群集設計調優翻來覆去就是這三板斧。
前端是管道是邏輯，而後端是狀態是數據，所以前端複製後端拆。前端服務器壓力大了就多做水平復制擴容，在網站類應用上，無狀態-會話保持-彈性伸縮等技術應用純熟。
後端要群集化就是多做業務拆分，常見的就是數據庫拆庫拆表拆鍵值，服務拆的越散微操作就越爽，但全局操作開銷更大更難控制。
實時改異步是我學的最後一門 IT 技術，絕大部分“實時操作”都不是業務需求，而是某應用無法看到後端和 Peer 狀態，默認就要實時處理結果了。
CS 模式的實時操作會給支撐服務帶來巨大壓力，Peer 合作的實時操作可能會讓數據申請方等一宿。
架構師將一個無腦大事務拆分成多個小事務，這就是異步架構，但拆分事務就跟拆分數據表一樣，拆散的小事務需要更高業務層級上做全局事務保障。
在群集性能規劃中，網絡和硬盤 IO+CPU 算力+磁盤和內存空間是可以互換的，架構師要完成補不足而損有餘的選型。
比如數據壓縮技術就是用算力資源來置換 IO 和空間，緩存技術是用空間和 IO 來緩解算力壓力，每個新選型都會帶來細節上的萬千變化，但每種變化都是符合自然規律有章可循的。
一個經典微機系統就是中央處理器+主存儲器+IO 設備，這幾個概念居然和群集性能規劃是一一對應。
架構常見技巧就像空中華爾茲一樣自然優雅
理解硬件天性：角色選型時要看硬件的天然特性
別讓硬盤扛性能，別讓內存保持久，別讓網線扛穩定。
架構層軟件技術已經足夠成熟，所謂技術選型不如說是適應場景；在做具體角色選型時，最深度也最易忽視的原則是順應硬件天性。
我的精神導師說過，如果一個服務依賴硬盤，那這個服務就不適合扛性能壓力。
我經常將讀寫引到 /dev/shm，SSD 盤讓很多細節調優聊勝於無，還讓 Fat32 枯木逢春，個別隊列和分佈式存儲在意硬盤的性能力，但都是應用了順序讀寫內容，且不介意磁盤空間浪費。
別讓內存扛持久和別讓網線扛穩定，聽起來很簡單，但新手程序員總會犯低級錯誤，而犯錯早晚要還技術債。
常規例子就是看新手程序是否有捕獲各種異常的習慣，舉個爭議性例子，某些雲服務設計者嘗試給一個進程映射和綁定持久文件系統，請問一段內存如何綁定一塊硬盤？
談到天性，我總是想起流暢奔跑的小波妞
數據的產生和消失：數據不會憑空產生，但會憑空消失
數據不會憑空產生，計算機或者自輸入設備獲取數據，或者自其他數據源導入數據，而且原始數據的轉化規則也要人類來定義。
我們要便捷輕巧安全可靠的獲取數據，就要選好數據源，保障好傳輸路徑，定義好數據變換規則。
在一個數據生命週期內，為了防止數據全部或部分憑空消失，數據的容錯校驗、關聯復原、冷熱備份和安全刪除都要考慮到位。
在生僻業務的規劃實施過程中，沒人告訴我們該有哪些服務，我們只能靠摸透一個又一個訪問邏輯圖和數據生命週期，來摸索群集內有哪些角色和依賴關係。
架構師的核心技能包括畫好訪問邏輯和數據流量圖，因為問題現狀描述清楚了，問題就解決了一多半了。
一個好的業務訪問邏輯圖，不僅僅是幾個圈圈幾條線連起來，其信息量大到包羅訪問過程的所有元素，也要詳略得當高亮關鍵點。
咦？數據被拿走了。是啊，拿走了。好巧。我們還要做點什麼嗎？
各環節都不可盲信：容災設計中都盡人事和聽天命
整個 IT 系統中就沒有可靠的組件，架構師既不能盲目信任撞大運，又不能無限冗餘嚇唬自己，而是在盡人事和聽天命之間做好權衡。
比如 TCP 就是要建立可靠鏈接，而現在做性能優化的時候，大家又嫌 TCP 太過笨重了。
業務應用不可靠，如果該應用能快速重建也不阻塞其他應用，月級偶發的內存洩漏和意外崩潰都是可以接受的。
支撐性服務不可靠，對於大部分業務，預估一年都不丟一次數據，SLA 能到 99.95% 就可以了。
操作系統故障崩潰，現在商用系統內核都很穩定，一般故障都出在硬件驅動兼容性上，或者有些照本宣科的傻瓜亂改默認參數。
網絡不穩定，內網通用的技術方案很成熟，少提複雜需求內網就能很穩定，我們最煩的是單條網線處於半死不活狀態；IDC 的外網 SLA 默認就是 3 個 9，所以我說支撐性服務能到 99.95% 就已經很可靠了。
硬件不穩定，大部分架構師根本不懂硬件，只要不出硬件批次故障，架構師就可以將單點硬件和系統、服務綁在一起做可靠性設計。
人力誤操作，我們招不到不出故障的人，我自己達不到不出錯的標準。只要員工沒有惡意破壞，出了大範圍故障就是群集健壯性設計不到位，別讓操作工給技術總監和架構師頂包。
監控和備份是運維的職責，但架構師需要幫忙確認目的正確性，別備份了半天廢數據，監控只看 telnet80。
幹活的角色和搗亂的角色一樣多，甚至更多
結束語：架構之術繁瑣，架構之道淺顯
本文講的是架構工作的“道”，對於架構之“術”並不提及。不同的業務系統的架構之術完全不同，能拿來彙總借鑑的只有這幾條簡單的道理。
心裡不慌就飛起來吧
如果一個架構師只是炫耀具體優化架構的手法，卻閉口不談選型的道理，他們其實是在簡單用公司業務嘗試賭博。
如果我們有架構之道做思想支撐，即使接手全新業務類型，庖丁可以解牛也可以殺豬，我們一樣能遊刃有餘心裡不慌。
我曾經接手三種生僻晦澀的業務，按照本文的原理去拆解和規劃，就沒有什麼特別難的。
閱讀更多 51CTO傳媒 的文章
