微服務(wù)架構(gòu)設(shè)計(jì)總結(jié)實(shí)踐篇，10 步搭建微服務(wù)

-     目錄    -

一、微服務(wù)架構(gòu)介紹

二、出現(xiàn)和發(fā)展

三、傳統(tǒng)開發(fā)模式和微服務(wù)的區(qū)別

四、微服務(wù)的具體特征

五、SOA和微服務(wù)的區(qū)別

六、如何具體實(shí)踐微服務(wù)

七、常見的微服務(wù)設(shè)計(jì)模式和應(yīng)用

八、微服務(wù)的優(yōu)點(diǎn)和缺點(diǎn)

九、思考：意識(shí)的轉(zhuǎn)變

十、參考資料和推薦閱讀

-     微服務(wù)架構(gòu)介紹    -

微服務(wù)架構(gòu)（Microservice Architecture）是一種架構(gòu)概念，旨在通過(guò)將功能分解到各個(gè)離散的服務(wù)中以實(shí)現(xiàn)對(duì)解決方案的解耦。你可以將其看作是在架構(gòu)層次而非獲取服務(wù)的類上應(yīng)用很多SOLID原則。微服務(wù)架構(gòu)是個(gè)很有趣的概念，它的主要作用是將功能分解到離散的各個(gè)服務(wù)當(dāng)中，從而降低系統(tǒng)的耦合性，并提供更加靈活的服務(wù)支持。

概念：把一個(gè)大型的單個(gè)應(yīng)用程序和服務(wù)拆分為數(shù)個(gè)甚至數(shù)十個(gè)的支持微服務(wù)，它可擴(kuò)展單個(gè)組件而不是整個(gè)的應(yīng)用程序堆棧，從而滿足服務(wù)等級(jí)協(xié)議。

定義：圍繞業(yè)務(wù)領(lǐng)域組件來(lái)創(chuàng)建應(yīng)用，這些應(yīng)用可獨(dú)立地進(jìn)行開發(fā)、管理和迭代。在分散的組件中使用云架構(gòu)和平臺(tái)式部署、管理和服務(wù)功能，使產(chǎn)品交付變得更加簡(jiǎn)單。

本質(zhì)： 用一些功能比較明確、業(yè)務(wù)比較精練的服務(wù)去解決更大、更實(shí)際的問(wèn)題。

-     出現(xiàn)和發(fā)展    -

微服務(wù)（Microservice）這個(gè)概念是2012年出現(xiàn)的，作為加快Web和移動(dòng)應(yīng)用程序開發(fā)進(jìn)程的一種方法，2014年開始受到各方的關(guān)注，而2015年，可以說(shuō)是微服務(wù)的元年。

越來(lái)越多的論壇、社區(qū)、blog以及互聯(lián)網(wǎng)行業(yè)巨頭開始對(duì)微服務(wù)進(jìn)行討論、實(shí)踐，可以說(shuō)這樣更近一步推動(dòng)了微服務(wù)的發(fā)展和創(chuàng)新。而微服務(wù)的流行，Martin Fowler 功不可沒(méi)。

這老頭是個(gè)奇人，特別擅長(zhǎng)抽象歸納和制造概念。特別是微服務(wù)這種新生的名詞，都有一個(gè)特點(diǎn)：一解釋就懂，一問(wèn)就不知，一討論就打架。

Martin Fowler是國(guó)際著名的OO專家，敏捷開發(fā)方法的創(chuàng)始人之一，現(xiàn)為ThoughtWorks公司的首席科學(xué)家。在面向?qū)ο蠓治鲈O(shè)計(jì)、UML、模式、軟件開發(fā)方法學(xué)、XP、重構(gòu)等方面，都是世界頂級(jí)的專家，現(xiàn)為Thought Works公司的首席科學(xué)家。Thought Works是一家從事企業(yè)應(yīng)用開發(fā)和——集成的公司。早在20世紀(jì)80年代，F(xiàn)owler就是使用對(duì)象技術(shù)構(gòu)建多層企業(yè)應(yīng)用的倡導(dǎo)者，他著有幾本經(jīng)典書籍：《企業(yè)應(yīng)用架構(gòu)模式》、《UML精粹》和《重構(gòu)》等。          

