首席架構師眼裡的架構本質
架構的本質
目前討論架構實操（術）的文章較多，討論架構理念（道）的較少，本文基於作者在大型電商系統架構方面的一些實踐和思考，和大家聊聊架構理念性的東西，希望能夠拋磚引玉，推進大家對架構的認識。
什麼是道，什麼是術？道是事物發展的本質規律，術是事物發展的具體途徑。
規律只有一個，途徑很多，條條大路通羅馬，羅馬是道，大路是術。道為本，術為途，如果事先知道羅馬在哪裡，那麼遍地是路，路路相通。架構也是如此，如果能領悟架構的本質，就不會拘泥於現有的實踐和理論框框，而以最直接的方式解決問題，無招勝有招。
說到這裡，也給大家推薦一個架構交流學習群：835544715，裡面會分享一些資深架構師錄製的視訊錄影：有Spring，MyBatis，Netty原始碼分析，高併發、高效能、分散式、微服務架構的原理，JVM效能優化這些成為架構師必備的知識體系。還能領取免費的學習資源，相信對於已經工作和遇到技術瓶頸的碼友，在這個群裡會有你需要的內容。
本文的內容包括：
架構的本質
架構的服務物件
架構師能力模型
架構境界
架構的本質
任何系統，自然情況下，都是從有序到無序，這是有科學依據的， 按照熱力學第二定律，自然界的一切自發過程都有方向性，一個孤立系統會由有序變為無序，即它的熵會不斷增加，最終寂滅。但生物可以通過和外界互動，主動進行新陳代謝，製造“負熵”來保證自身有序，繼續生存。
同樣，一個軟體系統隨著功能越來越多，呼叫量急劇增長，整個系統逐漸碎片化，越來越無序，最終無法維護和擴充套件，所以系統在一段時間的野蠻生長後，也需要及時干預，避免越來越無序。
架構的本質就是對系統進行有序化重構，不斷減少系統的“熵”，使系統不斷進化。
那架構是如何實現無序到有序的呢？ 基本的手段就是分和合，先把系統打散，然後重新組合。
分的過程是把系統拆分為各個子系統/模組/元件，拆的時候，首先要解決每個元件的定位問題，然後才能劃分彼此的邊界，實現合理的拆分。合就是根據最終要求，把各個分離的元件有機整合在一起，相對來說，第一步的拆分更難。
拆分的結果使開發人員能夠做到業務聚焦、技能聚焦，實現開發敏捷，合的結果是系統變得柔性，可以因需而變，實現業務敏捷。
舉個例子，在Web 1.0時代，一個ASP或JSP頁面裡，HTML和指令碼程式碼混在一起，此時指令碼程式碼越多，系統越混亂（即熵增加），最終連開發者自己都無法理解。此時就需要對系統重新架構，辦法是引入view helper模式，分離HTML和指令碼，HTML成為view，指令碼成為幫助類。然後再簡單整合在一起。通過重新分和合，整個系統層次清晰，職責明確，系統的無序度降低，容易擴充套件。同時不同技能的開發人員，如UED和程式員，可以負責不同部分，有效提高開發效率。
好的架構就像一篇優美的散文，形散神不散，表面看無序，實則高度有序。
架構分類和服務物件
架構一般可分業務架構、應用架構、技術架構，那麼它們分別解決什麼問題，服務於誰呢？ 我們首先看一個系統落地過程：
對於負責開發的人來說，怕的是業務太複雜，程式碼邏輯太亂，超出他能理解的範疇，系統無法維護。因此開發的需求是系統整體概念清晰，容易理解，方便擴充套件。
對於負責執行的機器來說，怕的是業務併發量太大，系統核心資源不夠用（如資料庫連線）。它希望在業務量增加時，系統能夠支援水平擴充套件，支援硬體容錯（如避免單點故障）。
開發的痛點主要由業務架構和應用架構解決，業務架構從概念層面幫助開發理解系統（動態的包括業務流程/節點/輸入輸出，靜態的包括業務域/業務模組/單據模型）。
應用架構從邏輯層面幫助開發落地系統（應用種類/應用形式/資料互動關係/互動方式等），整個系統邏輯上容易理解，最近大家談的比較多的SOA即屬於應用架構的範疇。
機器的痛點主要由技術架構解決，如技術平臺選型（作業系統/中介軟體/裝置等），部署上希望支援多機房，水平擴充套件，無單點等。
強調一下，系統是人的系統，架構首先是為人服務的，業務概念清晰、應用邏輯合理、人好理解是第一位的（即系統有序度高）。現在大家討論更多的是技術架構，如高併發設計，分散式事務處理等，只是因為這個不需要業務上下文背景，比較好相互溝通。具體架構設計時，首先要關注業務架構和應用架構，這個架構新手要特別注意。
架構師能力模型
架構師只做分和合的事情，但綜合能力要求很高，要求內外兼修，下得廚房，上得廳堂，下圖通過典型的架構方式介紹一個架構師的能力要求：
一個駕校教練，必定開車技術好，一個游泳教練，必定游泳水平好，因為這些都是實踐性很強的工作。書上學來終覺淺，梅花香自苦寒來，架構師亦如此，他必定是一個出色的程式設計師，對程式碼和系統有很好的駕駑能力。
在此基礎上，架構師要有技術的廣度（多領域知識），又有深度（技術前瞻），對主流公司的系統設計非常瞭解，知道優劣長短，碰到實際問題，很快有多種方案可供評估。
抽象思維是架構師最重要的能力，架構師要善於把實物概念化並歸類。比如面對一個大型的B2C網站，能夠迅速抽象為採購->運營->前臺搜尋->下單->履單這幾大塊，對系統分而治之，庖丁解牛，早已目無全牛。
抽象思維是往高層次的總結昇華，由實到虛；而透過問題看本質則是由虛到實，往深層次地挖掘。比如看到一段java程式碼，知道它在JVM如何執行；一個跨網路呼叫，知道資料是如何通過各種介質到達目標(作業系統核心/網絡卡埠/電磁介質等）。透過問題看本質使架構師能夠敏銳地發現底層之真實，系統性端到端地思考問題，識別木桶的短板並解決之。
能落地的架構才是好架構，良好的溝通能力確保各方對架構達成共識，願意採取行動；良好的平衡取捨能力確保架構在現有資源約束下是最合理的，理想最終照進現實。
總結下，架構師的能力要求包括：
l 兼具技術的廣度（多領域知識）和深度（技術前瞻）
l 兼具思維的高度（抽象思維）和深度（問題到本質）
l 兼具感性（溝通）和理性（平衡）
架構境界
架構師從境界上由淺到深可以分為四層：第一看山不是山，第二看山是山，第三看山不是山，第四看山是山。
剛接手專案時，對業務不瞭解，時時被業務方冒出的術語弄得一愣一愣的，如果把現有問題比作山，則是橫看成嶺側成峰，根本摸不透，此時看山不是山。
經過業務梳理和對系統深入瞭解，可以設計出一個屌絲的方案，把各個系統串起來，解決當前的問題，對當前這個山能夠看清楚全貌，此時能夠做到看山是山。
通過進一步抽象，發現問題的本質，原來這個問題是共性的，後續還會有很多類似問題。設計上進行總結和昇華，得出一個通用的方案，不光能解決當前的問題，還可以解決潛在的問題。此時看到的已經是問題本質，看山不是山。
最後回到問題本身，去除過度的抽象，給出的設計簡潔明瞭，增之一分嫌肥，減之一分嫌瘦，既解決當前問題，又保留最基本的擴充套件，此時問題還是那個問題，山還是那個山。
第一境界給不出合適方案，不表。
第二境界的方案只解決表面問題，往往設計不夠，碰到其它類似問題或者問題稍微變形，系統需要重新做。
第三境界的方案往往過度設計，太追求通用化會創造出過多抽象，生造概念，理解和實現均困難，此時系統的無序度反而增加，過猶不及。
第四境界的方案，在瞭解問題本質的基礎上，同時考慮現狀，評估未來，不多做，不少做。
佛教講空和色，色即事物現象，空即事物本質，從這個意義上說，第一重境界無色無空，第二重境界過色，第三重境界過空，第四重境界站在色和空之間，既色又空，不執著於當前，不虛無於未來。
不空不色，既空既色，道法自然，本性如來，架構之髓也。
想要學習Java高架構、分散式架構、高可擴充套件、高效能、高併發、效能優化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分散式專案實戰學習架構師視訊免費獲取 架構群：835544715
ofollow,noindex">點選連結加入群聊【JAVA高階架構】：https://jq.qq.com/?_wv=1027&k=5dbERkY