原標題：篤學私教：Java開發網站架構演變過程-從單體應用到微服務架構詳解

Java開發網站架構演變過程，到目前為止，大致分為5個階段，分別為單體架構、集群架構、分布式架構、SOA架構和微服務架構。下面玄武老師來給大家詳細介紹下這5種架構模式的發展背景、各自優缺點以及涉及到的一些技術，并且教會你如何區分它們。

第1階段：單體架構

單體架構介紹

單體架構就是將所有的應用、數據庫、文件都部署在一臺機器上，俗稱All-In-One。簡單來講其實就是我們熟知的SSH架構或SSM架構，把所有的業務模塊都放在一個應用中開發，這里面又衍生出三層架構，即表示層、業務邏輯層和數據庫訪問層，雖然在軟件設計中劃分了經典的三層模型，但是對業務場景沒有劃分，一個典型的單體應用就是將所有的業務場景的表示層、業務邏輯層和數據訪問層放在一個工程項目中，最終經過編譯、打包，部署在一臺服務器上。單體架構圖如下：

單體架構優點

1)部署簡單: 由于是完整的結構體，可以直接部署在一個服務器上即可。

2)技術單一: 項目不需要復雜的技術棧，往往一套熟悉的技術棧就可以完成開發。

3)用人成本低: 單個程序員可以完成業務接口到數據庫的整個流程。

單體架構缺點

1)系統啟動慢： 一個進程包含了所有的業務邏輯，涉及到的啟動模塊過多，導致系統的啟動、重啟時間周期過長;

2)系統錯誤隔離性差、可用性差：任何一個模塊的錯誤均可能造成整個系統的宕機;

3)可伸縮性差：系統的擴容只能只對這個應用進行擴容，不能做到對某個功能點進行擴容;

4)線上問題修復周期長：任何一個線上問題修復需要對整個應用系統進行全面升級。

單體架構向集群架構過渡(1)：應用和數據分離

隨著公司業務的不斷發展，由于單臺服務器性能有限，逐漸無法滿足業務需求，大量用戶高并發的訪問導致系統性能越來越差，數據存儲空間開始出現不足，這時我們需要將應用和數據分離，分離后開始使用三臺服務器：應用服務器、文件服務器、數據庫服務器。如圖:

應用和數據分離后，不同種類的服務器承擔著不同的服務角色，網站的并發處理能力和數據存儲空間都得到了很大的改善，支持網站業務進一步發展，但是隨著用戶量進一步增多，數據庫壓力依然越來越大，訪問延遲不可避免，進而影響整個網站的性能，糟糕的用戶體驗使得系統需要進一步優化。

單體架構向集群架構過渡(2)：緩存的使用

隨著QPS持續提高，為了降低接口訪問時間、提高服務性能和并發，我們注意到，網站訪問有個著名的二八定律，即80%的業務集中訪問在20%的數據上(熱數據)，其實部分數據有很多不需要每次都從數據庫獲取，比如經常被查詢但對準確性要求并不是特別高的數據。如果我們將這一小部分熱數據緩存在內存中，能夠很好的減少數據庫的訪問壓力，并大幅提升網站響應速度，因此網站就開始加入了緩存應用，常用的緩存組件有redis，ehcache等。

注意:能使用緩存的數據得滿足如下要求：

1)對于數據實時性要求不高

對于一些經常訪問但是很少改變的數據，查詢明顯多于修改，適用緩存就很有必要，比如一些網站配置項。

2)對于性能要求高

比如一些秒殺活動場景。

第2階段：集群架構

緩存在一定程度上解決了數據庫訪問量比較大的問題，但仍無法解決隨著業務增多造成的服務器并發壓力大的問題，因為單臺服務器的計算能力有限，應用程序運行速度就有限，因此這時想要突破服務器性能的瓶頸，最直接的辦法就是增加一臺甚至多臺應用服務器來分擔原來服務器的訪問壓力和存儲壓力，多臺應用服務器之間沒有直接的交互，他們都是依賴數據庫各自對外提供服務。注意，這里的多臺應用服務器部署的都是同一套應用程序(即同一套項目源碼或war包)，這就是集群架構，結構如圖:

思考：系統演變到這里，將會出現下面四個問題(不做具體展開)：

1)用戶的請求由誰來轉發到到具體的應用服務器

2)有什么轉發的算法

3)應用服務器如何返回用戶的請求

4)用戶如果每次訪問到的服務器不一樣，那么如何維護session的一致性

