原文地址：http://www.admin10000.com/document/6408.htmlhtml
在實際工做中，咱們常常聽到「架構」和「架構師」這樣的名詞，並不新鮮，可是總讓不少剛入門的人感受很神祕，甚至是高深莫測。不多有人對「架構」有全面的瞭解和認識能並說清楚架構是什麼，更談不上掌握了。事實上，也只有極少數人能成爲或者被冠以「架構師」這樣的title。爲此，筆者總結了對架構的一些理解，但願可以補充不少初入門的人在這方面認識上的不足，糾正一些誤解。高手和老鳥就直接跳過吧。程序員
架構的分類
對於「架構」來說，理論上劃分了5種架構視圖，分別是：邏輯架構、開發架構、運行架構、物理架構、數據架構。根據名字，你們均可能大概能猜到其側重點和含義。這裏先用通俗的文字簡單介紹下，便於你們理解，你們能夠沒必要糾結概念和這些理論。web
邏輯架構：邏輯架構關注的是功能，包含用戶直接可見的功能，還有系統中隱含的功能。或者更加通俗來描述，邏輯架構更偏向咱們平常所理解的「分層」，把一個項目分爲「表示層、業務邏輯層、數據訪問層」這樣經典的「三層架構」。面試
開發架構：開發架構則更關注程序包，不只僅是咱們本身寫的程序，還包括應用程序依賴的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網絡服務...
邏輯分層和物理分層的好處
邏輯分層的好處：
- 代碼組織更清晰
- 更易於維護
- 更好的代碼重用性
- 更好的團隊開發體驗性
- 更高的代碼清晰度
物理分層的好處：
- 性能
- 可伸縮性
- 容錯性
- 安全性
架構師的分類
架構師每每是不少開發人員嚮往的職業，也不是像不少人想象中的那樣（畫一下PPT或者UML草圖，而後交給程序員們去實現，而後本身就自由玩耍了）。國內不少公司，是沒有架構師這種崗位定義的，一般是由技術優秀和經驗比較豐富的開發人員擔任，身兼多職的狀況也並很多見（我見過不少小公司的骨幹人員是身兼技術主管、系統分析師、項目經理、架構師、核心開發人員...）。值得糾正的就是，架構師和系統分析師不一樣，系統分析師更側重在項目早期的需求分析。而架構師，通常貫穿整個軟件開發週期，與項目經理也是相輔相成的。微軟對於架構師，又分爲：軟件架構師、系統架構師、解決方案架構師、企業架構師等。而其它一些廠商，可能又會劃分:技術架構師、業務架構師、網絡架構師、安全架構師、SOA架構師......
你們沒必要對這些概念太糾結。按照筆者的理解，國內大互聯網公司裏，架構師通常只會分2-3個方向：軟件架構師和系統架構師（有些企業叫運維架構師），有些企業對於比較資深DBA並且懂整個系統架構的，還會分出所謂的「數據架構師」。至於具體Title，大可沒必要糾結，只需瞭解本身的興趣，知曉了大體發展和定位，而後朝該方向努力便可。對於程序員而言，最基本的仍是先寫出高質量的代碼，在實戰中逐步提高本身設計思惟。
限於筆者水平和理解有限，文中所有文字和描述等全憑筆者記憶和理解寫出，不免出現錯誤，請熱心的讀者及時批評和指正。
因爲時間有限，部分圖片筆者畫的比較粗糙，也請讀者諒解。