前言
通過上一篇學習我們大體瞭解了單體架構的含義及優缺點，隱性的引申出微服務分佈式體系的一些東西，接下來我們將開始真正走進微服務領域進行探索。從基本知識理念到技術，再到項目搭建。（字數很多，耐心閱讀）
關於本章學習，我們可以從以下幾點入手
1. 什麼是微服務
2. 微服務的優缺點
3. 單體架構系統與微服務架構系統的對比
4. 微服務運用的場景(設計原則)
目錄
一、什麼是微服務
通過文字定義我們可以用最直白的語言去說，“微”等同於細緻入微，“服務”等同於爲用戶提供功能支持。從系統架構層面簡單來說：將服務大模塊拆分成多個服務子模塊，通過“服務總站”將多個子模塊集中式地進行管理。
舉例來說：電商分爲用戶模塊，商品模塊，訂單模塊等
從傳統的單體架構體系來設計，這三個模塊都同屬於一個項目(war包)；從微服務的分佈式體系來設計，這三大模塊劃分爲獨立的三個項目。
來看一看作爲“微服務”這一名詞的發明人Martin Fowler對微服務的定義：
二、微服務的優缺點
優點
從上述對Martin Flower 微服務理念的引進，我們可以對其進行拆分梳理：(優點)
1. 模塊獨立化 (從以前系統多模塊的複雜性，到單元模塊的服務)
2. 輕量級的機制通信 (數據交互大多是以HTTP協議進行通信)
3. 自動化部署，集中式管理
4. 支持多語言及不同數據存儲
5. 分佈式系統
關於開發
我們在日常代碼維護中，講究的是高效，健壯，可用，而微服務的引進極大地滿足了我們這些日常需求。微服務是將複雜的業務拆分成多個單元服務，而我們針對業務需求進行開發的時候，不再對複雜業務進行大規模的設計和開發，而是將它拆分成多個子業務，只針對於子業務進行開發便可。這樣每個開發人員只負責維護自己的區域而不用在管其它人的區域。
開發方式由宏觀到微觀，時間成本由多到少。無論是項目版本更新，提出多麼複雜的功能需求，我們依然可以以微服務這樣理念去劃分，極大縮減了開發週期和成本，獨立單元服務的穩定型邊界，服務與服務之間沒有任何的耦合。
關於維護
傳統的軟件開發模式背後團隊領域都很齊全，UI負責作圖，產品負責原型，前端負責網頁設計，後端負責數據交互，測試確保項目不出任何問題，運維負責項目維護。雖然表面上看似堅不可摧，但往深了去看，本身所有的模塊集中在一個項目中，模塊的緊密性會牽扯到多個職位領域的參與，可能會遇到後端人員會參與到前端，運維；甚至是一個小業務會動用整個團隊，這樣顯然是產生了弊端。
微服務的體系，就避免了這樣弊端的存在，每一個職位領域負責本職工作而不會參與其它崗位人員的設計等。在維護方面極大的提高了工作效率，也大大提高了項目的穩定性，健壯性。
關於內部設計
1. 通信 - 數據傳輸
通常我們進行前後端數據交互的時候，都是以Json格式進行交互，少數以XML，Protobuf。Protobuf進行數據序列化生成二進制數據，反觀Json雖然前者更輕量化，但可讀性着實很差。Json與XML對比，無論是輕量傳輸還是可讀，Json更適合。
也是爲什麼現在JSON會成爲主流的數據交互方式那一定是有它的理由的。當然微服務單元之間一般傾向於HTTP通信機制，更多時候使用RESTFUL API。
跨語言使用也是微服務的優勢之一，無論是Go，Java，PHP，Pythod等都可以進行服務之間的通信交互，也就是說Java可以編寫業務提供給Pythod，同理也是一樣。
2. 數據存儲
微服務的分佈式體系，業務模塊的拆分可以使更多的單元服務使用不同的數據庫。
龐大的項目，業務模塊衆多，如果針對於同一個數據庫進行表操作，讀寫效率會隨着數據的增多，表的設計而大幅度縮減。微服務體系我們可以針對於不同單元服務進行關係數據庫和非關係數據庫的選擇，也可以進行關係數據庫分庫處理，相比於傳統單體架構系統而言，顯然微服務的分佈式體系更加佔有優勢。
3. 結構優化
從CAP理念我們知道，單體架構基於CA設計，微服務大多是基於AP設計，具由高可用和分區容錯的特點。高可用主要體現在7*24小時不間斷的服務，隨着用戶量的增加，併發數也逐漸升高，對於高併發的處理，微服務的水平擴展能力尤爲顯著，可以進行微服務的集羣化部署，從而增加系統的負載均衡。分區容錯特點也使得微服務更加健壯。
4. 熔斷器機制
微服務也具有熔斷處理機制，不會引起服務之間的“雪崩效應”，還可以自動化執行自我修復機制。
所謂的“雪崩效應”，就是因爲服務之間的強耦合性，使得一個服務運行出錯，另一個服務有依賴於這個服務，用戶不斷去使用出錯的服務，導致另一個服務壓力堆積使之線程阻塞，有更多被依賴的服務牽連着而引起整個項目的崩潰。而熔斷機制，在執行過程中會立即檢查並停掉出錯服務，本身是單元服務拆分，所以不會影響到其它服務的正常使用，避免了整個項目的崩潰，當然若有依賴此服務的單元服務也會被DOWN掉。
再者熔斷器還有另一個機制是自我修復機制，也就是被DOWN掉的服務通過調試解決問題後依然在其它服務運行過程中正常使用，這就是“悄無聲息”，不被其它人知道的情況下成功Up上了，這就是熔斷器中自我修復機制，會經過一段時間會半打開熔斷器來進行服務檢測。(在這裏給你一張圖自行模擬熔斷器機制)
關於部署
微服務具有集中式管理的特點，當然也拜託不了自動化部署，隨着Docker技術的引進，我們不會在向以前那樣將項目一列一列的打包，制定端口號等複雜操作，像Docker這樣的技術已經實現了，只需集中編寫，無需進行部署。(Jenkins還沒開始學習，關於自動化部署這裏推薦大家還是有必要看一看的)
微服務的缺點呢？
1. 分佈式事務
我們知道數據讀寫講究事務的基本原則，爲了保證數據的一致性而不會引起髒讀，幻讀等，微服務的分佈式體系對事務處理還是較爲繁瑣的。爲什麼？ 用一段僞代碼來說明一下：
/*
* 傳統項目中，因爲沒有服務拆分，所以只需要統一在一個模塊區域裏進行事務處理就可以
*/
@Transactional
public void updateTest() {
updateUser(); // 更新用戶表
updateOrder(); // 更新訂單表
}
微服務本身是服務拆分，所以得確保在服務與服務之間正常通信，非人爲因素本身是不可避免的，所以很有可能造成一個服務的事務成功，另一個服務事務的回滾。
2. 微服務的繁瑣
簡單來說，服務之間的獨立導致測試人員的成本開銷；通信機制牽扯到數據層面的交互本身重中之重，所以得選擇一個合適的機制來進行設計；服務與服務之間的建立，會造成有一個服務進行改動，而可能影響到另一個服務的改動。(這點可以人爲協調解決)
3. 服務部署
每一個單元服務相當於一個項目，除了內存的開銷以外，還有其項目本身所運用到不同的中間件等，這些複雜的業務程序在運維期間稍有不測，會影響到服務本身。
4. 服務拆分
微服務的微到底是拆分到什麼樣的層次，我們也不能具體的劃分。可以拆成一個接口一個項目，也可以拆成多個接口一個項目，所以這樣的邊界值是不定因素。
三、單體架構系統與微服務架構系統的對比
1. 從開發角度來說：前者效率低於後者
因爲後者模塊進行了拆分，側重角度明確，耦合性極低。
2. 從部署角度來說：前者效率低於後者
因爲後者支持集中式管理，自動化部署。
3. 從性能角度來說：優化相同的情況下，前者低於後者
前者CA設計理念，後者AP設計理念，可用型強，具有分區容錯特點。
4. 從錯誤處理角度來說：前者低於後者
後者支持熔斷機制，大幅度避免了雪崩效應
5. 從業務複雜性的角度來說：
前者適合用戶量少，業務模塊不是很多的應用；後者適合用戶量多，業務模塊複雜的應用
四、微服務運用的場景
以我的想法來說，首先從用戶量，領域，需求等有個大體的評估，確定了項目的走勢，在決定是否使用微服務分佈式架構體系，還是單體架構體系。
運用場景，比如：淘寶，京東，愛奇藝等這些基於百萬級以上的用戶量而言，更適合微服務的分佈式體系；比如：公司官網，小應用等這樣用戶量，需求量不是很多而言，單體架構體系更爲合適之選。
五、總結
以上是對微服務理念的大體介紹，通過對本篇的學習，我們也瞭解到了微服務之所以那麼火熱的原因，也瞭解了與傳統大體架構體系項目的不同之處。
在今後，我們便可以針對於不同產品需求和走勢選擇不同的架構體系去做。不得不說，寫一篇博客確實有些累，3個小時，一邊學習一邊總結也算收穫滿滿了。下一篇我們將真正開始接觸SpringCloud，雖然大多還是理論支持，但一分耕耘一分收穫，穩紮穩打纔是重要。