工作12年，談IT架構的本質：我的五點感悟

科技 02-18

前言

架構師是個無趣的工作

老僧三十年前未參禪時，見山是山，見水是水。

及至後來，親見知識，有個入出，見山不是山，見水不是水。

而今得個休歇處，依前見山只是山，見水只是水。

參禪的三重境界在IT技術圈同樣適用，初學者感嘆每個產品都如此精妙絕倫，追逐著最強的IDE；老司機喜歡自比管樂指點江山，嘲諷著最好的語言；當一切回歸平淡，搞IT就是一份思想延伸和語言翻譯工作；其中技術架構師就是一份古樸甚至無趣的工作。

我將架構師的工作總結出五條核心道理，這五條經驗簡單直白又深奧通透，算是對我十二年IT工作的一個總結。

配圖說明：架構技術像機器人哄小孩一樣簡單

1. 需求優化最重要

少查少寫少依賴，Less is more

一個IT系統是多角色多模塊分層分級的，像OSI模型上層應用簡單依賴下層支撐，SOA設計中同級角色也只看對方的介面。

各角色分工明確方便快速實現業務，但是給架構優化也埋下大坑，底層的盲目支撐是巨大資源浪費，平級調度協作也沒任何彈性。前端一個小邏輯需求會導致後端大規模聯動，不同服務也沒許可權理解對方的內存數據，各個角色的工程師都只看自己的工作範圍，這是正常又無奈的現狀。

我們要搞架構設計最重要的就是砍需求，將上層應用的需求優化刪減，讓同級的業務能容錯。上層需求優化，即前端對後端少輸入少查詢多容錯，而同級容錯可以看做應用間的需求優化，比如兩個服務可以冪等重試就是好解耦，而A系統會等B系統等到死鎖就是架構悲劇。

某電商ERP系統的用戶點一次查詢按鈕，後台系統就鎖庫查詢一次；實操過程中系統越慢用戶就重複點查詢按鈕，而並行查詢越多後台速度就更慢。這種環境要搞架構優化，首先要理解自然人並不要求實時數據，ERP客戶端限制每15秒才能點一次查詢按鈕，在Web接入層限制每個Session每分鐘只能查詢一次，還可在資料庫鏈接類庫上做一層控制策略。

多媒體服務工程師最好的情人節禮物會是一個完美的播放器；它可以自助容錯選擇CDN，可以主動預緩存下一分鐘的點播內容，可以完成私有解密編碼工作，可以和廣告系統解耦獨立載入，可以在卡頓時更換線路和存儲日誌，廣告日誌和卡頓日誌都低速適時後台上傳。

配圖說明：抓住核心訴求，不該要的東西都不要

2.群集設計通用規則

前段複製後端拆，實時改非同步，三組件互換

前端複製後端拆，實時改非同步，IO-算力-空間可互換——要做架構就要上群集，而群集設計調優翻來覆去就是這三板斧：

前端是管道是邏輯，而後端是狀態是數據，所以前端複製後端拆。前端伺服器壓力大了就多做水平複製擴容，在網站類應用上，無狀態-會話保持-彈性伸縮等技術應用純熟。後端要群集化就是多做業務拆分，常見的就是資料庫拆庫拆表拆鍵值，服務拆的越散微操作就越爽，但全局操作開銷更大更難控制。

實時改非同步是我學的最後一門IT技術，絕大部分「實時操作」都不是業務需求，而是某應用無法看到後端和Peer狀態，默認就要實時處理結果了。CS模式的實時操作會給支撐服務帶來巨大壓力，Peer合作的實時操作可能會讓數據申請方等一宿。架構師將一個無腦大事務拆分成多個小事務，這就是非同步架構，但拆分事務就跟拆分數據表一樣，拆散的小事務需要更高業務層級上做全局事務保障。

在群集性能規劃中，網路和硬碟IO CPU算力磁碟和內存空間是可以互換的，架構師要完成補不足而損有餘的選型。比如數據壓縮技術就是用算力資源來置換IO和空間，緩存技術是用空間和IO來緩解算力壓力，每個新選型都會帶來細節上的萬千變化，但每種變化都是符合自然規律有章可循的。一個經典微機系統就是中央處理器主存儲器 IO設備，這幾個概念居然和群集性能規劃是一一對應。