隨著互聯網技術的發展，傳統的應用架構已滿足不了實際需求，微服務架構就隨之產生。那么傳統應用架構到底出了什么問題呢?又如何解決?接下來我們將從傳統單體架構的問題開始，對為什么需要微服務架構進行詳細講解。

傳統單體應用架構的問題

通常我們所使用的傳統單體應用架構都是模塊化的設計邏輯，程序在編寫完成后會被打包并部署為一個具體的應用，而應用的格式則依賴于相應的應用語言和框架。例如，在網上商城系統中，JavaWeb工程通常會被打成WA R包部署在Web服務器上，而普通Java工程會以JAR包的形式包含在WA R包中，如圖1-1所示。

早期單體架構圖

上圖中的這種應用開發風格很常見，它易于開發和調試，并且易于部署。在用戶量不多時，此種架構方式完全可以滿足需求，但隨著用戶人數的增加，一臺機器已經滿足不了系統的負載，此時我們就會考慮系統的水平擴展。通常情況下，我們只需要增加服務器的數量，并將打包好的應用拷貝到不同服務器(如Tomcat)，然后通過負載均衡器(如Apache、Nginx)就可以輕松實現應用的水平擴展，如圖所示。

在早期，單體架構的這種擴展方式可以很好的滿足使用需求，但隨著時間的推移，這種方式就會產生很多問題，具體表現如下：

1.應用復雜度增加，更新、維護困難

一個簡單的應用會隨著時間的推移而逐漸變大。一旦應用變的龐大而又復雜，那么開發團隊將會面臨很多問題，其中最主要問題就是這個應用太復雜，以至于任何單個開發者都很難進行二次開發或維護。

2.易造成系統資源浪費

雖然使用負載均衡的方式可以對項目中的服務容量進行水平擴展，但由于傳統單體架構的代碼中只有一個包含所有功能的WA R包，所以在對服務容量擴容時，只能選擇重復的部署這個WA R包來擴展服務能力，而不僅僅是擴展了所需的服務。這樣導致其他不需要擴展的服務也進行了相應的擴展，但這種擴展是不需要的，因此這種方式會極大的浪費資源。

3.影響開發效率

當一個應用越大時，啟動時間就會越長。開發和調試的過程中，如果有很大一部分時間都要在等待中渡過，那么必然會對開發效率有極大的影響。

4.應用可靠性低

傳統單體應用架構在運行時的可靠性比較低，當所有模塊都運行在一個進程中時，如果任何一個模塊中出現了一個Bug，可能會導致整個進程崩潰，從而影響到整個應用。

5.不利于技術的更新

傳統單體應用架構一旦選定使用某些技術，則后期的開發和擴展將在這些技術的基礎上實現。如果需要更改某種技術，則可能需要將整個應用全部重新開發，這種成本是非常大的。當然，傳統單體應用架構的問題還不只這些，但出現這些問題的根本原因可以說就是由于傳統單體架構中一個WA R包內包含了系統的所有服務功能所導致的。隨著業務變的越來越多，問題也就越來越多。

如何解決傳統應用架構的問題

針對傳統單體架構的問題，大部分企業通過SOA(Service-Oriented Architecture，面向服務的架構)來解決上述問題。SOA的思路是把應用中相近的功能聚合到一起，以服務的形式提供出去，因此基于SOA架構的應用可以理解為一批服務的組合。

同樣以網上商城為例，一個簡單的SOA系統如圖1-3所示。

SOA系統

從上圖可以看出，SOA將原來的單體架構按照功能細分為不同的子系統，然后再由各個子系統依賴服務中間件(這里指企業服務總線Enterprise Service Bus，簡稱ESB)來調用所需服務。

使用SOA可以將系統切分成多個組件服務，這種通過多個組件服務來完成請求的方式有很多好處，具體如下：

l把項目拆分成若干個子項目，不同的團隊可以負責不同的子項目，從而提高開發效率;

l把模塊拆分，使用接口通信，降低了模塊之間的耦合度;

l為企業的現有資源帶來了更好的重用性;l能夠在最新的和現有的應用之上創建應用;

l能夠使客戶或服務消費者免予服務實現的改變所帶來的影響;

l能夠升級單個服務或服務消費者而無需重寫整個應用，也無需保留已經不再適用于新需求的現有系統。

雖然使用SOA解決了單體架構中的問題，但多數情況下，SOA中相互獨立的服務仍然會部署在同一個運行環境中(類似于一個Tomcat實例下，運行了很多web應用)。和單體架構類似，隨著業務功能的增多，SOA的服務會變得越來越復雜。本質上看，單體架構的問題并沒有因為使用SOA而變的更好。

針對單體架構和SOA的問題，許多公司(如Amazon、eBay和NetFlix)通過采用微處理結構模式解決了系統架構中的問題。其思路不是開發一個巨大的單體式的應用，而是將應用分解為小的、互相連接的微服務。隨著微服務的使用，微服務架構的思想也隨之產生。