微服務架構介紹
作為現在網際網路行業比較火的一個概念，微服務。結合網路的資源自給總結的概念性的東西，後期還會有新的基於技術性的文章總結出來。首先在瞭解微服務架構之前需要了解的概念有分散式、叢集等等，這裡是從架構的角度上做為總結。所以先從單體架構講起。
一、單體架構
1.單體架構
單體架構也被稱為單體系統或者是單體應用，就是一種系統中所有的功能、模組耦合在一個應用中的架構方式。用簡單的方式理解就是將整個應用包括應用、資料庫等都在同一個伺服器上。而分散式從簡單的角度上理解就是將應用和資料等分開到不同的伺服器上，就然後對於應用和資料庫進行不同方向上的效能優化等等操作。
2.單體架構特點
- 打包成一個獨立的單元（匯入稱為一個jar包或者是一個war包）部署完成應用之後，應用通過一個程序的方式來執行
單體架構的優缺點
優點
專案易於管理
部署簡單
缺點
測試成本高
可伸縮性差
可靠性差
迭代困難
跨語言程度差
團隊協作難
二、微服務架構
1.什麼是微服務
微服務是一種架構風格，一個大型的複雜軟體應用，由一個或者多個微服務組成，系統中的各個微服務可以被獨立部署，各個微服務之間是鬆耦合的，每個微服務僅僅關注於完成一件任務並很好的完成該任務。將一個複雜的軟體系統，進行了慘無人道的拆分，但是通過拆分之後，這個複雜的應用系統變的更加的高效。
2.架構風格
所謂的架構風格就是專案的一種設計模式。而我們常見的程式設計模式有以下的四種方式。後面對於每個模式的優缺點進行了詳細的比較。
常見的架構風格
客戶端與伺服器端 ：包括C/S 和B/S兩種，而B/S比較特殊。
基於元件模型的架構（EJB）
分層架構（MVC）
面向服務架構（SOA）
3.微服務特點
（1）系統是有多個服務構成
（2）每個服務可以單獨獨立部署
（3）每個服務之間是鬆耦合的。服務內部是高內聚的，外部是低耦合的，也是比較符合軟體設計原則的，高內聚就是每個服務內部的關係是非常密切的，每個服務之間只關注完成一個功能。
4.微服務的優點、缺點
優點
測試容易
可伸縮性強
可靠性強
跨語言程度會更加靈活
團隊協作容易
系統迭代容易
缺點
運維成本過高，部署數量較多
介面相容多版本
分散式系統的複雜性
分散式事務
三、MVC、RPC、SOA、微服務架構之間的區別
1.MVC架構
其實從本質上講，MVC應該算作是一種設計模式，算作是單體架構的一種。比較有代表性的技術：Struts2,、SpringMVC、Spring、Mybatis、Hibernate等等。
2.RPC架構
RPC（Remote Procedure Call），遠端過程呼叫，它是一種通過網路遠端計算機請求，而不需要了解底層網路技術的協議。代表技術，Thrift、Hessian等
SOA架構
SOA（Service oriented Architecture）面向服務架構
ESB（Enterparise Servce Bus）：企業匯流排服務，服務中介。主要提供了服務於服務之間的互動。
ESB包含的功能如：負載均衡，流量控制，加密處理，服務監控，異常處理，監控警告等等。
代表性的技術：Mule、WSO2等
微服務架構
微服務就是一個輕量級的服務治理方案，代表技術：SpringCloud，dubbo等等
四、如何設計微服務及其設計原則
1.AKF分拆原則
2.前端後端分離原則
3.無狀態服務
4.RestFul的通行風格
1.AKF拆分原則
業界對於可擴充套件的系統架構設計有一個樸素的概念，通過加機器就可以解決容量和可用性問題。也就是一臺機器不夠用那就用兩臺機器。
這個理念在“雲端計算”概念瘋狂流行的當今社會，得到了廣泛的認可，對於一個規模迅速增長的系統而言，我們討論最多問題就是容量和效能的問題。但是隨著時間的推進，系統規模的增長，除了面對效能和容量的問題，還需要面對功能與模組數量的增長帶來的系統複雜性增長的問題，以及業務變化帶來的提供差異化服務的問題。而許多的系統再設計的時候並沒有充分的考慮到這個問題，導致系統的重構成為了常態，從而影響到了業務的交付能力，還浪費人力財力！對此《可擴充套件性藝術》一書中提出了一個更加系統的可擴充套件模型——AKF可擴充套件立方。這個立方體沿著三個座標軸的方向分別是XYZ。
Y軸（功能）
Y軸擴充套件會加將龐大的整體應用拆分為多個服務。每個服務實現一組相關功能，例如訂單管理、客戶管理等。在工程上常見的方案是服務化架構（SOA），比如對一個電子商務平臺，我們可以拆分成為不同的服務，組成下面這樣一個架構：
但是通過觀察上圖，容易發現，當服務數量增多時候，服務呼叫關係也變得開始複雜。為系統新增一個新功能，要呼叫的服務數量也變得不可控，由此引發了服務管理上的混亂。所以，一般情況下，需要採用服務註冊的機制形成服務閘道器來進行服務治理，系統的架構設計將變成下圖所示：
X軸（水平擴充套件）
X軸擴充套件是面向前面樸素理念是一致的，通過絕對平等的服務複製服務與資料，一解決容量和可用性的問題。其實就是將微服務運用多個例項，做叢集加負載均衡的模式。
為了提升單個服務的可用性和容量，對每一個服務進行X軸擴充套件劃分。
Z軸（資料分割槽）
Z軸擴充套件通常是指基於請求者或者使用者獨特的需求，進行系統劃分，並使得劃分出來的子系統是相互隔離但又是完整的。以生產汽車的工廠來舉例：福特公司為了發展中國的業務，或者利用中國的廉價勞動力，在中國建立一個完整的子工廠，與美國工廠一樣，負責完整的汽車生產，這就是Z軸拓展。
工程領域常見的Z軸擴充套件方案有以下兩種：
- 單元化架構
在分散式服務設計領域，一個單元（Cell）就是滿足某個分割槽所有業務操作的自包含閉環。例如我們上面說到的Y軸擴充套件SOA架構，客戶端對服務端節點的選擇一般是隨機的，但是，如果在此加上Z軸擴充套件，那服務節點的選擇將不再是隨機的了，而是每個單元自成一體，如下圖
資料分割槽
為了效能資料安全上的考慮，我們將一個完整的資料集按一定的維度劃分出不同的子集。一個分割槽（Shard），就是整體資料集的一個子集。比如用尾號來劃分使用者，同樣的尾號的那部分使用者就可以認為是一個分割槽，資料分割槽為一般包括以下幾種資料劃分方式
資料型別 例如業務型別
資料範圍 例如時間段，使用者ID
資料熱度 例如使用者活躍度，商品熱度
按讀寫分 例如商品描述，商品庫存
2.前端後端分離原則
什麼叫做前端後端分離呢！前端和後端在一般的概念上本來就是分離的。這個就要從jsp技術講起，分工精細才能把一個蛋糕做大，多個領域工程師最好在不需要接觸其他領域知識的情況下合作，才可能是效率越來越高。維護也會變的越來越簡單。Jsp的模板技術，融合了HTML和Java的程式碼，使得傳統MVC開發中的前端和後端在這個技術中如膠似漆，前端的工作就是做好頁面，後端轉成模板，發現問題在去找前端解決，前端又看不懂java程式碼，前後端分離的目的就是將這尷尬的局面打破。
前後端分離的原則，簡單的來講就是前端和後端程式碼的分離，我們推薦的模式是最好採用物理分離的辦法部署，進一步促使更加徹底的分離，如果繼續直接使用伺服器端模板技術，如jsp把java，js，html，css都堆到一個頁面中，稍微有點複雜一點的頁面就沒有辦法維護了。
這種分離方式有幾個好處
- 前後端技術分離，可以由各自的專家來對各自的領域進行優化，這樣前端使用者體驗優化效果更好
- 分離模式下，前後端互動介面更清晰，就剩下介面模型，後端的介面簡介明瞭，更容易維護
- 前端多渠道整合場景更容易實現，後端伺服器無需變更，採用統一的資料和模型，可以支援多個前端，例如微信H5前端，PC前端，Android前端，IOS前端
3.無狀態服務
對於無狀態服務，首先介紹什麼是狀態：如果一個數據需要被多個服務共享，才能完成一筆交易，那麼和這個資料被稱為狀態。進而依賴這個狀態的資料的服務被稱為是狀態服務，反之稱為無狀態服務
那麼這個無狀態服務原則並不是說在微服務裡就不允許存在狀態，表達的真實意思是要把所有狀態的業務服務改變為無狀態的計算類服務，那麼狀態資料也就是相應的遷移到對應的有狀態資料服務中。
場景說明：例如我們以前在本地記憶體中建立的資料快取、Session快取，到現在的微服務架構中，就應該把這些資料遷移到分散式快取中儲存，讓業務服務變成一個無狀態的計算節點。遷移後，就可以做到按需動態伸縮，微服務應用在執行時動態增刪節點，就不需要考慮快取資料如何同步的問題。
4.RestFul的通訊風格
作為一個原則來講，本來應該是一個“無狀態通訊原則”，這裡直接推薦一個實踐優選的RestFul通訊風格，因為他有很多好處：
- 無狀態協議HTTP，具備先天優勢，擴充套件能力很強，例如需要安全加密，有現有的成熟解決方案HTTPS即可
- JSON報文序列化，輕量簡單，人與機器均可讀，學習成本低，搜尋引擎友好
- 語言無關，各大熱門語言都提供了成熟的RestFul API 框架，相對其他的一些RPC框架生態更加完整。