邏輯架構和物理架構

　　在實際工作中，我們經常聽到“架構”和“架構師”這樣的名詞，並不新鮮，但是總讓很多剛入門的人感覺很神祕，甚至是高深莫測。很少有人對“架構”有全面的瞭解和認識能並說清楚架構是什麼，更談不上掌握了。事實上，也只有極少數人能成為或者被冠以“架構師”這樣的title。為此，筆者總結了對架構的一些理解，希望能夠補充很多初入門的人在這方面認識上的不足，糾正一些誤解。高手和老鳥就直接跳過吧。

　架構的分類

　　對於“架構”來講，理論上劃分了5種架構檢視，分別是：邏輯架構、開發架構、執行架構、物理架構、資料架構。根據名字，大家都可能大概能猜到其側重點和含義。這裡先用通俗的文字簡單介紹下，便於大家理解，大家可以不必糾結概念和這些理論。

　　邏輯架構：邏輯架構關注的是功能，包含使用者直接可見的功能，還有系統中隱含的功能。或者更加通俗來描述，邏輯架構更偏向我們日常所理解的“分層”，把一個專案分為“表示層、業務邏輯層、資料訪問層”這樣經典的“三層架構”。

　　開發架構：開發架構則更關注程式包，不僅僅是我們自己寫的程式，還包括應用程式依賴的SDK、第三方類庫、中間價等。尤其是像目前主流的Java、.NET等依靠虛擬機器的語言和平臺，以及主流的基於資料庫的應用，都會比較關注。和邏輯架構有緊密的關聯。

　　執行架構：顧名思義，更關注的是應用程式執行中可能出現的一些問題。例如併發帶來的問題，比較常見的“執行緒同步”問題、死鎖問題、物件建立和銷燬（生命週期管理）問題等等。開發架構，更關注的是飛機起飛之前的一些準備工作，在靜止狀態下就能規劃好做好的，而執行架構，更多考慮的是飛機起飛之後可能發生的一些問題。

　　物理架構：物理架構，更關注的系統、網路、伺服器等基礎設施。例如：如何通過伺服器部署和配置網路環境，來實現應用程式的“可伸縮性、高可用性”。或者舉一個實際的例子，如何通過設計基礎設施的架構，來保障網站能支援同時10W人線上、7*24小時提供服務，當超過10W人或者低於10W人線上時，可以很方便的調整部署架構來支撐。

　　資料架構：資料架構，更關注的是資料持久化和儲存層面的問題，也可能會包括資料的分佈、複製、同步等問題。更貼切來講，如何選擇需要的關係型資料庫、流行的NOSQL，如何保障資料儲存層面的效能、高可用性、災備等等。很多時候，和物理架構是有緊密聯絡的，但它更關注資料儲存層面的，物理架構更關注整個基礎設施部署層面。

　　上面講了那麼多，相信國內很少有公司是嚴格按照這五種檢視去分工和設計的。其實在筆者眼中，架構大致分為兩種：軟體架構、系統架構。前三種檢視，可以歸納為軟體架構，而後兩種架構，則歸為系統架構。這也比較符合國內大部分中小型網際網路公司的現狀。

　　根據應用特性的不同，關注側重點可能不同。例如，某些門戶類的網際網路應用，讀多寫少而且業務相對比較簡單，則更加關注“高效能、可伸縮性、可用性”等方面。對於更加複雜的應用，例如電商類大規模交易型的應用，對每個層面和每個環節都會比較關注。對於業務型的系統，例如一些生產型企業使用的ERP，或者僅供企業內部使用的一些MIS、OA應用，通常更關注功能和複雜的業務和實現和擴充套件，而對效能等方面又可能不要太高，這類應用則更關注純軟體架構層面。這裡，不展開做具體討論。所以很多時候，架構師也需要是一個團隊，而不是一個人“全棧”。

　架構設計到底是什麼

　　在長期的技術招聘面試中，我發現在很多人眼中，架構就是分層，架構設計就是“三層架構”（或者四層、五層...反正分層越多就說明專案越複雜而且架構就越牛），或許是受到諸如PetShop之類的示例專案的影響，這裡暫時不去追究原因了。

　　之前已經糾正過很多人的誤解-架構不只是軟體架構。說一下通俗點的理解：

