綱舉目張：帶你看看微服務架構的前世此生

資料來源：有羣裏的朋友給個人一些資料，以及本身百度和論壇、社區找來的一些資料，權當作一個總結式的簡介。。。

 

目錄以下：

1、微服務架構介紹

2、出現和發展

3、傳統開發模式和微服務的區別

4、微服務的具體特徵

5、SOA和微服務的區別

6、如何具體實踐微服務

7、常見的微服務設計模式和應用

8、微服務的優勢和缺點

9、思考：意識的轉變

10、參考資料

11、我的推薦

 

1、微服務架構介紹  

微服務架構（Microservice Architecture）是一種架構概念，旨在經過將功能分解到各個離散的服務中以實現對解決方案的解耦。你能夠將其看做是在架構層次而非獲取服務的

類上應用不少SOLID原則。微服務架構是個頗有趣的概念，它的主要做用是將功能分解到離散的各個服務當中，從而下降系統的耦合性，並提供更加靈活的服務支持。

概念：把一個大型的單個應用程序和服務拆分爲數個甚至數十個的支持微服務，它可擴展單個組件而不是整個的應用程序堆棧，從而知足服務等級協議。

定義：圍繞業務領域組件來建立應用，這些應用可獨立地進行開發、管理和迭代。在分散的組件中使用雲架構和平臺式部署、管理和服務功能，使產品交付變得更加簡單。

本質：用一些功能比較明確、業務比較精練的服務去解決更大、更實際的問題。

 

2、出現和發展

微服務（Microservice）這個概念是2012年出現的，做爲加快Web和移動應用程序開發進程的一種方法，2014年開始受到各方的關注，而2015年，能夠說是微服務的元年；

愈來愈多的論壇、社區、blog以及互聯網行業巨頭開始對微服務進行討論、實踐，能夠說這樣更近一步推進了微服務的發展和創新。而微服務的流行，Martin Fowler功不可沒。

這老頭是個奇人，特別擅長抽象概括和製造概念。特別是微服務這種新生的名詞，都有一個特色：一解釋就懂，一問就不知，一討論就打架。

Martin Fowler是國際著名的OO專家，敏捷開發方法的創始人之一，現爲ThoughtWorks公司的首

席科學家。在面向對象分析設計、UML、模式、軟件開發方法學、XP、重構等方面，都是世界頂級的

專家，現爲Thought Works公司的首席科學家。Thought Works是一家從事企業應用開發和——集

成的公司。早在20世紀80年代，Fowler就是使用對象技術構建多層企業應用的倡導者，他著有幾

本經典書籍： 《企業應用架構模式》、《UML精粹》和《重構》等。

                                                                                              ———— 百度百科

3、傳統開發模式和微服務的區別

先來看看傳統的web開發方式，經過對比比較容易理解什麼是Microservice Architecture。和Microservice相對應的，這種方式通常被稱爲Monolithic（單體式開發）。

全部的功能打包在一個 WAR包裏，基本沒有外部依賴（除了容器），部署在一個JEE容器（Tomcat，JBoss，WebLogic）裏，包含了 DO/DAO，Service，UI等全部邏輯。

優勢：

①開發簡單，集中式管理

②基本不會重複開發

③功能都在本地，沒有分佈式的管理和調用消耗

缺點：

一、效率低：開發都在同一個項目改代碼，相互等待，衝突不斷

二、維護難：代碼功功能耦合在一塊兒，新人不知道何從下手

三、不靈活：構建時間長，任何小修改都要重構整個項目，耗時

四、穩定性差：一個微小的問題，均可能致使整個應用掛掉

五、擴展性不夠：沒法知足高併發下的業務需求

常見的系統架構遵循的三個標準和業務驅動力：

一、提升敏捷性：及時響應業務需求，促進企業發展

二、提高用戶體驗：提高用戶體驗，減小用戶流失

三、下降成本：下降增長產品、客戶或業務方案的成本

基於微服務架構的設計：

目的：有效的拆分應用，實現敏捷開發和部署

 

 

關於微服務的一個形象表達：

X軸：運行多個負載均衡器以後的運行實例

Y軸：將應用進一步分解爲微服務（分庫）

Z軸：大數據量時，將服務分區（分表）

 

4、微服務的具體特徵

