標準Web系統的架構分層

在上圖中我們描述了web系統架構中的組成部分。並且給出了每一層常用的技術元件/服務實現。需要注意以下幾點：

實際上負載均衡的概念很廣泛，所述的過程是將**於外部的處理壓力通過某種規律/手段分攤到內部各個處理節點上。在日常生活中我們隨時隨地在和負載技術打交道，例如：上下班高峰期的車流量引導、民航空管局的航空流量管制、銀行櫃檯的叫號系統。

這裡我們所說的負載分配層，是單指利用軟體實現的計算機系統上的狹義負載均衡。乙個大型（日pv一億+）、中型（日pv一千萬+）web業務系統，是不可能只有乙個業務處理服務，而是多台伺服器同時進行某乙個相同業務的服務。所以我們需要根據業務形態設計一種架構方式，將來自外部客戶端的業務請求分擔到每乙個可用的業務節點上。如下圖所示：

負載層還有乙個作用，是根據使用者的請求規則，將不同的請求型別分派到不同的伺服器上。例如：如果某乙個http請求是請求一張，那麼負載層會直接到儲存介質上尋找相應的；如果某乙個http請求是提交的一張訂單，那麼負載層會根據規則將這張訂單提交傳送到指定的「訂單服務」節點上。

不同的業務需求，使用的負載層方案也是不同的，這就考驗架構師的方案選擇能力。例如nginx只能處理tcp/ip協議的之上應用層http協議，如果要處理tcp/ip協議，則要按照第三方的tcp-proxy-module模。更好的直接在tcp/ip層負載的方案，是使用haproxy。

隨後的文章中將詳細介紹這些負載架構方案以及這些方案的變形。

通俗來講就是我們的核心業務層，訂單業務、施工管理業務、診療業務、付款業務、日誌業務等等。如下圖所示：

很明顯在中大型系統中，這些業務不可能是獨立存在的，一般的設計要求都會涉及到子系統間脫耦：即x1系統除了知曉底層支撐系統的存在外（例如使用者許可權系統），x1系統不需要知道和它邏輯對等的x2系統的存在就可以工作。這種情況下要完成乙個較複雜業務，子系統間呼叫又是必不可少的：例如a業務在處理成功後，會呼叫b業務進行執行；a業務在處理失敗後，會呼叫c業務進行執行；又或者a業務和d業務在某種情況下是不可分割的整體，只有同時成功才成功，其中有乙個失敗整個大的業務過程都失敗。如下圖所示：

這樣一來業務間的通訊層又是乙個逃不開的話題。 在隨後的文章中，我們將以alibaba的dubbo框架、基於amqp協議的訊息佇列和kafka訊息佇列技術的原理和使用方式，來講解業務通訊層技術，特別是業務通訊層的技術選型注意事項。

有的讀者可能會問，為什麼業務系統間通訊層沒有提到http這樣的呼叫方式。畢竟很多公司目前都採用這種方式作為業務系統間的呼叫方式。我們首先通過乙個圖來看看http方式的呼叫過程。（注意，此過程不考慮http客戶端快取的過程也不考慮dns網域名稱解析的過程，從http建立可靠的tcp連線開始）：

從上圖中我們可以看出以下幾個問題：

資料儲存將是這個系列文章中將要介紹的另乙個重點。進行業務計算前的初始資料、計算過程中的臨時資料、計算完成後得到的計算結果都需要進行儲存。我們通過一張思維導圖首先從幾個維度闡述一下資料儲存的基本分類。

我們通過乙個最基本的在centos6.5系統上建立ext4檔案系統的過程，講解檔案系統的最基本原理。

萬變不離其宗的建立過程告訴我們乙個什麼事實呢？

上一小節我們敘述了最簡單、最原始的物理塊和檔案格式規範的工作方式，但是隨著伺服器端不斷擴大的資料儲存容量的需求和資料安全性的需求，很顯然單機的儲存是沒辦法滿足要求的，目前儲存環境兩種大的需求型別是：

很明顯圖中兩個問題的答案是肯定的，也就是我們將要介紹的塊儲存系統要解決的問題。

我們先來聊一下塊儲存。之前我們提到的最簡單的情況就是磁碟在本地物理機上，傳輸的物理塊i/o命令，也是通過本地物理機主板上的南橋進行的。但是為了擴充套件更大的磁碟空間，並且保證資料吞吐量，我們需要將磁碟介質和本地物理機分離，並且讓物理塊的i/o命令在網路上進行傳輸：

從上面的簡介中我們可以清楚的知曉，當面對大量的資料讀寫壓力的時候，檔案儲存系統肯定不是我們的首要選擇，而當我們需要選擇塊儲存系統時又面臨成本和運維的雙重壓力（san系統的搭建是比較複雜的，並且裝置費用昂貴）。並且在實際生產環境中我們經常遇到資料讀取壓力大，且需要共享檔案資訊的場景。那麼這個問題怎麼解決呢？

物件儲存系統一定是分布式檔案系統。但分布式檔案系統不一定是物件儲存系統

後續的文章我將使用mysql講解幾個常用的架構方案和效能優化點，當然也會講到mysql中，諸如innodb這樣的核心資料引擎的工作方式。這些架構方案主要解決的是mysql的單機i/o瓶頸、機房內資料容災、資料庫穩定性、跨機房資料容災等核心問題。

