架構的本質

原文地址:http://kb.cnblogs.com/page/540632/

目前討論架構實操(術)的文章較多,討論架構理念(道)的較少,本文基於作者在大型電商系統架構方面的一些實踐和思考,和大家聊聊架構理念性的東西,希望能夠拋磚引玉,推進大家對架構的認識。

  什麼是道,什麼是術?道是事物發展的本質規律,術是事物發展的具體途徑。規律只有一個,途徑很多,條條大路通羅馬,羅馬是道,大路是術。道爲本,術爲途,如果事先知道羅馬在哪裏,那麼遍地是路,路路相通。架構也是如此,如果能領悟架構的本質,就不會拘泥於現有的實踐和理論框框,而以最直接的方式解決問題,無招勝有招。本文的內容包括架構的本質、架構的服務對象、架構師能力模型 、架構境界等。

  架構的本質

  任何系統,自然情況下,都是從有序到無序,這是有科學依據的, 按照熱力學第二定律,自然界的一切自發過程都有方向性,一個孤立系統會由有序變爲無序,即它的熵會不斷增加,最終寂滅。但生物可以通過和外界交互,主動進行新陳代謝,製造 “負熵” 來保證自身有序,繼續生存。

  同樣,一個軟件系統隨着功能越來越多,調用量急劇增長,整個系統逐漸碎片化,越來越無序,最終無法維護和擴展,所以系統在一段時間的野蠻生長後,也需要及時干預,避免越來越無序。

  架構的本質就是對系統進行有序化重構,不斷減少系統的 “熵”,使系統不斷進化。

  那架構是如何實現無序到有序的呢? 基本的手段就是分和合,先把系統打散,然後重新組合。

在首席架構師眼裏,架構的本質是……

  分的過程是把系統拆分爲各個子系統 / 模塊 / 組件,拆的時候,首先要解決每個組件的定位問題,然後才能劃分彼此的邊界,實現合理的拆分。合就是根據最終要求,把各個分離的組件有機整合在一起,相對來說,第一步的拆分更難。

  拆分的結果使開發人員能夠做到業務聚焦、技能聚焦,實現開發敏捷,合的結果是系統變得柔性,可以因需而變,實現業務敏捷。

  舉個例子,在 Web 1.0 時代,一個 ASP 或 JSP 頁面裏,HTML 和腳本代碼混在一起,此時腳本代碼越多,系統越混亂(即熵增加),最終連開發者自己都無法理解。此時就需要對系統重新架構,辦法是引入 view helper 模式,分離 HTML 和腳本,HTML 成爲 view,腳本成爲幫助類。然後再簡單整合在一起。通過重新分和合,整個系統層次清晰,職責明確,系統的無序度降低,容易擴展。同時不同技能的開發人員,如 UED 和程序員,可以負責不同部分,有效提高開發效率。

  好的架構就像一篇優美的散文,形散神不散,表面看無序,實則高度有序。

  架構分類和服務對象

  架構一般可分業務架構、應用架構、技術架構,那麼它們分別解決什麼問題,服務於誰呢? 我們首先看一個系統落地過程:

在首席架構師眼裏,架構的本質是……

  對於負責開發的人來說,怕的是業務太複雜,代碼邏輯太亂,超出他能理解的範疇,系統無法維護。因此開發的需求是系統整體概念清晰,容易理解,方便擴展。

  對於負責運行的機器來說,怕的是業務併發量太大,系統核心資源不夠用(如數據庫連接)。它希望在業務量增加時,系統能夠支持水平擴展,支持硬件容錯(如避免單點故障)。

  開發的痛點主要由業務架構和應用架構解決,業務架構從概念層面幫助開發理解系統(動態的包括業務流程 / 節點 / 輸入輸出,靜態的包括業務域 / 業務模塊 / 單據模型)。

  應用架構從邏輯層面幫助開發落地系統(應用種類 / 應用形式 / 數據交互關係 / 交互方式等),整個系統邏輯上容易理解,最近大家談的比較多的 SOA 即屬於應用架構的範疇。

  機器的痛點主要由技術架構解決,如技術平臺選型(操作系統 / 中間件 / 設備等),部署上希望支持多機房,水平擴展,無單點等。

  強調一下,系統是人的系統,架構首先是爲人服務的,業務概念清晰、應用邏輯合理、人好理解是第一位的(即系統有序度高)。現在大家討論更多的是技術架構,如高併發設計,分佈式事務處理等,只是因爲這個不需要業務上下文背景,比較好相互溝通。具體架構設計時,首先要關注業務架構和應用架構,這個架構新手要特別注意。

  架構師能力模型

  架構師只做分和合的事情,但綜合能力要求很高,要求內外兼修,下得廚房,上得廳堂,下圖通過典型的架構方式介紹一個架構師的能力要求:

