關於架構，都有什麼可以聊的？

作者｜王概凱

編輯｜小智

在軟體行業，架構師和工程師就類似於上帝，創建出形形色色的軟體產品來服務於人類。要想當好這個角色，架構師自然也需要具備某種上帝的視角，來觀察並表達這個世界。什麼是架構、怎樣做好架構、軟體架構如何落地、如何寫好程序、技術、業務和架構之間的關係如何？你還想了解什麼？

什麼是架構？

一直以來，在軟體行業，對於什麼是架構，都有很多的爭論，每個人都有自己的理解。甚至於很多架構師一說架構，就開始談論什麼應用架構、硬體架構、數據架構等等。我曾經也到處尋找過架構的定義，請教過很多人，結果發現，沒有大家都認可的定義。

架構實際上解決的是人的問題，架構的產出物就是對問題的分析，以及解決問題的方案。它包括：拆分的原則以及理由，溝通合并的原則以及理由，以及拆分，拆分出來的各個部分和合并所對應的角色和所需要的核心能力等。

1、根據要解決的問題，對目標系統的邊界進行界定。

2、對目標系統按某個原則的進行切分。切分的原則，要便於不同的角色，對切分出來的部分，並行或串列開展工作，一般並行才能減少時間。並對這些切分出來的部分，設立溝通機制。

3、根據 2，使得這些部分之間能夠進行有機的聯繫，合并組裝成為一個整體，完成目標系統的所有工作。

這就是架構。

為了讓你更好地從本源上理解「架構」這個概念，我們耗時接近兩年，打磨一本名為《聊聊架構》的技術書籍。花上五分鐘，讀完本文，再決定是否要入手這本可能無法成為暢銷書的技術書。

認識概念是理解架構的基礎

架構實際上解決的是人的問題，而概念是人認識這個世界的基礎，自然概念的認識就非常的重要。

每個概念實際上所解決的，還是人遇到的某個特定的問題，我們把解決問題的解決方案，給定了一個名字，這個名字就是對應的某個特定的概念。對於概念這個詞本身，為了統一指代這些名字，我們稱起這類作用的名字稱為「概念」。我們前文討論的「架構」也是是同樣的一個特定概念，這裡不再詳述。

要做好架構首先必須具備的能力是能夠正確的認識概念，能夠發現概念背後所代表的問題，進而才能夠認識目標領域所需要解決的問題。

事實上，這一能力，在任何一個領域都是適用的，比如我們如果想要學習一項新的技術，如 Hibernate、Spring、PhotoShop、WWW、Internet 等等，如果知道這些概念所要解決的問題，學習這些新的技術或者概念就會如虎添翼，快速的入手；學習一個新的領域，也會非常的快速有效；使用這些概念來解釋問題，甚至發明新的概念都是很容易的事。

為什麼強調這個？因為做架構的時候，很多時候都是在一個新的領域解決問題，必須要快速進入並掌握這個領域，然後才能夠正確的解決問題。

如何做好架構？

第一、識別問題，找到問題的主體

如果把真正的問題找到，那麼問題就已經解決了 80% 了。這個能力基本上就決定了架構師的水平。找出問題的主體，是做架構的首要問題。這也是前面強調的，我們要解決的問題，一定都是人的問題。

更進一步，作為軟體工程師或者架構師，我們大部分時候是要去解決別人的問題，「別人」是誰，是值得好好思考的。再進一步，我們一定要明白，任何找上架構師的問題，絕對都不是真正的問題。為什麼呢? 因為如果是真正的問題的話，提問題過來的人肯定都能夠自己解決了，不需要找架構師。架構師都要有這個自覺：發現問題永遠都比解決問題來的更加重要。

一般來說，從問題暴露的點，一點點去溯源查找，一定會找出來誰的問題，以及是什麼問題。最壞情況就是當我們時間或者能力有限，實在是無法定位出是誰的問題的時候，比如系統出故障，也就意味著我們無法根本解決問題。這時最好的辦法就是去降低問題發生所帶來的成本，盡量去隔離問題影響的範圍。給我留出時間和空間去識別真正的問題。

總結一下，要正確的認識問題，需要問兩個問題：

這是誰的問題？

有什麼問題？

當得到的回答是支支吾吾的時候，我們就知道正確的方向在哪兒，以及需要做哪些事了。以我的經驗，問題 1 會花比較多的時間，也是支支吾吾最多的地方，因為架構要解決的問題都是人的問題。但是一旦確定了答案，問題 2 就會變得非常容易。可以這樣說，架構師的能力大部分會體現在問題 1 的識別上。

第二、架構切分，本質上是利益的調整

在識別出是誰的問題之後，會發現，在大部分情況下，問題都迎刃而解，不需要做額外的動作。但總還有一部分確實是有問題的，需要做調整，那麼就必須要有所動作，做相應的調整。這個調整就是架構的切分。簡單來說：