　　軟體架構就是實用而且優雅的設計，它不在於分多少層，或者應用了多少種設計模式/架構模式等。它應該是以滿足實現使用者需求為前提，以開發人員普遍可接受為根本的，而且要符合系統特性和業務發展需要的，從軟體設計的角度，能夠達到層次清晰、可維護、可重用、可擴充套件...就非常優秀了，無需刻意去糾結分了多少層，是否使用了什麼模式，有多麼抽象等。以物件導向設計為例，基本目標是“高內聚、低耦合”，為此我們可能會遵循一些常見的設計原則（例如經典的SOLID設計原則）。最後糾正一點，通常我們所說的模式，其實又分為很多種，並不是僅僅指的是“設計模式”（設計模式也有千千萬，並不是只有常見的GOF 23種設計模式）。通常包括：企業架構模式、設計模式、SOA模式、企業整合模式等等。

　　強調一下，架構要講求“實用”，而且開發人員普遍可接受，要符合現狀的。否則，再“優雅”的設計，都會淪為高成本的“花架子”，生搬硬套和過度設計只會讓專案“流產”。

　關於Tier和Layer

　　筆者曾多次在一些技術社群和論壇看到一些關於Tier和Layer的爭論，眾說紛紜。其實最容易被廣泛認可和接受的理解就是：Tier通常指的是物理上的分層，由執行同樣功能的一臺（或者一組）伺服器定義。而Layer通常指的是邏輯上的分層，對於程式碼的組織，例如：我們通常提到的“業務邏輯層，表現層，資料訪問層”等等。

　　Tier指程式碼執行的位置，多個Layer可以執行在同一個Tier上的，不同的Layer也可以執行在不同的Tier上，當然，前提是應用程式本身支援這種架構。以J2EE和.NET平臺為例，大多數時候，不同的Layer之間都是直接通過DLL或者JAR包引用來完成呼叫的（例如：業務邏輯層需要引用資料訪問層），這樣部署的時候，也只能將多個Layer同時部署在一臺伺服器上。相反，不同的Layer之間如果是通過RPC的方式來實現通訊呼叫的，部署的時候，便可以將不同的Layer部署在不同的伺服器上面，這也是很常見的解耦設計。

　　如下圖所示：

　　順便再糾正一點，很多人問“到底什麼是web伺服器，什麼是應用伺服器”。這個恐怕沒有標準答案的。有些人可能覺得，處理靜態資源的就是web伺服器，處理動態請求的就是應用伺服器，這其實是不準確的。以網際網路領域典型的SOA架構為例，上層Web應用所在的伺服器，可以叫web伺服器，web應用僅僅負責處理輸入/輸出，而提供服務宿主的伺服器可以稱為應用伺服器（也包含對業務邏輯和資料訪問的處理）。當然，服務的宿主方式可以有很多中，可以是系統服務，是可執行程式，是web應用，是Socket網路服務...

　邏輯分層和物理分層的好處

　　邏輯分層的好處：

1. 程式碼組織更清晰
2. 更易於維護
3. 更好的程式碼重用性
4. 更好的團隊開發體驗性
5. 更高的程式碼清晰度

　　物理分層的好處：

1. 效能
2. 可伸縮性
3. 容錯性
4. 安全性

　架構師的分類

　　架構師往往是很多開發人員嚮往的職業，也不是像很多人想象中的那樣（畫一下PPT或者UML草圖，然後交給程式設計師們去實現，然後自己就自由玩耍了）。國內很多公司，是沒有架構師這種崗位定義的，通常是由技術優秀和經驗比較豐富的開發人員擔任，身兼多職的情況也並不少見（我見過很多小公司的骨幹人員是身兼技術主管、系統分析師、專案經理、架構師、核心開發人員...）。值得糾正的就是，架構師和系統分析師不同，系統分析師更側重在專案早期的需求分析。而架構師，一般貫穿整個軟體開發週期，與專案經理也是相輔相成的。微軟對於架構師，又分為：軟體架構師、系統架構師、解決方案架構師、企業架構師等。而其它一些廠商，可能又會劃分:技術架構師、業務架構師、網路架構師、安全架構師、SOA架構師......

　　大家不必對這些概念太糾結。按照筆者的理解，國內大網際網路公司裡，架構師一般只會分2-3個方向：軟體架構師和系統架構師（有些企業叫運維架構師），有些企業對於比較資深DBA而且懂整個系統架構的，還會分出所謂的“資料架構師”。至於具體Title，大可不必糾結，只需瞭解自己的興趣，知曉了大致發展和定位，然後朝該方向努力即可。對於程式設計師而言，最基本的還是先寫出高質量的程式碼，在實戰中逐步提升自己設計思維。

　　限於筆者水平和理解有限，文中全部文字和描述等全憑筆者記憶和理解寫出，難免出現錯誤，請熱心的讀者及時批評和指正。

　　由於時間有限，部分圖片筆者畫的比較粗糙，也請讀者諒解。