計算機是個複雜的機器，相比普通的機器（比如小家電、汽車），它可以在使用過程中對其「工作行為」進行「再定義和場景適配」，以解決不同場景下的人的需求和問題，這種「定義的結果」，對於機器的終端使用者來說，是「應用 / Application」。

對於非計算機相關的普通人而言，即便是有諸多對於職位頭銜的描述：「程式設計師」、「軟體工程師」、「架構師」、「首席技術官」，也離不開一個潛意識的印象：「做網站的」或者是「修電腦的」。

很多「架構師」，都是從「軟體工程師」開始，不知不覺的變成了一個「架構師」。對於我個人而言，當我還是一個實習生，被「升」為一個部門架構師帶領一些正式員工幹活的時候，對「架構師」這個概念居然是一片空白，甚至於不知道這是個「好訊息」，還是個「壞訊息」，當然也不知道「架構師」是幹嘛的。

所以，我一直以最簡單的方式對架構進行定義：架構是一種用計算機解決問題的綜合能力，與頭銜無關。下面我將結合自己的工作經驗，談談這些年來，我對結構的理解。

架構能力並不是與生俱來的，而是和具體經歷強相關的，豐富的經驗是形成架構能力的基礎。

很多時候我們強調「系統性思考」對於架構設計的重要性，希望從方法論上能夠對正在從事或者即將從事架構工作的程式設計師在專業能力上進行提升。教條式、填鴨式的培訓，是教不出架構能力的。理論的價值是能夠幫助應用理論的人少走一部分的彎路，但不能夠解決眼前的現實問題。

在企業裡，架構是一個實踐結合非常緊密的領域，一切以解決實際問題為目標。由於問題是多種多樣的，導致解決的方法也是多種多樣的。踩過的雷，填過的坑，都需要進行總結和抽象，才能提升到架構層的高度，防止重蹈覆轍。

對於一個複雜問題，通常會對複雜問題按照能力領域進行分解，其目的是能夠找到與現有能力相匹配的對映。這個對映，就是解決方案。它，離不開人的「知識型勞動」，主要分解為三個方面：

1. 對於已知問題的抽象和建模
2. 對於已知能力的抽象和建模
3. 對於解決方案和工具的設計

其中前兩個方面，都提到了「建模」。建模本身是對客觀事物的一種抽象，客觀事物越複雜，那建模的結果變成「盲人摸象」的概率就越高。

然而，「盲人摸象」在IT領域其實不能算是個「貶義詞」，因為這個現象十分的常見。究其原因，解決實際問題資訊系統，更多程度是面向於「典型」應用場景，而不是「任意」應用場景的。

場景即是對客觀事物的認知視角，資訊系統做不到、也不需要對一個完整的客觀事物進行全面（360°無死角）建模。

舉個具體的例子：對於人這個客觀事物，銀行系統裡，可能會關心這個人財務指標，例如「收入」、「支出」和「存款餘額」，但在醫院的重症監護病房裡，可能就會關心這個人的生命指標，例如「血壓」、「心跳」。

從例子裡可以看出，一個面向具體問題的場景化應用系統，都是對一個客體進行「片面的」場景化建模。

說到底，建模是一種抽象能力，具體的說，是人對客觀事物認知結果的理性提煉和總結，不可否認感性的部分太難以刻畫和描述。很符合「莊子·天道」中所述：「意之所隨者，不可以言傳也」。

如果要拿數學語言進行描述「建模的能力」，就是找到一組儘可能少的「特徵向量」去表述這個空間，而找這組「特徵向量」的能力，就是建模的能力。

沒有軟體的計算機，是「無法使用」的，因為沒有辦法幫助我們解決任何問題。計算機原本很「生硬」，無法很「柔軟」的去直接適配所需要解決的問題。

架構的核心工作是「設計」，設計計算機如何按照預期進行工作。

架構設計中，建模的結果，是模型，它有著結構化、稜角分明的特質，因為這是計算機進行計算的最高效的方式：嚴格的告訴我們——兩個數是相等還是不相等，及其衍生。正由於嚴格匹配，所以在很長的一段時間裡，解決方案的制定和後續系統的交付執行，都圍繞著如何嚴格按照實際場景進行模擬和落地。 很少以「按概率成功」對系統的業務功能進行設計和實現，一切都必須「絕對正確」。因為絕大部分的計算機系統，無法理解自然語意。只能根據人為設計的結構化資訊，「按部就班」地完成重複性勞動。

人工智慧、機器學習，在解決自動化建模領域的成熟度還是遠遠達不到人的能力，如果達到了，那麼軟體就不需要人進行「架構設計」了。簡單的從架構設計的結果（當然也是結構化的），生成程式碼，這方面目前的計算機還是有能力勝任的。