1、架構的切分的導火索是人的負載太重。

2、架構的切分實際就是對 stakeholder 的利益進行切分或合并，使得每個 stakeholder 的權責是對等的，每個 stakeholder 可以為自己的利益負責。

3、架構切分的最終結果都會體現在組織架構上，只有這樣才能夠讓架構落地並推進。

4、架構切分的結果一定是一個樹狀，這也是為什麼會產生分層。層數越多溝通越多，效率越低，分層要越少越好。儘可能變成一顆平衡樹，才能讓整個系統的效率最大化。

如何做架構切分？

切分就是利益的調整

我們要非常的清楚，所有的切分調整，都是對相關人的利益的調整。為什麼這麼說呢，因為維護自己的利益，是每個人的本性，是在骨子裡面的，我們不能逃避這一點。我們以第一篇文章裡面的例子為例來做解釋。

為什麼需要切分？

當人們認識到要主動的去切分一個系統的時候，毫無疑問，我們不能忘掉利益這個原動力。所有的切分決策都不能夠違背這一點，這是大方向。結合前一篇「識別問題」，一旦確定了問題的主體，那麼系統的利益相關人（用現代管理學語言叫：stockholder）就確定了下來。所發現的問題，會有幾種情況：

某個或者某些利益相關人負載太重。

時間上的負載太重。

空間上的負載太重，本質上還是時間上的負載太重。

某個或者某些利益相關人的權利和義務不對等。

總結：

架構的切分的導火索是人的負載太重。

架構的切分實際就是對 stakeholder 的利益進行切分或合并，使得每個 stakeholder 的權責是對等的，每個 stakeholder 可以為自己的利益負責。

架構切分的最終結果都會體現在組織架構上，只有這樣才能夠讓架構落地並推進。

架構切分的結果一定是一個樹狀，這也是為什麼會產生分層。層數越多溝通越多，效率越低，分層要越少越好。儘可能變成一顆平衡樹，才能讓整個系統的效率最大化。

什麼是軟體？

軟體的歷史，實際上可以說是用機器模擬人的歷史。不管大家（包括在這個歷史過程中的參與者）有沒有意識到，我們都有意無意的在計算機上模仿人類的行為。從馮諾依曼結構開始，程序邏輯開始脫離硬體，採用二進位編碼。加上存儲，配合輸入輸出，一個簡化的大腦就出現了。

軟硬體兩者一結合，一個可編程的大腦出現了，這也是現在為什麼我們把計算機叫做電腦。在硬體上編寫出的程序，就是軟體，是用來控制硬體的行為的。

人們越來越願意把原來只有人才能做的事情，交給計算機來做。結果就導致軟體越來越豐富，能夠做的事情也越來越多，成本也越來越低。

隨著軟體的規模的變大，做好一個軟體也變得越來越難了。早期的程序員寫程序，主要是為了幫助自己研究課題。這些程序員熟練了之後，提高了自己的生產力，並發現還可以幫助別人寫程序，慢慢軟體就變成了一個獨立的行業。程序從早期由一個人完成，也逐漸變成了由很多不同角色的人共同合作來完成。

如同前面描述的架構的定義，軟體架構的出現也是同樣的。一開始是懵懵懂懂的去寫軟體，後來慢慢的就有意識的去切分，演變成了不同的架構。這個背後的動力也是一樣的，就是提升參與的人的利益，降低成本。導火索也是軟體工程師的任務太重，我們需要把很多工作拆分出來。拆分的原則也是一樣的，如何讓權責一致。同樣，這個拆分也是需要組織架構的調整，來保證架構的落地。

所以，軟體的本質，其實就是通過把人類的日常工作生活虛擬化，減少成本，提升單個人員的生產力，提升人類自己的利益。

軟體架構要解決什麼問題？

如前所述，軟體實際上就是把現實生活模擬到計算機中，並且軟體是需要在計算機的硬體中運行起來的。要做到這一點需要解決兩個問題：

一、業務問題

具體的現實生活狀態下，沒有軟體的時候，所解決的問題的主體是誰，解決的是什麼問題，是如何解決，如何運作的？

二、計算機問題

如何把現實生活用軟體來模擬？

模擬出來的軟體，需要哪些硬體設施才能夠滿足要求？ 並且當訪問量越來越大的時候，軟體能否支持硬體慢慢長大，性能線性擴展？

因為硬體是可能會失效的，軟體如何在硬體失效的情況下，仍然能夠保證可用性，讓用戶能夠不中斷的訪問軟體提供的服務？

怎麼收集軟體產生的數據，為下一階段的工作提供依據？

究竟哪些算是軟體架構呢？