官方的定義：

一、一些列的獨立的服務共同組成系統

二、單獨部署，跑在本身的進程中

三、每一個服務爲獨立的業務開發

四、分佈式管理

五、很是強調隔離性

大概的標準：

一、分佈式服務組成的系統

二、按照業務，而不是技術來劃分組織

三、作有生命的產品而不是項目

四、強服務個體和弱通訊（ Smart endpoints and dumb pipes ）

五、自動化運維（ DevOps ）

六、高度容錯性

七、快速演化和迭代

 

5、SOA和微服務的區別

一、SOA喜歡重用，微服務喜歡重寫

SOA的主要目的是爲了企業各個系統更加容易地融合在一塊兒。 說到SOA不得不說ESB(EnterpriseService Bus)。 ESB是什麼? 能夠把ESB想象成一個鏈接全部企業級服務的腳手架。

經過service broker，它能夠把不一樣數據格式或模型轉成canonical格式，把XML的輸入轉成CSV傳給legacy服務，把SOAP 1.1服務轉成 SOAP 1.2等等。 它還能夠把一個服務

路由到另外一個服務上，也能夠集中化管理業務邏輯，規則和驗證等等。 它還有一個重要功能是消息隊列和事件驅動的消息傳遞，好比把JMS服務轉化成SOAP協議。 各服務間可能有

複雜的依賴關係。

微服務一般由重寫一個模塊開始。要把整個巨石型的應用重寫是有很大的風險的，也不必定必要。咱們向微服務遷移的時候一般從耦合度最低的模塊或對擴展性要求最高的模塊開始，

把它們一個一個剝離出來用敏捷地重寫，能夠嘗試最新的技術和語言和框架，然 後單獨佈署。 它一般不依賴其餘服務。微服務中經常使用的API Gateway的模式主要目的也不是重用代碼，

而是減小客戶端和服務間的往來。API gateway模式不等同與Facade模式，咱們可使用如future之類的調用，甚至返回不完整數據。

 

二、SOA喜歡水平服務，微服務喜歡垂直服務

SOA設計喜歡給服務分層(如Service Layers模式)。 咱們經常見到一個Entity服務層的設計，美其名曰Data Access Layer。 這種設計要求全部的服務都經過這個Entity服務層

來獲取數據。 這種設計很是不靈活，好比每次數據層的改動均可能影響到全部業務層的服務。 而每一個微服務一般有它本身獨立的data store。 咱們在拆分數據庫時能夠適當的作些

去範式化(denormalization)，讓它不須要依賴其餘服務的數據。

微服務一般是直接面對用戶的，每一個微服務一般直接爲用戶提供某個功能。 相似的功能可能針對手機有一個服務，針對機頂盒是另一個服務。 在SOA設計模式中這種狀況一般會用到

Multi-ChannelEndpoint的模式返回一個大而全的結果兼顧到全部的客戶端的需求。

 

三、SOA喜歡自上而下，微服務喜歡自下而上

SOA架構在設計開始時會先定義好服務合同(service contract)。 它喜歡集中管理全部的服務，包括集中管理業務邏輯，數據，流程，schema，等等。 它使用Enterprise

Inventory和Service Composition等方法來集中管理服務。 SOA架構一般會預先把每一個模塊服務接口都定義好。 模塊系統間的通信必須遵照這些接口，各服務是針對他們的調用者。

SOA架構適用於TOGAF之類的架構方法論。

微服務則敏捷得多。只要用戶用獲得，就先把這個服務挖出來。而後針對性的，快速確認業務需求，快速開發迭代。

 

6、怎麼具體實踐微服務

要實際的應用微服務，須要解決一下四點問題：

一、客戶端如何訪問這些服務

二、每一個服務之間如何通訊

三、如此多的服務，如何實現？

四、服務掛了，如何解決？（備份方案，應急處理機制）

一、客戶端如何訪問這些服務

原來的Monolithic方式開發，全部的服務都是本地的，UI能夠直接調用，如今按功能拆分紅獨立的服務，跑在獨立的通常都在獨立的虛擬機上的 Java進程了。客戶端UI如何訪問他的？

後臺有N個服務，前臺就須要記住管理N個服務，一個服務下線/更新/升級，前臺就要從新部署，這明顯不服務咱們 拆分的理念，特別當前臺是移動應用的時候，一般業務變化的節奏更快。