在首席架構師眼裏,架構的本質是……

  在此基礎上,架構師要有技術的廣度(多領域知識),又有深度(技術前瞻),對主流公司的系統設計非常瞭解,知道優劣長短,碰到實際問題,很快有多種方案可供評估。

  抽象思維是架構師最重要的能力,架構師要善於把實物概念化並歸類。比如面對一個大型的 B2C 網站,能夠迅速抽象爲採購->運營->前臺搜索->下單->履單這幾大塊,對系統分而治之,庖丁解牛,早已目無全牛。

  抽象思維是往高層次的總結昇華,由實到虛;而透過問題看本質則是由虛到實,往深層次地挖掘。比如看到一段 Java 代碼,知道它在 JVM 如何執行;一個跨網絡調用,知道數據是如何通過各種介質到達目標 (操作系統內核 / 網卡端口 / 電磁介質等)。透過問題看本質使架構師能夠敏銳地發現底層之真實,系統性端到端地思考問題,識別木桶的短板並解決之。

  能落地的架構纔是好架構,良好的溝通能力確保各方對架構達成共識,願意採取行動;良好的平衡取捨能力確保架構在現有資源約束下是最合理的,理想最終照進現實。

  總結下,架構師的能力要求包括:

  1. 兼具技術的廣度(多領域知識)和深度(技術前瞻)

  2. 兼具思維的高度(抽象思維)和深度(問題到本質)

  3. 兼具感性(溝通)和理性(平衡)

  架構境界

  架構師從境界上由淺到深可以分爲四層:第一看山不是山,第二看山是山,第三看山不是山,第四看山是山。

在首席架構師眼裏,架構的本質是……

  剛接手項目時,對業務不瞭解,時時被業務方冒出的術語弄得一愣一愣的,如果把現有問題比作山,則是橫看成嶺側成峯,根本摸不透,此時看山不是山。

  經過業務梳理和對系統深入瞭解,可以設計出一個屌絲的方案,把各個系統串起來,解決當前的問題,對當前這個山能夠看清楚全貌,此時能夠做到看山是山。

  通過進一步抽象,發現問題的本質,原來這個問題是共性的,後續還會有很多類似問題。設計上進行總結和昇華,得出一個通用的方案,不光能解決當前的問題,還可以解決潛在的問題。此時看到的已經是問題本質,看山不是山。

  最後回到問題本身,去除過度的抽象,給出的設計簡潔明瞭,增之一分嫌肥,減之一分嫌瘦,既解決當前問題,又保留最基本的擴展,此時問題還是那個問題,山還是那個山。

  第一境界給不出合適方案,不表。

  第二境界的方案只解決表面問題,往往設計不夠,碰到其它類似問題或者問題稍微變形,系統需要重新做。

  第三境界的方案往往過度設計,太追求通用化會創造出過多抽象,生造概念,理解和實現均困難,此時系統的無序度反而增加,過猶不及。

  第四境界的方案,在瞭解問題本質的基礎上,同時考慮現狀,評估未來,不多做,不少做。

  佛教講空和色,色即事物現象,空即事物本質,從這個意義上說,第一重境界無色無空,第二重境界過色,第三重境界過空,第四重境界站在色和空之間,既色又空,不執着於當前,不虛無於未來。

  不空不色,既空既色,道法自然,本性如來,架構之髓也。


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章