Spring Cloud作為一套微服務治理的框架，幾乎考慮到了微服務治理的方方面面，之前也寫過一些關于Spring Cloud文章，主要偏重各組件的使用，本次分享主要解答這兩個問題：Spring Cloud在微服務的架構中都做了哪些事情？Spring Cloud提供的這些功能對微服務的架構提供了怎樣的便利？

傳統架構發展史

單體架構

單體架構在小微企業比較常見，典型代表就是一個應用、一個數據庫、一個web容器就可以跑起來，比如我們開發的開源軟件云收藏，就是標準的單體架構。

在兩種情況下可能會選擇單體架構：一是在企業發展的初期，為了保證快速上線，采用此種方案較為簡單靈活；二是傳統企業中垂直度較高，訪問壓力較小的業務。在這種模式下對技術要求較低，方便各層次開發人員接手，也能滿足客戶需求。

下面是單體架構的架構圖：

在單體架構中，技術選型非常靈活，優先滿足快速上線的要求，也便于快速跟進市場。

垂直架構

在單體架構發展一段時間后，公司的業務模式得到了認可，交易量也慢慢的大起來，這時候有些企業為了應對更大的流量，就會對原有的業務進行拆分，比如說：后臺系統、前端系統、交易系統等。

在這一階段往往會將系統分為不同的層級，每個層級有對應的職責，UI層負責和用戶進行交互、業務邏輯層負責具體的業務功能、數據庫層負責和上層進行數據交換和存儲。

下面是垂直架構的架構圖：

在這個階段SSH（struts+spring+hibernate）是項目的關鍵技術，Struts負責web層邏輯控制、Spring負責業務層管理Bean、Hibernate負責數據庫操作進行封裝，持久化數據。

服務化架構

如果公司進一步的做大，垂直子系統會變的越來越多，系統和系統之間的調用關系呈指數上升的趨勢。在這樣的背景下，很多公司都會考慮服務的SOA化。SOA代表面向服務的架構，將應用程序根據不同的職責劃分為不同的模塊，不同的模塊直接通過特定的協議和接口進行交互。這樣使整個系統切分成很多單個組件服務來完成請求，當流量過大時通過水平擴展相應的組件來支撐，所有的組件通過交互來滿足整體的業務需求。

SOA服務化的優點是，它可以根據需求通過網絡對松散耦合的粗粒度應用組件進行分布式部署、組合和使用。服務層是SOA的基礎，可以直接被應用調用，從而有效控制系統中與軟件代理交互的人為依賴性。

服務化架構是一套松耦合的架構，服務的拆分原則是服務內部高內聚，服務之間低耦合。

下面是服務化架構圖：

在這個階段可以使用WebService或者dubbo來服務治理。

SOA和微服務的區別

其實服務化架構已經可以解決大部分企業的需求了，那么我們為什么要研究微服務呢？先說說它們的區別；

微服務架構強調業務系統需要徹底的組件化和服務化，一個組件就是一個產品，可以獨立對外提供服務

微服務不再強調傳統SOA架構里面比較重的ESB企業服務總線

微服務強調每個微服務都有自己獨立的運行空間，包括數據庫資源。

微服務架構本身來源于互聯網的思路，因此組件對外發布的服務強調了采用HTTP Rest API的方式來進行

微服務的切分粒度會更小

總結:微服務架構是 SOA 架構思想的一種擴展，更加強調服務個體的獨立性、拆分粒度更小。

為什么考慮Spring Cloud

Spring Cloud來源于Spring，質量、穩定性、持續性都可以得到保證

Spirng Cloud天然支持Spring Boot，更加便于業務落地。

Spring Cloud發展非常的快，從16年開始接觸的時候相關組件版本為1.x，到現在將要發布2.x系列

Spring Cloud是Java領域最適合做微服務的框架。

相比于其它框架,Spring Cloud對微服務周邊環境的支持力度最大。

對于中小企業來講，使用門檻較低。

Spring Cloud　是微服務架構的最佳落地方案

以下為Spring Cloud的核心特性：

分布式/版本化配置

服務注冊和發現

路由

服務和服務之間的調用

負載均衡

斷路器

分布式消息傳遞

這些特性都是由不同的組件來完成，在架構的演進過程中扮演著重要的角色，接下來我們一起看看。

從現在開始，我這邊會將近期研發的spring

cloud微服務云架構的搭建過程和精髓記錄下來，幫助更多有興趣研發spring cloud框架的朋友，希望可以幫助更多的好學者。大家來一起探討spring cloud架構的搭建過程及如何運用于企業項目。源碼來源