另外，N個小服務的調用也是一個不小的網絡開銷。還有通常微服務在系統內部，一般是無 狀態的，用戶登陸信息和權限管理最好有一個統一的地方維護管理（OAuth）。

因此，通常在後臺N個服務和UI之間通常會一個代理或者叫API Gateway，他的做用包括：

① 提供統一服務入口，讓微服務對前臺透明

② 聚合後臺的服務，節省流量，提高性能

③ 提供安全，過濾，流控等API管理功能

其實這個API Gateway能夠有不少廣義的實現辦法，能夠是一個軟硬一體的盒子，也能夠是一個簡單的MVC框架，甚至是一個Node.js的服務端。他們最重要的做 用是爲前臺（一般是

移動應用）提供後臺服務的聚合，提供一個統一的服務出口，解除他們之間的耦合，不過API Gateway也有可能成爲單點故障點或者性能的瓶頸。

用過Taobao Open Platform（淘寶開放平臺）的就能很容易的體會，TAO就是這個API Gateway。

 

 

二、每一個服務之間如何通訊

全部的微服務都是獨立的Java進程跑在獨立的虛擬機上，因此服務間的通訊就是IPC（inter process communication），已經有不少成熟的方案。如今基本最通用的有兩種方式：

同步調用：

①REST（JAX-RS，Spring Boot）

②RPC（Thrift, Dubbo）

異步消息調用(Kafka, Notify, MetaQ)

同步和異步的區別：

通常同步調用比較簡單，一致性強，可是容易出調用問題，性能體驗上也會差些，特別是調用層次多的時候。RESTful和RPC的比較也是一個頗有意 思的話題。

通常REST基於HTTP，更容易實現，更容易被接受，服務端實現技術也更靈活些，各個語言都能支持，同時能跨客戶端，對客戶端沒有特殊的要求，只要封裝了HTTP的

SDK就能調用，因此相對使用的廣一些。RPC也有本身的優勢，傳輸協議更高效，安全更可控，特別在一個公司內部，若是有統一個 的開發規範和統一的服務框架時，

他的開發效率優點更明顯些。就看各自的技術積累實際條件，本身的選擇了。

而異步消息的方式在分佈式系統中有特別普遍的應用，他既能減低調用服務之間的耦合，又能成爲調用之間的緩衝，確保消息積壓不會沖垮被調用方，同時能保證調用方的

服務體驗，繼續幹本身該乾的活，不至於被後臺性能拖慢。不過須要付出的代價是一致性的減弱，須要接受數據最終一致性；還有就是後臺服務通常要 實現冪等性，由於消息

發送出於性能的考慮通常會有重複（保證消息的被收到且僅收到一次對性能是很大的考驗）；最後就是必須引入一個獨立的broker，若是公司內部沒有技術積累，

對broker分佈式管理也是一個很大的挑戰。

 

三、如此多的服務，如何實現？

在微服務架構中，通常每個服務都是有多個拷貝，來作負載均衡。一個服務隨時可能下線，也可能應對臨時訪問壓力增長新的服務節點。服務之間如何相互感知？服務如何管理？

這就是服務發現的問題了。通常有兩類作法，也各有優缺點。基本都是經過zookeeper等相似技術作服務註冊信息的分佈式管理。當服務上線時，服務提供者將本身的服務信息

註冊到ZK（或相似框架），並經過心跳維持長連接，實時更新連接信息。服務調用者經過ZK尋址，根據可定製算法， 找到一個服務，還能夠將服務信息緩存在本地以提升性能。

當服務下線時，ZK會發通知給服務客戶端。

客戶端作：優勢是架構簡單，擴展靈活，只對服務註冊器依賴。缺點是客戶端要維護全部調用服務的地址，有技術難度，通常大公司都有成熟的內部框架支持，好比Dubbo。

服務端作：優勢是簡單，全部服務對於前臺調用方透明，通常在小公司在雲服務上部署的應用採用的比較多。

 

 

四、服務掛了，如何解決

前面提到，Monolithic方式開發一個很大的風險是，把全部雞蛋放在一個籃子裏，一榮俱榮，一損俱損。而分佈式最大的特性就是網絡是不可靠的。經過微服務拆分能下降這個風險，

