微服務系列文章導航
一、單體架構
- 單體架構也稱之為單體系統或者是單體應用。就是一種吧系統中所有的功能、模塊耦合在一個應用中的架構方式
1、單體架構特點
- 打包成一個獨立的單元（導成一個唯一的jar包或者是war包）
會開啟一個進程的方式來運行
單層結構圖.png
2、單體架構的優點、缺點
2.1 優點
- 項目易于管理
- 部署簡單
2.2 缺點
- 測試成本高
- 可伸縮性差
- 可靠性差
- 迭代困難
- 跨語言程度差
- 團隊協作難
二、微服務架構
1、什么是微服務
- 微服務是一種架構風格。一個大型的復雜軟件應用，由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的，每個微服務僅關注一件任務并很好的完成該任務。
2、架構風格
- 項目的一種設計模式
2.1 常見的架構風格
- 客戶端與服務端的
- 基于組件模型的架構（EJB）
- 分層架構（MVC）
- 面向服務架構（SOA）
3、微服務特點
- 系統是由多個服務構成
- 每個服務可以單獨獨立部署
- 每個服務之間是松耦合的，服務內部是高內聚的，外部是低耦合的。高內聚就是每個服務只關注完成一個功能
4 、微服務的優點、缺點
4.1、優點
- 測試容易
- 可伸縮性強
- 可靠性強
- 跨語言成都會更加靈活
- 團隊協作容易
- 系統迭代容易
4.1、缺點
- 運維成本過高，部署數量較多
- 接口兼容多版本問題
- 分布式系統的復雜性
- 分布式事務（分布式事務的解決方案）
三、MVC、RPC、SOA、微服務架構區別
微服務架構的區別.png
1、MVC架構
- 其實MVC架構就是一個單體架構，代表技術：struts2，spring、springMVC、Mybatis等等
2、RPC架構
- RPC（remote procedure call）:遠程過程調用。她是一種通過網絡從遠程計算機程序上請求服務。而不需要了解底層網絡技術的協議
- 代表技術：Thrift（Apache）、Hessian（輕量級，速度快）等等
3、SOA架構
- SOA（Service Oriented Architecture）：面向服務架構
- ESB（Enterprise Service Bus）：企業服務總線，服務中介。主要是提供了一個服務與服務之間的交互
- ESB包含的功能入：負載均衡，流量控制，加密處理，服務的監控，異常處理，監控告急等等
- 代表技術 ： Mule（以Java為核心的服務框架）、WSO2（快速，輕巧，開源免費）
4、微服務架構
- 微服務，即是一個輕量級的服務治理方案
- 代表技術：springcloud，doubbo 等等
四、如何設計微服務以及設計原則
- AKF拆分原則
- 前后端分離原則
- 無狀態服務
- RestFul的通信風格
1、AKF拆分原則 【重點】
業界對于可擴展的系統架構設計有一個樸素的理念就是：
- 通過加機器就可以解決容量和可用性問題。（如果一臺不行就兩臺）
image.png
- y軸（功能） -- 關注應用中功能劃分，基于不同的業務員拆分
- x軸（水平擴展） -- 關注水平擴展，也就是
加機器解決問題- z軸（數據分區） -- 關注服務和數據的優先級劃分，如按地域劃分
1.1 Y軸（功能）
- Y 軸擴展會將龐大的整體應用拆分為多個服務。每個服務實現一組相關的功
能，如訂單管理、客戶管理等。在工程上常見的方案是 服務化架構(SOA) 。比
如對于一個電子商務平臺，我們可以拆分成不同的服務，組成下面這樣的架構:Y軸.png
- 但通過觀察上圖容易發現，當服務數量增多時，服務調用關系變得復雜。為
系統添加一個新功能，要調用的服務數也變得不可控，由此引發了服務管理上的
混亂。所以，一般情況下，需要采用服務注冊的機制形成服務網關來進行服務治
理。系統的架構將變成下圖所示：服務網關.png
1.2 X軸（水平擴產）
- X 軸擴展與我們前面樸素理念是一致的，通過絕對平等地復制服務與數據，
以解決容量和可用性的問題。其實就是將微服務運行多個實例，做集群加負載均
衡的模式。- 為了提升單個服務的可用性和容量， 對每一個服務進行 X 軸擴展劃分 。
負載均衡.png
1.3 Z軸（數據分區）
- Z 軸擴展通常是指基于請求者或用戶獨特的需求，進行系統劃分，并使得劃
分出來的子系統是相互隔離但又是完整的。以生產汽車的工廠來舉例：福特公司
為了發展在中國的業務，或者利用中國的廉價勞動力，在中國建立一個完整的子
工廠，與美國工廠一樣，負責完整的汽車生產。這就是一種 Z 軸擴展。
1.3.1 工程領域常見的 Z 軸擴展有以下兩種方案：
單元化架構
在分布式服務設計領域，一個單元（Cell）就是滿足某個分區所有業務操作
的自包含閉環。如上面我們說到的 Y 軸擴展的 SOA 架構，客戶端對服務端節點
的選擇一般是隨機的，但是，如果在此加上 Z 軸擴展，那服務節點的選擇將不再
是隨機的了，而是每個單元自成一體。如下圖：
image.png數據分區
為了性能數據安全上的考慮，我們將一個完整的數據集按一定的維度劃分出
不同的子集。 一個分區（Shard），就是是整體數據集的一個子集。比如用尾
號來劃分用戶，那同樣尾號的那部分用戶就可以認為是一個分區。數據分區為一
般包括以下幾種數據劃分的方式：
- 數據類型（如：業務類型)
- 數據范圍（如：時間段，用戶 ID）
- 數據熱度（如：用戶活躍度，商品熱度）
- 按讀寫分（如：商品描述，商品庫存）
2、前后端分離原則
前后端分離.png
- 何為前后端分離？前后端本來不就分離么？這要從尷尬的 jsp 講起。分工精細化從來都
是蛋糕做大的原則，多個領域工程師最好在不需要接觸其他領域知識的情況下合作，才可能
使效率越來越高，維護也會變得簡單。jsp 的模板技術融合了 html 和 java 代碼，使得傳統
MVC 開發中的前后端在這里如膠似漆，前端做好頁面，后端轉成模板，發現問題再找前端，
前端又看不懂 java 代碼......前后端分離的目的就是將這尷尬局面打破。前后端分離原則，簡單來講就是前端和后端的代碼分離，我們推薦的模式是最好采用物
理分離的方式部署，進一步促使更徹底的分離。如果繼續直接使用服務端模板技術，如：jsp，
把 java、js、html、css 都堆到一個頁面里，稍微復雜一點的頁面就無法維護了。
前后端分離.png這種分離方式有幾個好處：
- 前后端技術分離，可以由各自的專家來對各自的領域進行優化，這樣前段的用戶體
驗優化效果更好- 分離模式下，前后端交互界面更清晰，就剩下了接口模型，后端的接口簡潔明了，
更容易維護- 前端多渠道集成場景更容易實現，后端服務無需變更，采用統一的數據和模型，可
以支持多個前端：例如：微信 h5 前端、PC 前端、安卓前端、IOS 前端。
3、無狀態服務
無狀態服務.png
- 對于無狀態服務，首先說一下什么是狀態：如果一個數據需要被多個服務共
享，才能完成一筆交易，那么這個數據被稱為狀態。進而依賴這個“狀態”數據的
服務被稱為有狀態服務，反之稱為無狀態服務。- 那么這個無狀態服務原則并不是說在微服務架構里就不允許存在狀態，表達
的真實意思是要把有狀態的業務服務改變為無狀態的計算類服務，那么狀態數據
也就相應的遷移到對應的“有狀態數據服務”中。- 場景說明：例如我們以前在本地內存中建立的數據緩存、Session 緩存，到
現在的微服務架構中就應該把這些數據遷移到分布式緩存中存儲，讓業務服務變
成一個無狀態的計算節點。遷移后，就可以做到按需動態伸縮，微服務應用在運
行時動態增刪節點，就不再需要考慮緩存數據如何同步的問題。
4、RestFul的通信風格
RestFul的通信風格.png作為一個原則來講本來應該是個“無狀態通信原則”，在這里我們直接推薦一
個實踐優選的 Restful 通信風格 ，因為他有很多好處：
- 無狀態協議 HTTP，具備先天優勢，擴展能力很強。例如需要安全加密，有
現成的成熟方案 HTTPS 即可。- JSON 報文序列化，輕量簡單，人與機器均可讀，學習成本低，搜索引擎友
好。- 語言無關，各大熱門語言都提供成熟的 Restful API 框架，相對其他的一些
RPC 框架生態更完善。