這時候，你會發現圖中多了一個名為負載均衡器的代理服務器，通常我們使用Nginx來實現，它的作用主要就是用戶不需要記住兩個甚至多個應用服務器的IP或域名，只要記住一臺代理服務器IP就可以了。由代理服務器來負責分發用戶是訪問哪個應用服務器，那么用戶具體是訪問服務器1、訪問服務器2還是服務器N，由Nginx里面的權重設置來決定的，并且通過Nginx的配置，Session共享也可以附帶實現，保證多臺應用服務器的Session一致性。另外，這樣做還有一個好處就是將代理服務器放在外網，應用服務器均放在內網，可以有效防止應用服務器被惡意攻擊。

集群架構演變(1)：數據庫讀寫分離

系統正常運行了一段時間后，雖然加有緩存，使絕大多數的數據庫操作可以不通過數據庫就能完成，但是仍然有一部分的數據庫操作(緩存訪問不命中或緩存過期)和全部的寫操作需要訪問數據庫，當用戶規模再一步增長后，數據庫因為負載壓力過大還是會成為系統性能的瓶頸，這時主流的數據庫都提供的有主從熱備份功能，通過配置兩臺數據庫實現主從關系，可以將一臺數據庫服務器的數據更新同步到另一臺服務器上。可以利用這一功能來實現數據庫讀寫分離，從而改善數據庫的負載壓力，如圖:

在圖中我們可以發現主數據庫服務器負責寫操作，而從服務器負責讀操作，這樣數據庫的壓力就被分散在兩臺服務器上，而我們只需保證主從數據庫的數據一致性即可，這里說明下Mysql的讀寫分離可以通過自身自帶的從主復制實現，Oracle數據庫可以通過阿里巴巴的mycat組件來實現。

概念補充：

1)負載：是指將請求負載到不同的服務器；

2)均衡：指的是平分服務器的請求次數。

3)熱備份：指的是它可以在不停止數據庫運行的情況下，自動的根據定時任務或者數量容量大小去備份數據庫。

集群架構演變(2)：反向代理和CDN加速

為了應對復雜的網絡環境和不同地區用戶的訪問(比如你的服務器在美國或新加坡，國內用戶直接訪問可能會很卡)，保障各個地區的用戶都能流暢地訪問系統，可以通過CDN和反向代理來加快用戶訪問的速度，同時減輕后端服務器的負載壓力。CDN與反向代理的基本原理其實本質上都是緩存。CDN部署在網絡提供商的機房，用戶請求到來的時候從距離自己最近的網絡提供商機房獲取數據，而反向代理則部署在網站的中心機房中，請求帶來的時候先去反向代理服務器中查看請求資源，如果有則直接返回。結構如圖：

第3階段：分布式架構

分布式架構的演變涉及分布式文件、分布式數據庫、NoSql、搜索引擎以及業務模塊的拆分，下面我們一個個看。

分布式架構演變(1)：分布式文件和分布式數據庫

即使性能再強大的單臺服務器也無法滿足大型網站持續增長的業務需求，數據庫經過讀寫分離后，數據庫服務器從一臺拆分成了兩臺，但是隨著業務的飛速增長依然會達到性能瓶頸，這時我們需要使用分布式數據庫，同時文件系統也一樣，需要使用分布式文件系統。

分布式數據庫是數據庫拆分的最后的手段，只有在表單數據規模非常龐大的時候才使用，不到不得已時，我們更常用的手段是業務分庫，將不同的業務數據部署在不同的物理服務器上。結構如圖：

分布式架構演變(2)：NoSql和搜索引擎

隨著業務越來越復雜，系統對數據存儲和檢索的需求也跟著復雜化，這時一些NoSQL(Reids,HBase,mongodb)數據庫技術和搜索引擎(Solr,Elasticsearch)的時候就顯得很有必要。數據庫做讀庫的時候，往往對模糊查詢顯得力不從心，即使做了讀寫分離，這個問題還未能解決。以我們電商網站為例，發布的商品存儲在數據庫中，用戶最常使用的功能就是查找商品，尤其是根據商品的標題來查找對應的商品。對于這種需求，一般我們都是通過like功能來實現的，但是這種方式的代價非常大。此時我們可以使用搜索引擎的倒排索引來完成。

搜索引擎能夠大大提高查詢速度，但系統引入搜索引擎后也會帶來以下的開銷：

1)帶來大量的維護工作，我們需要自己實現索引的構建過程，設計全量/增加的構建方式來應對非實時與實時的查詢需求。