不過若是沒有特別的保障，結局確定是噩夢。因此當咱們的系統是由一系列的服務調用鏈組成的時候，咱們必須確保任一環節出問題都不至於影響總體鏈路。相應的手段有不少：

①重試機制

②限流

③熔斷機制

④負載均衡

⑤降級（本地緩存）

這些方法基本都很明確通用，好比Netflix的Hystrix：https://github.com/Netflix/Hystrix

 

7、常見的設計模式和應用

有一個圖很是好的總結微服務架構須要考慮的問題，包括：

一、API Gateway

二、服務間調用

三、服務發現

四、服務容錯

五、服務部署

六、數據調用

 

 

六種常見的微服務架構設計模式：

一、聚合器微服務設計模式

這是一種最多見也最簡單的設計模式：

聚合器調用多個服務實現應用程序所需的功能。它能夠是一個簡單的Web頁面，將檢索到的數據進行處理展現。它也能夠是一個更高層次的組合微服務，對檢索到的數據增長業務邏輯後進一步

發佈成一個新的微服務，這符合DRY原則。另外，每一個服務都有本身的緩存和數據庫。若是聚合器是一個組合服務，那麼它也有本身的緩存和數據庫。聚合器能夠沿X軸和Z軸獨立擴展。

 

二、代理微服務設計模式

這是聚合模式的一個變種，以下圖所示：

在這種狀況下，客戶端並不聚合數據，但會根據業務需求的差異調用不一樣的微服務。代理能夠僅僅委派請求，也能夠進行數據轉換工做。

 

三、鏈式微服務設計模式

這種模式在接收到請求後會產生一個通過合併的響應，以下圖所示：

在這種狀況下，服務A接收到請求後會與服務B進行通訊，相似地，服務B會同服務C進行通訊。全部服務都使用同步消息傳遞。在整個鏈式調用完成以前，客戶端會一直阻塞。

所以，服務調用鏈不宜過長，以避免客戶端長時間等待。

 

四、分支微服務設計模式

這種模式是聚合器模式的擴展，容許同時調用兩個微服務鏈，以下圖所示：

 

 

五、數據共享微服務設計模式

自治是微服務的設計原則之一，就是說微服務是全棧式服務。但在重構現有的「單體應用（monolithic application）」時，SQL數據庫反規範化可能會致使數據重複和不一致。

所以，在單體應用到微服務架構的過渡階段，可使用這種設計模式，以下圖所示：

在這種狀況下，部分微服務可能會共享緩存和數據庫存儲。不過，這隻有在兩個服務之間存在強耦合關係時才能夠。對於基於微服務的新建應用程序而言，這是一種反模式。

 

六、異步消息傳遞微服務設計模式

雖然REST設計模式很是流行，但它是同步的，會形成阻塞。所以部分基於微服務的架構可能會選擇使用消息隊列代替REST請求/響應，以下圖所示：

 

 

8、優勢和缺點

一、微服務的優勢：

關鍵點：複雜度可控，獨立按需擴展，技術選型靈活，容錯，可用性高

①它解決了複雜性的問題。它會將一種怪異的總體應用程序分解成一組服務。雖然功能總量 不變，但應用程序已分解爲可管理的塊或服務。每一個服務都以RPC或消息驅動的API的

形式定義了一個明確的邊界；Microservice架構模式實現了一個模塊化水平。

②這種架構使每一個服務都可以由專一於該服務的團隊獨立開發。開發人員能夠自由選擇任何有用的技術，只要該服務符合API合同。固然，大多數組織都但願避免徹底無政府狀態並

限制技術選擇。然而，這種自由意味着開發人員再也不有義務使用在新項目開始時存在的可能過期的技術。在編寫新服務時，他們能夠選擇使用當前的技術。此外，因爲服務相對較小，

所以使用當前技術重寫舊服務變得可行。

③Microservice架構模式使每一個微服務都能獨立部署。開發人員不須要協調部署本地服務的變動。這些變化能夠在測試後儘快部署。例如，UI團隊能夠執行A | B測試，並快速迭代

UI更改。Microservice架構模式使連續部署成爲可能。

④Microservice架構模式使每一個服務均可以獨立調整。您能夠僅部署知足其容量和可用性限制的每一個服務的實例數。此外，您可使用最符合服務資源要求的硬件。

 