任何不符合實際場景的計算結果，使用者都認為是「缺陷 」，而在系統中產生此類異常結果，往往需要「程式設計師」為此承擔相應的責任。吶，回想一下，在沒計算機的時代，反而往往都是店小二算錯了帳自己賠，沒有人會去責怪算盤。這是為什麼，因為算盤足夠簡單，簡單到不需要做任何的監控系統、不需要記錄任何的日誌，連「三下五除二」這樣的操作規則，都已經被社會化學習消除了使用成本。最終，一切出錯的原因只有一個：用鍵盤的人。

是的，計算機系統生來就是是不可靠的，它不可能像「算盤」一樣在執行期不依賴任何的自然資源。斷電了，會引發故障；光纖斷了，會引發故障；磁碟滿了，會引發故障。。。一系列的不確定因素，導致「分散式系統」架構設計比「主機系統」的架構設計複雜的多，原本不需要操心的事情，都需要從更上層的軟體層加以解決了。

所以，當前架構工作的很大一塊，都隨著分散式系統規模的增大而加大了比重。也許，導致世界上最聰明的一夥人都去解決計算機的問題了。

架構既然是個解決方案，自然有很多可以自由選擇的領域，有很多受限的前提條件。這些外圍因素，往往還系統背後的個人、團隊、企業的價值觀、以及非IT能力有關，這是一個很容易被忽視的點。

與人和團隊的關係

架構往往是與個人或者團隊的能力有關的，因為架構前一部分是設計工作，後一部分是程式碼框架的落地工作。可以沒有一個十全十美、滿足各方需求的方案，架構過程中有很多都是妥協的結果，有的是向需求妥協，有的是向運維妥協，有的是向個人英雄主義妥協。另外，絕大部分的選擇都是人作出的，這導致了和人、團隊的水平形成了很大的耦合關係。

早在1895年，法國心理學家勒龐在他的心理學名著「烏合之眾（The Crowd）」就早已經說過：一群精英所作出的群體決定，很有可能是最愚蠢的決定。有時候，技術團隊不能太強調民主；有時候，技術團隊中的強強產生的效果是「1 + 1 \< 1」。一個良好的、強弱結合的組織結構，才有可能孵化出優秀的工具，再進階為一個優秀的產品，也有利於成員梯隊的培養。

團隊越大，一個優秀的架構設計方案被嚴格執行下去的可能性越小。第一，制定方案的人和落地方案的人大多數情況下都有脫節，很多設計精巧的方案細節到了執行者的手裡，會被忽視。第二，為了統一一個團隊的認識結構、設計理念，這部分的培訓成本往往都是各個僱主不願意付出的。第三，方案的描述本省是「不精確」的，還很容易存在文件過期的情況，在軟體及交付的各個環節，任何參與者都有機會以自己的知識背景作為出發點進行理解，並自豪地加上自己的「傑作」。

與企業的價值觀相關

企業的價值觀，最直接的體現，就是企業的投資組合。

在大型的企業裡，軟體產品的採購往往會受制於「採購部」，也會受制於不懂IT的公司級領導所下達的行政干預，有些理由好像聽上去也「很有道理」：採購過為什麼還要採購，要「保護投資」。往往到了這個層面，程式設計師、架構師都紛紛表達了無奈。

軟體，包含程式碼和資料。它不是一個簡單的能夠按照「固定資產折舊」進行的固定資產。它透射的是使用者對客觀世界的認識，也需要隨著對客觀世界認知的變化而變化，因此版本對於軟體來說就是一個時刻認知的快照沉澱。

行業的快速發展，企業的快速發展，勢必推動企業資訊系統的快速發展。對於企業而言，其價值是能夠找到感知行業、感知產品、感知使用者、感知企業內部運營的觸角，每個社會中的實體不管是個人，還是產品都能夠在系統中找到它的影子。

對企業主而言，IT是一個長期的投資行為。陳舊的、不符合時代背景的軟體，是會變成降低企業生產力的絆腳石。

現今任何的計算機高階程式語言，例如Java/C/C++，或者更高層的DSL，都是人與計算機之間的「單向語言」。這些「單向語言」，並非自然語言，大多數由程式設計師編寫，再交由計算機進行執行，在很長的一段時間內，資訊系統都是以這種方式與人進行互動。 （當然，也可以慢慢的等待「Siri」之類的助手長大成人，成為一名架構師，也許那個時候，廣大架構師需要轉行了。）

程式碼是架構實現的核心，通過程式碼可以完成對現實世界的「虛擬化」：

• 概念的虛擬化
• 能力的虛擬化
• 實體的虛擬化
• 記憶的虛擬化
• 協作的虛擬化

通過一些例子，有助於理解：

• 概念的虛擬化：一個業務概念的類定義
• 能力的虛擬化：一個方法對多個輸入資料進行加工並返回結果
• 實體的虛擬化：一個類的例項，即具體的資料
• 記憶的虛擬化：一條關係型資料庫的行記錄
• 協作的虛擬化：遠端方法呼叫