2)需要維護搜索引擎集群

3)搜索引擎并不能替代數據庫，他解決了某些場景下的“讀”的問題，是否引入搜索引擎，需要綜合考慮整個系統的需求。

結構如下圖:

NoSQL和搜索引擎對可伸縮的分布式特性具有更好的支持，應用服務器通過一個統一的數據訪問模塊訪問各種數據，減輕應用程序管理諸多數據源的麻煩。

分布式架構演變(3)：業務模塊拆分成子項目

當訪問量達到一定規模的時候我們可以通過分而治之的手段將整個系統的業務分成不同的產品線，例如我們將系統的首頁，商鋪，訂單，買家，賣家，支付，訂單等模塊拆分成不同的產品線，每個產品線都獨立成一個子項目，每個子項目都有自己的獨立的數據庫，子項目之間通過RPC框架(dubbo,webService,httpClient…)建立連接通信，也可以通過消息隊列實現異步分發處理，從而構成一個完整的系統，結構如下圖:

第4階段：SOA架構

SOA是什么？SOA全英文是Service-Oriented Architecture，意為面向服務編程，也稱為服務治理，是一種思想，一種方法論，一種分布式的服務架構，這里的服務可以理解為service層業務服務，它將共同的業務邏輯拆分成獨立的應用進行部署，這些應用沒有視圖層，只對外提供RPC調用接口。

注意區分項目與服務概念：

項目表達的意思：包含業務邏輯層和視圖層

服務表達的意思是：只包含業務邏輯層，沒有視圖層

SOA 系統原型的一個典型例子是 CORBA，它已經出現很長時間，其定義的概念與 SOA 相似。SOA 建立在 XML 等新技術的基礎上，通過使用基于 XML 的語言來描述接口，服務已經轉到更動態且更靈活的接口系統中，CORBA 中的 IDL 無法與之相比。如圖描述了一個完整的 SOA 模型。

在 SOA 模型中，所有的功能都定義成了獨立的服務。服務之間通過交互和協調完成業務的整體邏輯。所有的服務通過服務總線或流程管理器來連接。這種松散耦合的架構使得各服務在交互過程中無需考慮雙方的內部實現細節，以及部署在什么平臺上。一個獨立的服務基本結構如圖所示：

服務模型的表示層從邏輯層分離出來，中間增加了服務對外的接口層。通過服務接口的標準化描述，使得服務可以提供給在任何異構平臺和任何用戶接口使用。這允許并支持基于服務的系統成為松散耦合、面向構件和跨技術實現，服務請求者很可能根本不知道服務在哪里運行、是由哪種語言編寫的，以及消息的傳輸路徑，而是只需要提出服務請求，然后就會得到答案。舉個例子：

通過上面的圖我們可以看出，多個子系統直接相互交互，相互調用非常凌亂，這樣我們就很不爽，所以我們就用到了我們的SOA架構，SOA又叫服務治理，SOA就是幫助我們把服務之間調用的亂七八糟的關系給治理起來，然后提供一個統一的標準，把我們的服務治理成下圖所示，以前我們的服務是互相交互，現在是只對數據總線進行交互，這樣系統就變得統一起來。

各個系統分別根據統一標準向數據總線進行注冊，各子系統調用其他子系統時，我們并不關心如何找到其他子系統，我們只找數據總線，數據總線再根據統一標準找其他子系統，所以數據總線在這里充當一個指路人的作用。

SOA的特點：

1)系統集成：站在系統的角度，解決企業系統間的通信問 題，把原先散亂、無規劃的系統間的網狀結構，梳理成 規整、可治理的系統間星形結構，這一步往往需要引入 一些產品，比如 ESB、以及技術規范、服務管理規范； 這一步解決的核心問題是【有序】

2)系統的服務化：站在功能的角度，把業務邏輯抽象成 可復用、可組裝的服務，通過服務的編排實現業務的 快速再生，目的：把原先固有的業務功能轉變為通用 的業務服務，實現業務邏輯的快速復用；這一步解決 的核心問題是【復用】

3)業務的服務化：站在企業的角度，把企業職能抽象成 可復用、可組裝的服務；把原先職能化的企業架構轉變為服務化的企業架構，進一步提升企業的對外服務能力；“前面兩步都是從技術層面來解決系統調用、系統功能復用的問題”。第三步，則是以業務驅動把一個業務單元封裝成一項服務。這一步解決的核心問題是【高效】