—— 百度百科

-     傳統(tǒng)開發(fā)模式和微服務(wù)的區(qū)別    -

先來(lái)看看傳統(tǒng)的web開發(fā)方式，通過(guò)對(duì)比比較容易理解什么是Microservice Architecture。和Microservice相對(duì)應(yīng)的，這種方式一般被稱為Monolithic（單體式開發(fā)）。

所有的功能打包在一個(gè) WAR包里，基本沒(méi)有外部依賴（除了容器），部署在一個(gè)JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等所有邏輯。

優(yōu)點(diǎn)：

①開發(fā)簡(jiǎn)單，集中式管理

②基本不會(huì)重復(fù)開發(fā)

③功能都在本地，沒(méi)有分布式的管理和調(diào)用消耗

缺點(diǎn)：

1、效率低：開發(fā)都在同一個(gè)項(xiàng)目改代碼，相互等待，沖突不斷

2、維護(hù)難：代碼功功能耦合在一起，新人不知道何從下手

3、不靈活：構(gòu)建時(shí)間長(zhǎng)，任何小修改都要重構(gòu)整個(gè)項(xiàng)目，耗時(shí)

4、穩(wěn)定性差：一個(gè)微小的問(wèn)題，都可能導(dǎo)致整個(gè)應(yīng)用掛掉

5、擴(kuò)展性不夠：無(wú)法滿足高并發(fā)下的業(yè)務(wù)需求

常見的系統(tǒng)架構(gòu)遵循的三個(gè)標(biāo)準(zhǔn)和業(yè)務(wù)驅(qū)動(dòng)力：

1、提高敏捷性：及時(shí)響應(yīng)業(yè)務(wù)需求，促進(jìn)企業(yè)發(fā)展

2、提升用戶體驗(yàn)：提升用戶體驗(yàn)，減少用戶流失

3、降低成本：降低增加產(chǎn)品、客戶或業(yè)務(wù)方案的成本

基于微服務(wù)架構(gòu)的設(shè)計(jì)：

目的： 有效的拆分應(yīng)用，實(shí)現(xiàn)敏捷開發(fā)和部署

關(guān)于微服務(wù)的一個(gè)形象表達(dá)：

X軸： 運(yùn)行多個(gè)負(fù)載均衡器之后的運(yùn)行實(shí)例

Y軸： 將應(yīng)用進(jìn)一步分解為微服務(wù)（分庫(kù)）

Z軸： 大數(shù)據(jù)量時(shí)，將服務(wù)分區(qū)（分表）

-     微服務(wù)的具體特征    -

官方的定義：

1、一些列的獨(dú)立的服務(wù)共同組成系統(tǒng)

2、單獨(dú)部署，跑在自己的進(jìn)程中

3、每個(gè)服務(wù)為獨(dú)立的業(yè)務(wù)開發(fā)

4、分布式管理

5、非常強(qiáng)調(diào)隔離性

大概的標(biāo)準(zhǔn)：

1、分布式服務(wù)組成的系統(tǒng)

2、按照業(yè)務(wù)，而不是技術(shù)來(lái)劃分組織

3、做有生命的產(chǎn)品而不是項(xiàng)目

4、強(qiáng)服務(wù)個(gè)體和弱通信（ Smart endpoints and dumb pipes ）

5、自動(dòng)化運(yùn)維（ DevOps ）

6、高度容錯(cuò)性

7、快速演化和迭代

-     SOA 和微服務(wù)的區(qū)別    -

1、SOA喜歡重用，微服務(wù)喜歡重寫

SOA 的主要目的是為了企業(yè)各個(gè)系統(tǒng)更加容易地融合在一起。說(shuō)到SOA不得不說(shuō)ESB(EnterpriseService Bus)。ESB是什么? 可以把ESB想象成一個(gè)連接所有企業(yè)級(jí)服務(wù)的腳手架。通過(guò)service broker，它可以把不同數(shù)據(jù)格式或模型轉(zhuǎn)成canonical格式，把XML的輸入轉(zhuǎn)成CSV傳給legacy服務(wù)，把SOAP 1.1服務(wù)轉(zhuǎn)成 SOAP 1.2等等。它還可以把一個(gè)服務(wù)路由到另一個(gè)服務(wù)上，也可以集中化管理業(yè)務(wù)邏輯，規(guī)則和驗(yàn)證等等。它還有一個(gè)重要功能是消息隊(duì)列和事件驅(qū)動(dòng)的消息傳遞，比如把JMS服務(wù)轉(zhuǎn)化成SOAP協(xié)議。各服務(wù)間可能有復(fù)雜的依賴關(guān)系。