軟體因為流量增大而分拆成不同的運行單元，在不同的機器上部署所形成的架構，屬於軟體架構。每個運行單元為了讓不同角色的人，比如前端，業務，數據存儲等能夠並行工作，所分成的代碼架構，也屬於軟體架構。

所以當我們說軟體架構的時候，我們一定要講清楚，究竟說的是部署的架構，還是代碼的架構。軟體架構的落地，需要軟體的組織架構和流程來保障，離開了這個，軟體架構是一句空話。

另外很多人講，架構是進化出來的。架構實際上是在量不斷的增大，超過了單台伺服器的容量，逐漸的分拆，同時導致超過單個人員的能力，工作人員不斷的增多，工作內容不斷的分拆形成的。這本身就是架構的意義所在。不管怎麼分拆，所達到的目標沒有任何變化，就是完成業務在計算機中的虛擬化。

架構師沒有話語權，還架什麼構！

架構師是要去平衡別人的利益，甚至會調整別人的利益的。一旦架構師是全心全意的為別人的利益服務，自然而然的架構師就擁有了強有力的影響力，肯定會是一個 leader。但是只是民意上的 leader 是沒有用的，不能完全發揮架構師的能量。

架構師必須是一個組織的領導人，有權利調動這個組織的架構，才能夠更好的發揮架構師的作用，更好的把利益的調整落到實處。所以很多公司設了很多架構師的職位，但是並不具備調動組織架構的權利，那麼這個架構師的職位一定是形同虛設。

架構師只能夠通過建立某些流程來行使架構師的權利，比如強制架構 review，反而會造成很多內部不必要的衝突，最終都會導致這些流程流於形式，得不償失。相信很多人都已經經歷過這些，但似乎很少有人會去探討這是為什麼。

反過來，具備架構師能力的組織領導人，一定是一個很好的領導，這個組織一定是很健康向上的，因為每個人的權利和義務就是比較均等的。並且這類領導對於組織成員權利和義務的對等狀況會非常的敏感，會及時的調整組織架構，在問題發生之前就解決了。

這樣這個組織就會具備更好的抗壓能力，能夠更好的為這個組織的客戶服務，這個組織的成員內心一定都是比較平衡的，每個人的能力都能夠得到比較好的發展。當然讀者可能又會說，這不是管理學的東西嗎？ 是的，但也是架構的問題。

所有架構的核心就是組織架構。或者也可以這樣說，一個合格的組織領導人，一定必須是一個合格的架構師。

架構師和技術？

很多人會問，特別是做軟體行業的，架構師是不是需要學習技術，甚至是學習語言？ 如果一個架構師還有這個困擾—就如問這個問題的人，說明目前還不具備做架構師的能力，或者說還不具備對自己領域 -- 哪怕是技術領域 -- 的自信，更別談業務領域了。

因為技術和語言，都是用來識別和解決所服務的主體的權責，保護並提升所服務的主體的權利的。特別對於軟體領域來說，必須明白軟體本身是怎麼回事，解決什麼問題，還要解決軟體所服務的對象的領域本身是怎麼回事，解決什麼問題，這就要求更高了。

語言和技術應該是隨手拈來才對，對於架構師這些都是工具。學習技術和語言，如果明白了這些技術和語言要解決的是誰的問題，什麼問題，學起來是非常快，非常容易的。

同樣，採用哪個技術或者語言，只要某個技術或語言所解決的問題的主體，以及所解決的問題，和自己所面對的問題的主體和這個主體要解決的問題，這兩者是匹配的，那麼這個方案是成本是最低的，所採用的技術或者語言就是靠譜的。

沒有趁手的工具或語言的情況下，自己設計一個也不難，因為很清楚自己要什麼。要不要自己做，無非是一個成本問題，也就是利益問題。並且從這個思路下去，選擇的工具和語言肯定都是最簡單的，成本是最低的。因為架構畢竟解決的還是人的利益問題，成本越低越好，這個成本當然是長期總體成本，不是眼前的短期成本。

從架構的角度看如何寫好代碼

我們經常會聽說，重寫代碼，推翻原有架構，重新設計等等說法，來說明架構的進化。這實際上就是當初為了完成任務，沒有充分思考所帶來的後果。這也並不是架構進化的事情，而是個人對問題領域的逐漸深入理解的過程。所以有必要再討論一下，代碼的架構應該是怎樣的。

軟體實際上是對現實生活的模擬，虛擬化。這是一個非常重要的前提，直接決定了我們的代碼應該分為幾部分。結合每個部署單元所承擔的責任，可以明確的拆分為兩個不同的責任：

表達業務邏輯的代碼。很多人把這部分叫做 Domain Logic，或者叫 Domain Model。這部分實際是來源於生活的，必須保持和現實生活中的切分一致，並非人為的抽象而成。