是的，程式碼是計算機的指揮者，程式碼是把人類智慧「賦能」給計算機的一種語言。

程式碼到不到位，寫的好不好，對設計的落地實現會產生很大的影響。

很多時候我們看到的「系統架構圖」，其實是針對目標問題所設計的「計算機領域的解決方案」，是一種設計圖紙。

可以說，「架構工作」不僅要能夠交付「設計圖紙」，還要能夠「建地基、搭房樑」。

• 巨集觀層面：對特定問題，進行解決方案的設計
• 微觀層面：對後續的編碼工作，形成與解決方案核心相一致的程式碼框架

做好「架構工作」有很多非技術的「軟實力」，比如：

• 對於團隊中成員職能的正確定位，知道他們真正擅長什麼
• 深挖至本質的問題分析
• 多視角、符合人性的換位思考
• 捨棄一些力所能及，但影響專注的「雜事」，合理的說「不」
• 具備一定的投資意識，從更高、更長遠的視角，看待投入與產出

在網際網路公司出現之前，有沒有「網際網路公司」呢？他們和現如今的網際網路公司的差別是什麼？

其實是有的，例如「電網」、「電信運營商」、「股份制商業銀行」、「快遞物流公司」。在人類社會中最基本的兩個元素，就是「實體」和「連線」，一切和連線有關的行業，都可以認為是「互聯」，只不過資訊系統在企業中的價值是由「生產關係」決定了其價值。

機器學習能夠幫助架構設計嗎？

機器學習很長一段時間之內都停留在引數調優上，而不具備對於一般事物進行建模的能力。前文也闡述過「概念的虛擬化」和「實體虛擬化」之間的關係，實體虛擬化就是資料，而資料本身已經是類的例項了，

網際網路公司大談「大資料」以及「資料驅動DT」的原因是什麼？

前面提到，資料是對客觀實體的虛擬化，客觀實體並不是無中生有的，他們是自然世界的產物，資料驅動的本質是客觀事物驅動，退一步講，本質仍然是「業務驅動」。當然，打通多個場景化的資料，對客體進行360°的建模，是「大資料」真正價值所在。

需要注意的是，劍總是雙刃的，當在計算機系統這個虛擬世界裡，找到了360°、包含衣食住行的你，生活是便利了，因為可以預測你的需求，不過你的隱私還存在多少？

對開源軟體實施「拿來主義」是否可行？

很多開源軟體，直接的「拿來主義」，會導致「後患無窮」。很大程度上，開原始碼是一個個人、一個團隊整體能力的對映，並且和執行這些程式碼所需要的環境息息相關。開原始碼也是挑人、挑環境的，在一個團隊沒有想匹配的能力進行正確的使用之前，很多時候都是一匹「天生野馬」，在馴服之後才會變成自己的「血汗寶馬」，馴服的過程其實就是和自己團隊以及周邊環境相適配、磨合的過程。

重複造輪子真的是浪費嗎？

一個健康的IT團隊，應當建立起一套評估「現有輪子」是否產生實際效益的體系，比如能夠監控程式碼在生產環境的實際使用率、故障率，適時的下線一些「低效益」的程式碼。不要簡單的否定和阻止「重新造輪子」，這是與企業內部人的能力對齊、外部大環境對齊的過程，更是企業不斷新陳代謝的「投資型基因」。

結構化的資料到底意味著什麼？

所謂結構化，其實是面向資料的下游處理者，可以與其內建的概念（資料模型）進行對映和處理。結構是一種「元資訊」。

舉個具體的例子，一張bitmap圖片，它本身是有結構的。bitmap的圖片是標明瞭每個畫素點上的RGB顏色值具體是多少，這個資料結構，對於圖片瀏覽器來說，是可以識別和解析成為一張人眼能夠識別的圖片的，而瀏覽器本身只負責每個畫素點上的顏色還原。倘若這張圖片裡是一張「使用者」寫實頭像，那麼圖片瀏覽器並不能夠分析出這張頭像具體是哪個自然人，也無法將這張圖片作為一個API的入參，聯合其他該使用者的入參，進行內部業務邏輯的處理。

王延炯，密碼學博士，現任普元資訊軟體產品部主任架構師，微博帳號@SINeWang。畢業於北京郵電大學網路與交換技術國家重點實驗室網路安全中心。曾先後任職於西門子（中國）研究院、普元資訊、垂直行業網際網路公司。帶領團隊交付了移動、金融、電信、廣電、移動網際網路等多個行業、眾多IT系統的諮詢、設計、研發、實施、維護、優化工作。對分散式架構，企業架構，以及企業IT平臺化運營有深入的研究和理解。

文章出處：聊聊架構