SOA的優點：

1)降低用戶成本，用戶不需要關心各服務之間是什么語言的、不需要知道如果調用他們，只要通過統一標準找數據總線就可以了。

2)程序之間關系服務簡單

3)識別哪些程序有問題(掛掉)

SOA的缺點：

提示了系統的復雜程度，性能有相應影響。

第5階段：微服務架構

隨著業務拆分越來越小，存儲系統越來越龐大，應用系統的整體復雜度呈指數級增加，部署維護越來越困難，由于所有應用要和所有數據庫系統連接，最終導致數據庫連接資源不足，拒絕服務。

1)當服務越來越多時，服務URL配置管理變得非常困難，F5硬件負載均衡器的單點壓力也越來越大。

2)當進一步發展，服務間依賴關系變得錯蹤復雜，甚至分不清哪個應用要在哪個應用之前啟動，架構師都不能完整的描述應用的架構關系。

3)接著，服務的調用量越來越大，服務的容量問題就暴露出來，這個服務需要多少機器支撐？什么時候該加機器？

4)服務多了，溝通成本也開始上升，調某個服務失敗該找誰？服務的參數都有什么約定？

5)一個服務有多個業務消費者，如何確保服務質量？

6)隨著服務的不停升級，總有些意想不到的事發生，比如cache寫錯了導致內存溢出，故障不可避免，每次核心服務一掛，影響一大片，人心慌慌，如何7)控制故障的影響面？服務是否可以功能降級？或者資源劣化？

解決方案：公共的應用模塊被提取出來，部署在分布式服務器上供應用服務器調用。也就是我們所說的分布式服務或者微服務。

微服務架構是一種架構概念，核心思想在于通過將業務功能和需求分解到各個不同的服務中進行管理，實現對業務整體解耦。圍繞業務模式創建應用服務，應用服務可獨立地進行開發、迭代、部署，使項目的架構更加清晰明確。目前主流的微服務架構框架就是SpringCloud。

以下是一個微服務案例的架構圖：

微服務優點

1)每個服務足夠內聚，足夠小，代碼容易理解、開發效率提高；

2)服務之間可以獨立部署，微服務架構讓持續部署成為可能；

3)每個服務可以各自進行負載均衡擴展和數據庫擴展，而且，每個服務可以根據自己的需要部署到合適的硬件服務器上；

4)容易擴大開發團隊，可以針對每個服務(service)組件開發團隊；

5)提高容錯性(fault isolation)，一個服務的內存泄露并不會讓整個系統癱瘓；

6)系統不會被長期限制在某個技術棧上。

微服務缺點

1)開發人員要處理分布式系統的復雜性；

2)開發人員要設計服務之間的通信機制，對于需要多個后端服務的user case，要在沒有分布式事務的情況下實現代碼非常困難；

3)涉及多個服務直接的自動化測試也具備相當的挑戰性；

4)服務管理的復雜性，在生產環境中要管理多個不同的服務的實例，這意味著開發團隊需要全局統籌(PS：現在docker的出現適合解決這個問題)；

總結：架構之間的區別

1)單體架構很好區分，只要看所有應用程序、文件系統、數據庫等是否都在一個服務器上

2)集群架構，其實就是將原先的單體架構中的應用程序分別部署在多臺應用服務器上，不過他們還是公用一個數據庫。

3)分布式架構，將原先的單體架構中的項目按照功能模塊拆分成多個單獨的子項目，分別部署在不同的應用服務器，并且每個子項目都有自己的獨立的數據庫。

4)SOA架構與微服務架構的區別：

首先SOA和微服務架構一個層面的東西，而對于ESB和微服務網關是一個層面的東西，一個談到是架構風格和方法，一個談的是實現工具或組件。

(Service Oriented Architecture)“面向服務的架構”:他是一種設計方法，其中包含多個服務， 服務之間通過相互依賴最終提供一系列的功能。一個服務 通常以獨立的形式存在與操作系統進程中。各個服務之間 通過網絡調用。

2.微服務架構:其實和 SOA 架構類似,微服務是在 SOA 上做的升華，微服務架構強調的一個重點是“業務需要徹底的組件化和服務化”，原有的單個業務系統會拆分為多個可以獨立開發、設計、運行的小應用。這些小應用之間通過服務完成交互和集成。

微服務架構 = 80%的SOA服務架構思想 + 100%的組件化架構思想 + 80%的領域建模思想

具體如圖：

返回搜狐，查看更多

責任編輯：