微服務(wù)通常由重寫一個(gè)模塊開始。要把整個(gè)巨石型的應(yīng)用重寫是有很大的風(fēng)險(xiǎn)的，也不一定必要。我們向微服務(wù)遷移的時(shí)候通常從耦合度最低的模塊或?qū)U(kuò)展性要求最高的模塊開始，把它們一個(gè)一個(gè)剝離出來(lái)用敏捷地重寫，可以嘗試最新的技術(shù)和語(yǔ)言和框架，然 后單獨(dú)布署。它通常不依賴其他服務(wù)。微服務(wù)中常用的API Gateway的模式主要目的也不是重用代碼，而是減少客戶端和服務(wù)間的往來(lái)。API gateway模式不等同與Facade模式，我們可以使用如future之類的調(diào)用，甚至返回不完整數(shù)據(jù)。

2、SOA喜歡水平服務(wù)，微服務(wù)喜歡垂直服務(wù)

SOA 設(shè)計(jì)喜歡給服務(wù)分層(如Service Layers模式)。我們常常見到一個(gè)Entity服務(wù)層的設(shè)計(jì)，美其名曰Data Access Layer。這種設(shè)計(jì)要求所有的服務(wù)都通過(guò)這個(gè)Entity服務(wù)層來(lái)獲取數(shù)據(jù)。這種設(shè)計(jì)非常不靈活，比如每次數(shù)據(jù)層的改動(dòng)都可能影響到所有業(yè)務(wù)層的服務(wù)。而每個(gè)微服務(wù)通常有它自己獨(dú)立的data store。我們?cè)诓鸱謹(jǐn)?shù)據(jù)庫(kù)時(shí)可以適當(dāng)?shù)淖鲂┤シ妒交?denormalization)，讓它不需要依賴其他服務(wù)的數(shù)據(jù)。

微服務(wù) 通常是直接面對(duì)用戶的，每個(gè)微服務(wù)通常直接為用戶提供某個(gè)功能。類似的功能可能針對(duì)手機(jī)有一個(gè)服務(wù)，針對(duì)機(jī)頂盒是另外一個(gè)服務(wù)。在SOA設(shè)計(jì)模式中這種情況通常會(huì)用到Multi-ChannelEndpoint的模式返回一個(gè)大而全的結(jié)果兼顧到所有的客戶端的需求。

3、SOA喜歡自上而下，微服務(wù)喜歡自下而上

SOA 架構(gòu)在設(shè)計(jì)開始時(shí)會(huì)先定義好服務(wù)合同(service contract)。它喜歡集中管理所有的服務(wù)，包括集中管理業(yè)務(wù)邏輯，數(shù)據(jù)，流程，schema，等等。它使用Enterprise Inventory和Service Composition等方法來(lái)集中管理服務(wù)。SOA架構(gòu)通常會(huì)預(yù)先把每個(gè)模塊服務(wù)接口都定義好。模塊系統(tǒng)間的通訊必須遵守這些接口，各服務(wù)是針對(duì)他們的調(diào)用者。

SOA架構(gòu)適用于TOGAF之類的架構(gòu)方法論。

微服務(wù) 則敏捷得多。只要用戶用得到，就先把這個(gè)服務(wù)挖出來(lái)。然后針對(duì)性的，快速確認(rèn)業(yè)務(wù)需求，快速開發(fā)迭代。

-     怎么具體實(shí)踐微服務(wù)    -

要實(shí)際的應(yīng)用微服務(wù)，需要解決一下四點(diǎn)問(wèn)題：

1、客戶端如何訪問(wèn)這些服務(wù)？

2、每個(gè)服務(wù)之間如何通信？

3、如此多的服務(wù)，如何實(shí)現(xiàn)？

