《撇開代碼不說，談談我對架構的6個冷思考》要點：
本文介紹了撇開代碼不說，談談我對架構的6個冷思考，希望對您有用。如果有疑問，可以聯系我們。
計算機是個復雜的機器,相比普通的機器(比如小家電、汽車),它可以在使用過程中對其「工作行為」進行「再定義和場景適配」,以解決不同場景下的人的需求和問題,這種「定義的結果」,對于機器的最終用戶來說,是「應用 / Application」.
對于非計算機相關的普通人而言,即便是有諸多對于職位頭銜的描述：「程序員」、「軟件工程師」、「架構師」、「首席技術官」,也離不開一個潛意識的印象：「做網站的」或者是「修電腦的」.
很多「架構師」,都是從「軟件工程師」開始,不知不覺的變成了一個「架構師」.對于我個人而言,當我還是一個實習生,被「升」為一個部門架構師帶領一些正式員工干活的時候,對「架構師」這個概念居然是一片空白,甚至于不知道這是個「好消息」,還是個「壞消息」,當然也不知道「架構師」是干嘛的.
所以,我一直以最簡單的方式對架構進行定義：架構是一種用計算機解決問題的綜合能力,與頭銜無關.下面我將結合自己的工作經驗,談談這些年來,我對結構的理解.
架構能力并不是與生俱來的,而是和具體經歷強相關的,豐富的經驗是形成架構能力的基礎.
很多時候我們強調「系統性思考」對于架構設計的重要性,希望從方法論上能夠對正在從事或者即將從事架構工作的程序員在專業能力上進行提升.教條式、填鴨式的培訓,是教不出架構能力的.理論的價值是能夠幫助應用理論的人少走一部分的彎路,但不能夠解決眼前的現實問題.
在企業里,架構是一個實踐結合非常緊密的領域,一切以解決實際問題為目標.由于問題是多種多樣的,導致解決的方法也是多種多樣的.踩過的雷,填過的坑,都需要進行總結和抽象,才能提升到架構層的高度,防止重蹈覆轍.
對于一個復雜問題,通常會對復雜問題按照能力領域進行分解,其目的是能夠找到與現有能力相匹配的映射.這個映射,就是解決方案.它,離不開人的「知識型勞動」,主要分解為三個方面：
其中前兩個方面,都提到了「建模」.建模本身是對客觀事物的一種抽象,客觀事物越復雜,那建模的結果變成「盲人摸象」的概率就越高.
然而,「盲人摸象」在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平臺化運營有深入的研究和理解.
文章出處：聊聊架構
轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4444.html