後續的文章我還會選取目前流行的資料快取系統，講解其工作原理、核心演算法和架構方案。以便讀者們根據自己的業務情況設計符合業務的儲存集群。當然還有非關係型資料庫cassandra、hbase、mongodb的深入介紹。

我們如何來評價乙個服務系統的頂層設計是否優秀呢？拋開八股文式的擴充套件性、穩定性、健壯性、安全性這樣的套話不說。我從實際工作中為大家總結了一下幾個評價要點。

任何系統架構在進行生產環境實施的時候，都是需要付出建設成本的。顯然各個公司/組織對成本的承受度是不一樣的（這些成本包括：設計成本、資產採購成本、運維成本、第三方服務成本），所以如何利用有限的成本建設出符合業務需求、適應訪問規模的系統，就是乙個複雜的問題。另外，這種要求下架構師是不能進行過度設計的。

根據業務的發展，整個系統是需要進行公升級的（這包括已有模組的功能公升級、合併已有的模組、加入新的業務模組或者在模組功能不變的情況下提高資料吞吐量）。那麼如何盡量不影響原業務的工作，以最快的速度、最小的工作量來進行系統的橫向、縱向擴充套件，也就是乙個複雜的問題了。好的系統架構是可以在使用者無任何感覺的情況下進行公升級的，或者只需要在某些關鍵子系統公升級時才需要短暫的停止服務。

對系統的攻擊肯定是瞄準整個系統最薄弱的環節進行的，攻擊可能來自於外部（例如dos/ddos攻擊）也可能來自於內部（口令入侵）。好架構的系統不是「絕對不能攻破」的系統，而是「預防很好」的系統。所謂預防，就是預防可能的攻擊，分階段對可能遇到的各種攻擊進行模擬；所謂隱藏，就是利用各種手段對整個系統的關鍵資訊進行涉密管理，root許可權、物理位置、防火牆引數、使用者身份。

好的架構應該考慮不同等級的容災。集群容災，在集群中某乙個服務節點崩潰的情況下，集群中另外一台主機能夠接替馬上接替他的工作，並且故障節點能夠脫離；分布式容災：分布式系統一般會假設整個系統中隨時都在發生單點故障/多點故障，當產生單點故障/多點故障時，整個分布式系統都還可以正常對外提供服務，並且分布式系統中的單點故障/多點故障區可以通過自動/人工的方式進行恢復，分布式系統會重新接納它們；異地容災（機房等級容災）：在機房產生物理災難的情況下（物理網路斷裂、戰爭摧毀、**等），在某個相隔較遠的異地，備份系統能夠發現這樣的災難發生，並主動接過系統執行權，通知系統運維人員（根據系統不同的執行要求，可能還有多個備份系統）。異地容災最大的挑戰性是如何保證異地資料的完整性。

系統架構歸根結底還是為業務服務的，系統架構的設計選型一定是以服務當前的業務為前提。在上文中提到的業務通訊層中，選擇soa元件還是訊息佇列元件，又或者選擇什麼樣的訊息佇列，就是乙個很好的業務驅動事件。例如，a業務是一種web前端服務，需要及時反饋給客戶操作結果，b業務的服務壓力又非常大。a業務在呼叫b業務時，b業務無法在毫秒級的時間內返回給a業務呼叫結果。這種業務場景下可以使用amqp型別的訊息佇列服務。另外說明兩點，目前行業內有很多為解決相同業務場景存在的不同方案，架構師在進行方案選型的過程中，一定要對各種解決方案的特點足夠掌握，這樣才能做出正確的選擇；另外行業內的解決方案已經足夠多，架構師在業務沒有特殊要求的情況下一定不要做「 重**明輪子」的事情。

一套服務系統從架設之初就需要運維團隊不斷的進行投入。顯然根據系統的複雜程度和物理機器的數量，運維團隊的知識複雜性也是不一樣的。在架構師進行頂層架構設計時，必須還要考慮系統的運維難度和運維成本。

感謝作者的無私奉獻

常見系統應用分層架構

常見系統應用分層架構 1 顯示層 web android ios h5 2 邏輯控制層 api 監控api 3 資料儲存層 mysql 監控mysql mongodb redis 5 分塊拆分測試，一塊一塊測試 6 資料庫測試 把研發 拿過來，把裡面跟資料庫產生互動的sql語句抽離出來，然後開發成效...

web系統架構

前端頁面快取技術，例如squid，如想用好的話還得深入掌握下squid的實現方式以及快取的失效演算法等。頁面片段快取技術，例如esi等，想用好的話同樣需要掌握esi的實現方式等 架構演變第五步 增加webserver 負載均衡技術 包括但不限於硬體負載均衡 軟體負載均衡 負載演算法 linux 協議...

DDD中的分層架構

ddd中的分層架構很好的應用了關注點分離原則separation of concerns soc 每一層做好自己的事情，減少交叉 表現層提供用來完成任務的使用者介面，如webform wpf asp.net mvc 以及winform等，一般而言，我們把表現層顯示的任何資料稱為檢視模型，把任何從螢幕...