4、服務(wù)掛了，如何解決（備份方案，應(yīng)急處理機(jī)制）？

1、客戶端如何訪問(wèn)這些服務(wù)

原來(lái)的Monolithic方式開發(fā)，所有的服務(wù)都是本地的，UI可以直接調(diào)用，現(xiàn)在按功能拆分成獨(dú)立的服務(wù)，跑在獨(dú)立的一般都在獨(dú)立的虛擬機(jī)上的 Java進(jìn)程了?？蛻舳薝I如何訪問(wèn)他的？

后臺(tái)有N個(gè)服務(wù)，前臺(tái)就需要記住管理N個(gè)服務(wù)，一個(gè)服務(wù)下線/更新/升級(jí)，前臺(tái)就要重新部署，這明顯不服務(wù)我們 拆分的理念，特別當(dāng)前臺(tái)是移動(dòng)應(yīng)用的時(shí)候，通常業(yè)務(wù)變化的節(jié)奏更快。

另外，N個(gè)小服務(wù)的調(diào)用也是一個(gè)不小的網(wǎng)絡(luò)開銷。還有一般微服務(wù)在系統(tǒng)內(nèi)部，通常是無(wú) 狀態(tài)的，用戶登錄信息和權(quán)限管理最好有一個(gè)統(tǒng)一的地方維護(hù)管理（OAuth）。

所以，一般在后臺(tái)N個(gè)服務(wù)和UI之間一般會(huì)一個(gè)代理或者叫API Gateway，他的作用包括：

① 提供統(tǒng)一服務(wù)入口，讓微服務(wù)對(duì)前臺(tái)透明；

② 聚合后臺(tái)的服務(wù)，節(jié)省流量，提升性能；

③ 提供安全，過(guò)濾，流控等API管理功能。

其實(shí)這個(gè)API Gateway可以有很多廣義的實(shí)現(xiàn)辦法，可以是一個(gè)軟硬一體的盒子，也可以是一個(gè)簡(jiǎn)單的MVC框架，甚至是一個(gè)Node.js的服務(wù)端。他們最重要的作 用是為前臺(tái)（通常是移動(dòng)應(yīng)用）提供后臺(tái)服務(wù)的聚合，提供一個(gè)統(tǒng)一的服務(wù)出口，解除他們之間的耦合，不過(guò)API Gateway也有可能成為單點(diǎn)故障點(diǎn)或者性能的瓶頸。

用過(guò)Taobao Open Platform（淘寶開放平臺(tái)）的就能很容易的體會(huì)，TAO就是這個(gè)API Gateway。

2、每個(gè)服務(wù)之間如何通信

所有的微服務(wù)都是獨(dú)立的Java進(jìn)程跑在獨(dú)立的虛擬機(jī)上，所以服務(wù)間的通信就是IPC（inter process communication），已經(jīng)有很多成熟的方案。

現(xiàn)在基本最通用的有兩種方式：

同步調(diào)用：

①REST（JAX-RS，Spring Boot）

②RPC（Thrift, Dubbo）

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

同步和異步的區(qū)別：

一般同步調(diào)用比較簡(jiǎn)單，一致性強(qiáng)，但是容易出調(diào)用問(wèn)題，性能體驗(yàn)上也會(huì)差些，特別是調(diào)用層次多的時(shí)候。RESTful和RPC的比較也是一個(gè)很有意 思的話題。

一般REST基于HTTP，更容易實(shí)現(xiàn)，更容易被接受，服務(wù)端實(shí)現(xiàn)技術(shù)也更靈活些，各個(gè)語(yǔ)言都能支持，同時(shí)能跨客戶端，對(duì)客戶端沒(méi)有特殊的要求，只要封裝了HTTP的SDK就能調(diào)用，所以相對(duì)使用的廣一些。RPC也有自己的優(yōu)點(diǎn)，傳輸協(xié)議更高效，安全更可控，特別在一個(gè)公司內(nèi)部，如果有統(tǒng)一個(gè) 的開發(fā)規(guī)范和統(tǒng)一的服務(wù)框架時(shí)，他的開發(fā)效率優(yōu)勢(shì)更明顯些。就看各自的技術(shù)積累實(shí)際條件，自己的選擇了。

