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

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

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

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

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

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

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

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

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

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

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

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

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

由於角色和分工不同,軟體架構是一個複雜的整體，軟體架構工程師不可能在一個視角、一下子講清楚，而利用多重軟體架構檢視的方法，可以一次只圍繞少數概念和技術展開，分別著重研究軟體架構的不同方面，使問題得以清晰公和簡化，利於軟體架構工程師完成架構設計工作。

因此軟體架構的每個檢視分別關注不同的方面，針對不同的目標和用途。目前常用架構設計五檢視方法進行軟體架構描述。它們分別是邏輯架構、開發架構、執行架構、物理架構和資料架構。

邏輯架構的設計著重考慮功能需求，系統應當向用戶提供什麼樣的服務，關注點主要是行為或職責的劃分。邏輯架構關注的功能，不僅包括使用者可見的功能，還應當包括為實現使用者功能而必須提供的輔助功能。邏輯架構的靜態方面是抽象職責的劃分，動態方面是承擔不同職責的邏輯單元之間的互動與協作。

開發架構的設計著重考慮開發期質量屬性，關注點是在軟體開發環境中軟體模組（包）的實際組織方式，具體涉及源程式檔案、配置檔案、源程式包、編譯打包後的目標檔案、直接使用的第三方SDK/框架/類庫、以及開發的系統將運行於其上的系統軟體或中介軟體。

執行架構的設計著重考慮執行期質量屬性，關注點是系統的併發、同步、通訊等問題，這勢必涉及到程序、執行緒、物件等執行時概念，以及相關的併發、同步、通訊等。執行架構的靜態方面關注軟體系統執行時的單元結構，動態方面關注執行時單元之間的互動機制。

物理架構的設計著重考慮安裝和部署需求，關注點是目標程式及其依賴的執行庫和系統軟體最終如何安裝或部署到物理機器，以及如何部署機器和網路來配合軟體系統的可靠性、可伸縮性、持續可用性、效能和安全性等要求。

資料架構的設計著重考慮資料需求，關注點是持久化資料的儲存方案，不僅包括實體及實體關係資料儲存格式，還可能包括資料傳遞、資料複製、資料同步等策略。

在運用五檢視方法進行架構設計時需要注意兩個方面的問題：一是多個架構檢視間的同步問題，也就是必須保證不同檢視之間是互相解釋而不是相互矛盾的；另一個是架構檢視的數量問題，原則上是軟體系統不涉及某方面的要求時就不需要該方面的檢視，嚴格控制架構檢視的數量，但如果有需要，可以引入新的架構檢視，從而更加突出和明確地制定和表達特定方面的架構決策，如安全性。

構成每個架構設計檢視的元素不同，這些不同的元素撐起不同的思維空間，從而使每個架構檢視重點覆蓋不同種類的需求，最終所有架構設計檢視所表達的語義綜合左右一起，就構成了軟體架構設計方案。

​

​