對用戶提供訪問並保存業務邏輯運行結果的代碼。計算機的狀態保存有一個缺陷，本機保留業務運行結果有很大的問題，一般都在外存儲設備上保存，也便於擴展。

我們真正想快速的完成代碼工作，就要克服自己對時間的恐懼，真正的去研究業務的問題，相關 stakeholder 的利益，把這個變成我們的習慣。寫代碼的時候讓該出現邏輯的地方出現邏輯，讓不該出現的地方不能出現。一旦不該出現的地方出現了邏輯，那麼要馬上意識到，這個地方是一個坑，這個問題一定和業務的分析不透徹有關係。

更多相關內容，可參考本文：從架構的角度看如何寫好代碼？

理清技術、業務和架構的關係

在很多人的概念裡面，架構和技術實際上是等同的。學會了幾種技術，就認為自己是架構師了，甚至是學習的技術越多，就覺得自己的水平越高。這樣實際上是對自己很不負責任的。要知道任何技術都是為了解決某種問題而存在的，學會了技術，並不代表自己能夠解決問題，這一點非常的重要。

學會的技術的多少，所帶來的差別只是自己解決問題的手段多了罷了。但是手段多了就一定是好事嗎？ 很多時候，學習的技術越多，越不知道採用哪種技術好，所謂「亂花漸欲迷人眼"。

還有另一種很普遍的觀點：技術人普遍看不起業務，認為技術更高端，而業務太低端，並且業務往往喜歡給技術挖坑。業務則覺得技術眼光高，但是實際解決不了問題，總是理解有偏差，但是又無可奈何，因為自己不會。

技術與架構，以及與業務之間的關係

技術總是在人類解決對業務的要求不斷提高的情況下產生，目的也是為了獲取更大更好的利益。所以：

技術是為了解決業務的問題而產生的，沒有了業務，技術就沒有了存在的前提。

有了更好的技術，效率更差的技術，就會慢慢的被淘汰，消失，一切都遵從人類的利益訴求——也就是業務。有人會問，不用鑽木取火了，但是弓弦加速轉動木棍還可以用啊？ 沒錯，因為弓弦轉動木棍這個技術，不是來生火的，是用來加速木棍轉動的，所解決的問題不一樣。但是兩種不同的技術，合理結合起來，會更好更有效率的解決業務問題。

所以技術與技術之間，有兩種關係：

在解決同一個業務問題的前提下，更高效，更低成本的技術，會淘汰低效，高成本的技術。這是人類利益訴求所決定的。

一般剛開始解決根本問題的技術（鑽木取火）的效率是比較低的，只是把不可能變成了可能（從這一點上來說，技術才是業務的 enabler）。然後就會有提高效率的需求出現，要求改進這個技術。這個技術的低效率部分就會被其他人（或者技術發明人自己）加以改進，這部分就會形成新的技術。

技術人員和業務人員的關係

技術人員很多時候關心的技術，和業務的主要目標往往不是直接對應的，業務也是負責某一部分的業務，也不是和業務的主要目標直接對應的，都是樹的分支節點（上文已經解釋了為何會發生這種情況）。只有直接解決業務問題的那個技術（或業務）-- 樹的根節點 -- 會和業務直接相關。所以一旦產生衝突，一般必須兩個根節點（一般都是領導）碰面才能解決問題。

在軟體行業，這個根節點技術就是軟體。這也是為什麼架構師要認識什麼叫軟體，軟體解決誰的問題，什麼問題，軟體本身又是怎麼分拆的，才能夠更好的組合不同的技術，完成業務的目標。而軟體裡面和業務直接相關的，只有 Business Domain 這一部分。

用人來打比方，Business Domain 相當於人的大腦，而 Service，Repository，Glue Code 等部分所採用的技術，全部都是計算機自己領域的技術，都是為了能夠讓程序跑起來，相當於人的四肢。我們大部分開發人員的工作主要專註於四肢部分。

很多架構師、技術人員主要專註於計算機相關的技術，忽略了業務本身，甚至看不起業務，這也是為什麼技術總是和業務衝突的原因。

架構師應該承擔起解決業務問題的這個角色來，專註於 Business Domain 和軟體本身的架構，讓技術人員致力於為業務在計算機中跑起來而努力。只有把這兩者很好的結合起來，才能更好地完成業務的目標，才會讓軟體更好地服務於大家。最終一定會得到一個很好的軟體架構，令軟體開發團隊和業務部門都能夠很好地開展工作並降低成本。

只有把這兩者很好的結合起來，才能更好地完成業務的目標，才會讓軟體更好地服務於大家。最終一定會得到一個很好的軟體架構，令軟體開發團隊和業務部門都能夠很好地開展工作並降低成本。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！