而異步消息的方式在分布式系統(tǒng)中有特別廣泛的應(yīng)用，他既能減低調(diào)用服務(wù)之間的耦合，又能成為調(diào)用之間的緩沖，確保消息積壓不會(huì)沖垮被調(diào)用方，同時(shí)能保證調(diào)用方的服務(wù)體驗(yàn)，繼續(xù)干自己該干的活，不至于被后臺(tái)性能拖慢。不過(guò)需要付出的代價(jià)是一致性的減弱，需要接受數(shù)據(jù)最終一致性；還有就是后臺(tái)服務(wù)一般要 實(shí)現(xiàn)冪等性，因?yàn)橄l(fā)送出于性能的考慮一般會(huì)有重復(fù)（保證消息的被收到且僅收到一次對(duì)性能是很大的考驗(yàn)）；最后就是必須引入一個(gè)獨(dú)立的broker，如果公司內(nèi)部沒(méi)有技術(shù)積累，對(duì)broker分布式管理也是一個(gè)很大的挑戰(zhàn)。

3、如此多的服務(wù)，如何實(shí)現(xiàn)？

在微服務(wù)架構(gòu)中，一般每一個(gè)服務(wù)都是有多個(gè)拷貝，來(lái)做負(fù)載均衡。一個(gè)服務(wù)隨時(shí)可能下線，也可能應(yīng)對(duì)臨時(shí)訪問(wèn)壓力增加新的服務(wù)節(jié)點(diǎn)。服務(wù)之間如何相互感知？服務(wù)如何管理？

這就是服務(wù)發(fā)現(xiàn)的問(wèn)題了。一般有兩類做法，也各有優(yōu)缺點(diǎn)?；径际峭ㄟ^(guò)zookeeper等類似技術(shù)做服務(wù)注冊(cè)信息的分布式管理。當(dāng)服務(wù)上線時(shí)，服務(wù)提供者將自己的服務(wù)信息注冊(cè)到ZK（或類似框架），并通過(guò)心跳維持長(zhǎng)鏈接，實(shí)時(shí)更新鏈接信息。服務(wù)調(diào)用者通過(guò)ZK尋址，根據(jù)可定制算法， 找到一個(gè)服務(wù)，還可以將服務(wù)信息緩存在本地以提高性能。當(dāng)服務(wù)下線時(shí)，ZK會(huì)發(fā)通知給服務(wù)客戶端。

客戶端做： 優(yōu)點(diǎn)是架構(gòu)簡(jiǎn)單，擴(kuò)展靈活，只對(duì)服務(wù)注冊(cè)器依賴。缺點(diǎn)是客戶端要維護(hù)所有調(diào)用服務(wù)的地址，有技術(shù)難度，一般大公司都有成熟的內(nèi)部框架支持，比如Dubbo。

服務(wù)端做： 優(yōu)點(diǎn)是簡(jiǎn)單，所有服務(wù)對(duì)于前臺(tái)調(diào)用方透明，一般在小公司在云服務(wù)上部署的應(yīng)用采用的比較多。

4、服務(wù)掛了，如何解決

前面提到，Monolithic方式開發(fā)一個(gè)很大的風(fēng)險(xiǎn)是，把所有雞蛋放在一個(gè)籃子里，一榮俱榮，一損俱損。而分布式最大的特性就是網(wǎng)絡(luò)是不可靠的。通過(guò)微服務(wù)拆分能降低這個(gè)風(fēng)險(xiǎn)，不過(guò)如果沒(méi)有特別的保障，結(jié)局肯定是噩夢(mèng)。所以當(dāng)我們的系統(tǒng)是由一系列的服務(wù)調(diào)用鏈組成的時(shí)候，我們必須確保任一環(huán)節(jié)出問(wèn)題都不至于影響整體鏈路。

相應(yīng)的手段有很多：

①重試機(jī)制

②限流

③熔斷機(jī)制

④負(fù)載均衡

⑤降級(jí)（本地緩存）

這些方法基本都很明確通用，比如Netflix的Hystrix：

https://github.com/Netflix/Hystrix

-     常見的設(shè)計(jì)模式和應(yīng)用    -