二、微服務的缺點

關鍵點（挑戰）：多服務運維難度，系統部署依賴，服務間通訊成本，數據一致性，系統集成測試，重複工做，性能監控等

①一個缺點是名稱自己。術語microservice過分強調服務規模。但重要的是要記住，這是一種手段，而不是主要目標。微服務的目標是充分分解應用程序，以便於敏捷應用程序開發和部署。

②微服務器的另外一個主要缺點是分佈式系統而產生的複雜性。開發人員須要選擇和實現基於消息傳遞或RPC的進程間通訊機制。此外，他們還必須編寫代碼來處理部分故障，

由於請求的目的地可能很慢或不可用。

③微服務器的另外一個挑戰是分區數據庫架構。更新多個業務實體的業務交易是至關廣泛的。可是，在基於微服務器的應用程序中，您須要更新不一樣服務所擁有的多個數據庫。使用分佈式事務

一般不是一個選擇，而不只僅是由於CAP定理。許多今天高度可擴展的NoSQL數據庫都不支持它們。你最終不得不使用最終的一致性方法，這對開發人員來講更具挑戰性。

④測試微服務應用程序也更復雜。服務相似的測試類將須要啓動該服務及其所依賴的任何服務（或至少爲這些服務配置存根）。再次，重要的是不要低估這樣作的複雜性。

⑤Microservice架構模式的另外一個主要挑戰是實現跨越多個服務的更改。例如，咱們假設您正在實施一個須要更改服務A，B和C的故事，其中A取決於B和B取決於C.在單片應用程序中，

您能夠簡單地更改相應的模塊，整合更改，並一次性部署。相比之下，在Microservice架構模式中，您須要仔細規劃和協調對每一個服務的更改。例如，您須要更新服務C，而後更新服務B，

而後再維修A.幸運的是，大多數更改一般僅影響一個服務，而須要協調的多服務變動相對較少。

⑥部署基於微服務的應用程序也更復雜。單一應用程序簡單地部署在傳統負載平衡器後面的一組相同的服務器上。每一個應用程序實例都配置有基礎架構服務（如數據庫和消息代理）

的位置（主機和端口）。相比之下，微服務應用一般由大量服務組成。例如，每一個服務將有多個運行時實例。更多的移動部件須要進行配置，部署，擴展和監控。此外，您還須要實現服務

發現機制，使服務可以發現須要與之通訊的任何其餘服務的位置（主機和端口）。傳統的基於故障單和手動操做的方法沒法擴展到這種複雜程度。所以，成功部署微服務應用程序須要

開發人員更好地控制部署方法，並實現高水平的自動化。

 

9、思考：意識的轉變

微服務對咱們的思考，更多的是思惟上的轉變。對於微服務架構：技術上不是問題，意識比工具重要。

關於微服務的幾點設計出發點：

一、應用程序的核心是業務邏輯，按照業務或客戶需求組織資源（這是最難的）

二、作有生命的產品，而不是項目

三、頭狼戰隊，全棧化

四、後臺服務貫徹Single Responsibility Principle（單一職責原則）

五、VM->Docker （to PE）

六、DevOps (to PE)

同時，對於開發同窗，有這麼多的中間件和強大的PE支持當然是好事，咱們也須要深刻去了解這些中間件背後的原理，知其然知其因此然，在有限的技術資源如何經過開源技術實施微服務？

最後，通常提到微服務都離不開DevOps和Docker，理解微服務架構是核心，devops和docker是工具，是手段。

 

10、參考資料：

http://kb.cnblogs.com/page/520922/

http://www.infoq.com/cn/articles/seven-uservices-antipatterns

http://www.csdn.net/article/2015-08-07/2825412

http://blog.csdn.net/mindfloating/article/details/45740573

http://blog.csdn.net/sunhuiliang85/article/details/52976210

http://www.oschina.net/news/70121/microservice

 

 11、我的推薦

文章的最後，給你們推薦一個架構交流平臺，我在寫這篇文章時遇到的一些模糊的概念的時候，也是裏面的朋友幫我梳理清楚的，但願這篇文章可以幫到你們，想要加入的能夠加羣650385180，但願你們可以加入進來一塊兒相互交流。