有一個(gè)圖非常好的總結(jié)微服務(wù)架構(gòu)需要考慮的問(wèn)題，包括：

1、API Gateway

2、服務(wù)間調(diào)用

3、服務(wù)發(fā)現(xiàn)

4、服務(wù)容錯(cuò)

5、服務(wù)部署

6、數(shù)據(jù)調(diào)用

-     六種常見的微服務(wù)架構(gòu)設(shè)計(jì)模式    -

1、聚合器微服務(wù)設(shè)計(jì)模式

這是一種最常見也最簡(jiǎn)單的設(shè)計(jì)模式：

聚合器調(diào)用多個(gè)服務(wù)實(shí)現(xiàn)應(yīng)用程序所需的功能。它可以是一個(gè)簡(jiǎn)單的Web頁(yè)面，將檢索到的數(shù)據(jù)進(jìn)行處理展示。它也可以是一個(gè)更高層次的組合微服務(wù)，對(duì)檢索到的數(shù)據(jù)增加業(yè)務(wù)邏輯后進(jìn)一步發(fā)布成一個(gè)新的微服務(wù)，這符合DRY原則。另外，每個(gè)服務(wù)都有自己的緩存和數(shù)據(jù)庫(kù)。如果聚合器是一個(gè)組合服務(wù)，那么它也有自己的緩存和數(shù)據(jù)庫(kù)。聚合器可以沿X軸和Z軸獨(dú)立擴(kuò)展。

2、代理微服務(wù)設(shè)計(jì)模式

這是聚合模式的一個(gè)變種，如下圖所示：

在這種情況下，客戶端并不聚合數(shù)據(jù)，但會(huì)根據(jù)業(yè)務(wù)需求的差別調(diào)用不同的微服務(wù)。代理可以僅僅委派請(qǐng)求，也可以進(jìn)行數(shù)據(jù)轉(zhuǎn)換工作。

3、鏈?zhǔn)轿⒎?wù)設(shè)計(jì)模式

這種模式在接收到請(qǐng)求后會(huì)產(chǎn)生一個(gè)經(jīng)過(guò)合并的響應(yīng)，如下圖所示：

在這種情況下，服務(wù)A接收到請(qǐng)求后會(huì)與服務(wù)B進(jìn)行通信，類似地，服務(wù)B會(huì)同服務(wù)C進(jìn)行通信。所有服務(wù)都使用同步消息傳遞。在整個(gè)鏈?zhǔn)秸{(diào)用完成之前，客戶端會(huì)一直阻塞。

因此，服務(wù)調(diào)用鏈不宜過(guò)長(zhǎng)，以免客戶端長(zhǎng)時(shí)間等待。

4、分支微服務(wù)設(shè)計(jì)模式

這種模式是聚合器模式的擴(kuò)展，允許同時(shí)調(diào)用兩個(gè)微服務(wù)鏈，如下圖所示：

5、數(shù)據(jù)共享微服務(wù)設(shè)計(jì)模式

自治是微服務(wù)的設(shè)計(jì)原則之一，就是說(shuō)微服務(wù)是全棧式服務(wù)。但在重構(gòu)現(xiàn)有的“單體應(yīng)用（monolithic application）”時(shí)，SQL數(shù)據(jù)庫(kù)反規(guī)范化可能會(huì)導(dǎo)致數(shù)據(jù)重復(fù)和不一致。

因此，在單體應(yīng)用到微服務(wù)架構(gòu)的過(guò)渡階段，可以使用這種設(shè)計(jì)模式，如下圖所示：

在這種情況下，部分微服務(wù)可能會(huì)共享緩存和數(shù)據(jù)庫(kù)存儲(chǔ)。不過(guò)，這只有在兩個(gè)服務(wù)之間存在強(qiáng)耦合關(guān)系時(shí)才可以。對(duì)于基于微服務(wù)的新建應(yīng)用程序而言，這是一種反模式。

6、異步消息傳遞微服務(wù)設(shè)計(jì)模式

雖然REST設(shè)計(jì)模式非常流行，但它是同步的，會(huì)造成阻塞。因此部分基于微服務(wù)的架構(gòu)可能會(huì)選擇使用消息隊(duì)列代替REST請(qǐng)求/響應(yīng)，如下圖所示：

-     優(yōu)點(diǎn)和缺點(diǎn)    -

1、微服務(wù)的優(yōu)點(diǎn)：

關(guān)鍵點(diǎn)： 復(fù)雜度可控，獨(dú)立按需擴(kuò)展，技術(shù)選型靈活，容錯(cuò)，可用性高。

① 它解決了復(fù)雜性的問(wèn)題。它會(huì)將一種怪異的整體應(yīng)用程序分解成一組服務(wù)。雖然功能總量 不變，但應(yīng)用程序已分解為可管理的塊或服務(wù)。每個(gè)服務(wù)都以RPC或消息驅(qū)動(dòng)的API的形式定義了一個(gè)明確的邊界；Microservice架構(gòu)模式實(shí)現(xiàn)了一個(gè)模塊化水平。

② 這種架構(gòu)使每個(gè)服務(wù)都能夠由專注于該服務(wù)的團(tuán)隊(duì)獨(dú)立開發(fā)。開發(fā)人員可以自由選擇任何有用的技術(shù)，只要該服務(wù)符合API合同。當(dāng)然，大多數(shù)組織都希望避免完全無(wú)政府狀態(tài)并限制技術(shù)選擇。然而，這種自由意味著開發(fā)人員不再有義務(wù)使用在新項(xiàng)目開始時(shí)存在的可能過(guò)時(shí)的技術(shù)。在編寫新服務(wù)時(shí)，他們可以選擇使用當(dāng)前的技術(shù)。此外，由于服務(wù)相對(duì)較小，因此使用當(dāng)前技術(shù)重寫舊服務(wù)變得可行。

③ Microservice架構(gòu)模式使每個(gè)微服務(wù)都能獨(dú)立部署。開發(fā)人員不需要協(xié)調(diào)部署本地服務(wù)的變更。這些變化可以在測(cè)試后盡快部署。例如，UI團(tuán)隊(duì)可以執(zhí)行A | B測(cè)試，并快速迭代UI更改。Microservice架構(gòu)模式使連續(xù)部署成為可能。

④ Microservice架構(gòu)模式使每個(gè)服務(wù)都可以獨(dú)立調(diào)整。您可以僅部署滿足其容量和可用性限制的每個(gè)服務(wù)的實(shí)例數(shù)。此外，您可以使用最符合服務(wù)資源要求的硬件。

2、微服務(wù)的缺點(diǎn)

關(guān)鍵點(diǎn)（挑戰(zhàn)）： ，系統(tǒng)部署依賴，服務(wù)間通信成本，數(shù)據(jù)一致性，系統(tǒng)集成測(cè)試，重復(fù)工作，性能監(jiān)控等。

① 一個(gè)缺點(diǎn)是名稱本身。術(shù)語(yǔ)microservice過(guò)度強(qiáng)調(diào)服務(wù)規(guī)模。但重要的是要記住，這是一種手段，而不是主要目標(biāo)。微服務(wù)的目標(biāo)是充分分解應(yīng)用程序，以便于敏捷應(yīng)用程序開發(fā)和部署。

② 微服務(wù)器的另一個(gè)主要缺點(diǎn)是分布式系統(tǒng)而產(chǎn)生的復(fù)雜性。開發(fā)人員需要選擇和實(shí)現(xiàn)基于消息傳遞或RPC的進(jìn)程間通信機(jī)制。此外，他們還必須編寫代碼來(lái)處理部分故障，因?yàn)檎?qǐng)求的目的地可能很慢或不可用。

③ 微服務(wù)器的另一個(gè)挑戰(zhàn)是分區(qū)數(shù)據(jù)庫(kù)架構(gòu)。更新多個(gè)業(yè)務(wù)實(shí)體的業(yè)務(wù)交易是相當(dāng)普遍的。但是，在基于微服務(wù)器的應(yīng)用程序中，您需要更新不同服務(wù)所擁有的多個(gè)數(shù)據(jù)庫(kù)。使用分布式事務(wù)通常不是一個(gè)選擇，而不僅僅是因?yàn)镃AP定理。許多今天高度可擴(kuò)展的NoSQL數(shù)據(jù)庫(kù)都不支持它們。你最終不得不使用最終的一致性方法，這對(duì)開發(fā)人員來(lái)說(shuō)更具挑戰(zhàn)性。

④ 測(cè)試微服務(wù)應(yīng)用程序也更復(fù)雜。服務(wù)類似的測(cè)試類將需要啟動(dòng)該服務(wù)及其所依賴的任何服務(wù)（或至少為這些服務(wù)配置存根）。再次，重要的是不要低估這樣做的復(fù)雜性。

⑤ Microservice架構(gòu)模式的另一個(gè)主要挑戰(zhàn)是實(shí)現(xiàn)跨越多個(gè)服務(wù)的更改。例如，我們假設(shè)您正在實(shí)施一個(gè)需要更改服務(wù)A，B和C的故事，其中A取決于B和B取決于C.在單片應(yīng)用程序中，您可以簡(jiǎn)單地更改相應(yīng)的模塊，整合更改，并一次性部署。相比之下，在Microservice架構(gòu)模式中，您需要仔細(xì)規(guī)劃和協(xié)調(diào)對(duì)每個(gè)服務(wù)的更改。例如，您需要更新服務(wù)C，然后更新服務(wù)B，然后再維修A.幸運(yùn)的是，大多數(shù)更改通常僅影響一個(gè)服務(wù)，而需要協(xié)調(diào)的多服務(wù)變更相對(duì)較少。

⑥ 部署基于微服務(wù)的應(yīng)用程序也更復(fù)雜。單一應(yīng)用程序簡(jiǎn)單地部署在傳統(tǒng)負(fù)載平衡器后面的一組相同的服務(wù)器上。每個(gè)應(yīng)用程序?qū)嵗寂渲糜谢A(chǔ)架構(gòu)服務(wù)（如數(shù)據(jù)庫(kù)和消息代理）的位置（主機(jī)和端口）。相比之下，微服務(wù)應(yīng)用通常由大量服務(wù)組成。例如，每個(gè)服務(wù)將有多個(gè)運(yùn)行時(shí)實(shí)例。更多的移動(dòng)部件需要進(jìn)行配置，部署，擴(kuò)展和監(jiān)控。此外，您還需要實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)機(jī)制，使服務(wù)能夠發(fā)現(xiàn)需要與之通信的任何其他服務(wù)的位置（主機(jī)和端口）。傳統(tǒng)的基于故障單和手動(dòng)操作的方法無(wú)法擴(kuò)展到這種復(fù)雜程度。因此，成功部署微服務(wù)應(yīng)用程序需要開發(fā)人員更好地控制部署方法，并實(shí)現(xiàn)高水平的自動(dòng)化。

-     思考：思維模型的轉(zhuǎn)變    -

微服務(wù)對(duì)我們的思考，更多的是思維上的轉(zhuǎn)變。對(duì)于微服務(wù)架構(gòu)：技術(shù)上不是問(wèn)題，意識(shí)比工具重要。

關(guān)于微服務(wù)的幾點(diǎn)設(shè)計(jì)出發(fā)點(diǎn)：

1、應(yīng)用程序的核心是業(yè)務(wù)邏輯，按照業(yè)務(wù)或客戶需求組織資源（這是最難的）；

2、做有生命的產(chǎn)品，而不是項(xiàng)目；

3、頭狼戰(zhàn)隊(duì)，全?；?；

4、后臺(tái)服務(wù)貫徹Single Responsibility Principle（單一職責(zé)原則）；

5、VM->Docker （to PE）；

6、DevOps (to PE)。

同時(shí)，對(duì)于開發(fā)同學(xué)，有這么多的中間件和強(qiáng)大的PE支持固然是好事，我們也需要深入去了解這些中間件背后的原理，知其然知其所以然，在有限的技術(shù)資源如何通過(guò)開源技術(shù)實(shí)施微服務(wù)？

最后，一般提到微服務(wù)都離不開DevOps和Docker，理解微服務(wù)架構(gòu)是核心，devops和docker是工具，是手段。

-     參考資料和推薦閱讀    -

• 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
  
  

來(lái)源：

cnblogs.com/imyalost/p/6792724.html