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

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

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

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

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

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

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

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

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

Martin Fowler是國際著名的OO專家尾序，敏捷開發(fā)方法的創(chuàng)始人之一，現(xiàn)為ThoughtWorks公司的首

席科學(xué)家躯砰。在面向?qū)ο蠓治鲈O(shè)計、UML携丁、模式琢歇、軟件開發(fā)方法學(xué)、XP梦鉴、重構(gòu)等方面李茫，都是世界頂級的

專家，現(xiàn)為Thought Works公司的首席科學(xué)家肥橙。Thought Works是一家從事企業(yè)應(yīng)用開發(fā)和——集

成的公司魄宏。早在20世紀(jì)80年代，F(xiàn)owler就是使用對象技術(shù)構(gòu)建多層企業(yè)應(yīng)用的倡導(dǎo)者存筏，他著有幾

本經(jīng)典書籍： 《企業(yè)應(yīng)用架構(gòu)模式》宠互、《UML精粹》和《重構(gòu)》等。

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

先來看看傳統(tǒng)的web開發(fā)方式予跌，通過對比比較容易理解什么是Microservice Architecture。和Microservice相對應(yīng)的善茎，這種方式一般被稱為Monolithic（單體式開發(fā)）券册。

所有的功能打包在一個 WAR包里，基本沒有外部依賴（除了容器）垂涯，部署在一個JEE容器（Tomcat烁焙，JBoss，WebLogic）里耕赘，包含了 DO/DAO骄蝇，Service，UI等所有邏輯鞠苟。

大型互聯(lián)網(wǎng)公司微服務(wù)架構(gòu)進(jìn)化史

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

①開發(fā)簡單乞榨，集中式管理

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

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

缺點(diǎn)：

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

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

3河质、不靈活：構(gòu)建時間長，任何小修改都要重構(gòu)整個項(xiàng)目震叙，耗時

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

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

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

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

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

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

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

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

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

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

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

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

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

官方的定義：

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

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

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

4、分布式管理

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

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

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

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

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

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

5混萝、自動化運(yùn)維（ DevOps ）

6遗遵、高度容錯性

7、快速演化和迭代

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

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

SOA的主要目的是為了企業(yè)各個系統(tǒng)更加容易地融合在一起崭倘。 說到SOA不得不說ESB(EnterpriseService Bus)翼岁。 ESB是什么? 可以把ESB想象成一個連接所有企業(yè)級服務(wù)的腳手架类垫。

通過service broker，它可以把不同數(shù)據(jù)格式或模型轉(zhuǎn)成canonical格式琅坡，把XML的輸入轉(zhuǎn)成CSV傳給legacy服務(wù)悉患，把SOAP 1.1服務(wù)轉(zhuǎn)成 SOAP 1.2等等。 它還可以把一個服務(wù)

路由到另一個服務(wù)上榆俺，也可以集中化管理業(yè)務(wù)邏輯售躁，規(guī)則和驗(yàn)證等等。 它還有一個重要功能是消息隊(duì)列和事件驅(qū)動的消息傳遞茴晋，比如把JMS服務(wù)轉(zhuǎn)化成SOAP協(xié)議陪捷。 各服務(wù)間可能有

復(fù)雜的依賴關(guān)系。

微服務(wù)通常由重寫一個模塊開始诺擅。要把整個巨石型的應(yīng)用重寫是有很大的風(fēng)險的市袖，也不一定必要。我們向微服務(wù)遷移的時候通常從耦合度最低的模塊或?qū)U(kuò)展性要求最高的模塊開始烁涌，

把它們一個一個剝離出來用敏捷地重寫凌盯，可以嘗試最新的技術(shù)和語言和框架，然 后單獨(dú)布署烹玉。 它通常不依賴其他服務(wù)。微服務(wù)中常用的API Gateway的模式主要目的也不是重用代碼阐滩，

而是減少客戶端和服務(wù)間的往來二打。API gateway模式不等同與Facade模式，我們可以使用如future之類的調(diào)用掂榔，甚至返回不完整數(shù)據(jù)继效。

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

SOA設(shè)計喜歡給服務(wù)分層(如Service Layers模式)瑞信。 我們常常見到一個Entity服務(wù)層的設(shè)計，美其名曰Data Access Layer穴豫。 這種設(shè)計要求所有的服務(wù)都通過這個Entity服務(wù)層

來獲取數(shù)據(jù)凡简。 這種設(shè)計非常不靈活，比如每次數(shù)據(jù)層的改動都可能影響到所有業(yè)務(wù)層的服務(wù)精肃。 而每個微服務(wù)通常有它自己獨(dú)立的data store秤涩。 我們在拆分?jǐn)?shù)據(jù)庫時可以適當(dāng)?shù)淖鲂?/p>

去范式化(denormalization)，讓它不需要依賴其他服務(wù)的數(shù)據(jù)司抱。

微服務(wù)通常是直接面對用戶的筐眷，每個微服務(wù)通常直接為用戶提供某個功能。 類似的功能可能針對手機(jī)有一個服務(wù)习柠，針對機(jī)頂盒是另外一個服務(wù)匀谣。 在SOA設(shè)計模式中這種情況通常會用到

Multi-ChannelEndpoint的模式返回一個大而全的結(jié)果兼顧到所有的客戶端的需求照棋。

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

SOA架構(gòu)在設(shè)計開始時會先定義好服務(wù)合同(service contract)。 它喜歡集中管理所有的服務(wù)鸭丛，包括集中管理業(yè)務(wù)邏輯后频，數(shù)據(jù)梳庆，流程，schema卑惜，等等膏执。 它使用Enterprise

Inventory和Service Composition等方法來集中管理服務(wù)。 SOA架構(gòu)通常會預(yù)先把每個模塊服務(wù)接口都定義好露久。 模塊系統(tǒng)間的通訊必須遵守這些接口更米，各服務(wù)是針對他們的調(diào)用者。

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

微服務(wù)則敏捷得多征峦。只要用戶用得到，就先把這個服務(wù)挖出來消请。然后針對性的栏笆，快速確認(rèn)業(yè)務(wù)需求，快速開發(fā)迭代臊泰。

在此我向大家推薦一個架構(gòu)學(xué)習(xí)交流群蛉加。交流學(xué)習(xí)群號：478030634 ?里面會分享一些資深架構(gòu)師錄制的視頻錄像：有Spring，MyBatis缸逃，Netty源碼分析针饥，高并發(fā)、高性能需频、分布式丁眼、微服務(wù)架構(gòu)的原理，JVM性能優(yōu)化昭殉、分布式架構(gòu)等這些成為架構(gòu)師必備的知識體系苞七。還能領(lǐng)取免費(fèi)的學(xué)習(xí)資源，目前受益良多

六饲化、怎么具體實(shí)踐微服務(wù)

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

客戶端如何訪問這些服務(wù)

每個服務(wù)之間如何通信

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

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

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

原來的Monolithic方式開發(fā)巧号，所有的服務(wù)都是本地的，UI可以直接調(diào)用姥闭，現(xiàn)在按功能拆分成獨(dú)立的服務(wù)丹鸿，跑在獨(dú)立的一般都在獨(dú)立的虛擬機(jī)上的 Java進(jìn)程了∨锲罚客戶端UI如何訪問他的靠欢？

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

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

所以，一般在后臺N個服務(wù)和UI之間一般會一個代理或者叫API Gateway驱入，他的作用包括：

① 提供統(tǒng)一服務(wù)入口拧粪，讓微服務(wù)對前臺透明

② 聚合后臺的服務(wù)，節(jié)省流量沧侥，提升性能

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

其實(shí)這個API Gateway可以有很多廣義的實(shí)現(xiàn)辦法宴杀，可以是一個軟硬一體的盒子，也可以是一個簡單的MVC框架拾因，甚至是一個Node.js的服務(wù)端旺罢。他們最重要的作 用是為前臺（通常是

移動應(yīng)用）提供后臺服務(wù)的聚合，提供一個統(tǒng)一的服務(wù)出口绢记，解除他們之間的耦合扁达，不過API Gateway也有可能成為單點(diǎn)故障點(diǎn)或者性能的瓶頸。

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

2、每個服務(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)用比較簡單图仓，一致性強(qiáng)罐盔，但是容易出調(diào)用問題，性能體驗(yàn)上也會差些救崔，特別是調(diào)用層次多的時候惶看。RESTful和RPC的比較也是一個很有意 思的話題。

一般REST基于HTTP六孵，更容易實(shí)現(xiàn)纬黎，更容易被接受，服務(wù)端實(shí)現(xiàn)技術(shù)也更靈活些狸臣，各個語言都能支持莹桅，同時能跨客戶端，對客戶端沒有特殊的要求烛亦，只要封裝了HTTP的

SDK就能調(diào)用诈泼，所以相對使用的廣一些。RPC也有自己的優(yōu)點(diǎn)煤禽，傳輸協(xié)議更高效铐达，安全更可控，特別在一個公司內(nèi)部檬果，如果有統(tǒng)一個 的開發(fā)規(guī)范和統(tǒng)一的服務(wù)框架時瓮孙，

他的開發(fā)效率優(yōu)勢更明顯些。就看各自的技術(shù)積累實(shí)際條件选脊，自己的選擇了杭抠。

而異步消息的方式在分布式系統(tǒng)中有特別廣泛的應(yīng)用，他既能減低調(diào)用服務(wù)之間的耦合恳啥，又能成為調(diào)用之間的緩沖偏灿，確保消息積壓不會沖垮被調(diào)用方，同時能保證調(diào)用方的

服務(wù)體驗(yàn)钝的，繼續(xù)干自己該干的活翁垂，不至于被后臺性能拖慢。不過需要付出的代價是一致性的減弱硝桩，需要接受數(shù)據(jù)最終一致性沿猜；還有就是后臺服務(wù)一般要 實(shí)現(xiàn)冪等性，因?yàn)橄?/p>

發(fā)送出于性能的考慮一般會有重復(fù)（保證消息的被收到且僅收到一次對性能是很大的考驗(yàn)）碗脊；最后就是必須引入一個獨(dú)立的broker啼肩，如果公司內(nèi)部沒有技術(shù)積累，

對broker分布式管理也是一個很大的挑戰(zhàn)。

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

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

這就是服務(wù)發(fā)現(xiàn)的問題了蹦漠。一般有兩類做法，也各有優(yōu)缺點(diǎn)车海〉言埃基本都是通過zookeeper等類似技術(shù)做服務(wù)注冊信息的分布式管理。當(dāng)服務(wù)上線時侍芝，服務(wù)提供者將自己的服務(wù)信息

注冊到ZK（或類似框架）研铆，并通過心跳維持長鏈接，實(shí)時更新鏈接信息州叠。服務(wù)調(diào)用者通過ZK尋址棵红，根據(jù)可定制算法， 找到一個服務(wù)咧栗，還可以將服務(wù)信息緩存在本地以提高性能逆甜。

當(dāng)服務(wù)下線時，ZK會發(fā)通知給服務(wù)客戶端致板。

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

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

4咽块、服務(wù)掛了绘面，如何解決

前面提到，Monolithic方式開發(fā)一個很大的風(fēng)險是，把所有雞蛋放在一個籃子里揭璃，一榮俱榮晚凿，一損俱損。而分布式最大的特性就是網(wǎng)絡(luò)是不可靠的瘦馍。通過微服務(wù)拆分能降低這個風(fēng)險歼秽，

不過如果沒有特別的保障，結(jié)局肯定是噩夢情组。所以當(dāng)我們的系統(tǒng)是由一系列的服務(wù)調(diào)用鏈組成的時候燥筷，我們必須確保任一環(huán)節(jié)出問題都不至于影響整體鏈路。相應(yīng)的手段有很多：

①重試機(jī)制

②限流

③熔斷機(jī)制

④負(fù)載均衡

⑤降級（本地緩存）

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

七肆氓、常見的設(shè)計模式和應(yīng)用

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

1底瓣、API Gateway

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

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

4捐凭、服務(wù)容錯

5拨扶、服務(wù)部署

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

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

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

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

聚合器調(diào)用多個服務(wù)實(shí)現(xiàn)應(yīng)用程序所需的功能屈雄。它可以是一個簡單的Web頁面，將檢索到的數(shù)據(jù)進(jìn)行處理展示官套。它也可以是一個更高層次的組合微服務(wù)酒奶，對檢索到的數(shù)據(jù)增加業(yè)務(wù)邏輯后進(jìn)一步

發(fā)布成一個新的微服務(wù)，這符合DRY原則奶赔。另外惋嚎，每個服務(wù)都有自己的緩存和數(shù)據(jù)庫。如果聚合器是一個組合服務(wù)站刑，那么它也有自己的緩存和數(shù)據(jù)庫另伍。聚合器可以沿X軸和Z軸獨(dú)立擴(kuò)展。

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

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

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

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

這種模式在接收到請求后會產(chǎn)生一個經(jīng)過合并的響應(yīng)琐鲁，如下圖所示：

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

因此跪呈，服務(wù)調(diào)用鏈不宜過長段磨，以免客戶端長時間等待。

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

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

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

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

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

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

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

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

八件豌、優(yōu)點(diǎn)和缺點(diǎn)

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

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

①它解決了復(fù)雜性的問題棘街。它會將一種怪異的整體應(yīng)用程序分解成一組服務(wù)。雖然功能總量 不變承边，但應(yīng)用程序已分解為可管理的塊或服務(wù)遭殉。每個服務(wù)都以RPC或消息驅(qū)動的API的

形式定義了一個明確的邊界；Microservice架構(gòu)模式實(shí)現(xiàn)了一個模塊化水平博助。

②這種架構(gòu)使每個服務(wù)都能夠由專注于該服務(wù)的團(tuán)隊(duì)獨(dú)立開發(fā)险污。開發(fā)人員可以自由選擇任何有用的技術(shù)，只要該服務(wù)符合API合同富岳。當(dāng)然蛔糯，大多數(shù)組織都希望避免完全無政府狀態(tài)并

限制技術(shù)選擇。然而窖式，這種自由意味著開發(fā)人員不再有義務(wù)使用在新項(xiàng)目開始時存在的可能過時的技術(shù)。在編寫新服務(wù)時淮逻，他們可以選擇使用當(dāng)前的技術(shù)阁簸。此外爬早，由于服務(wù)相對較小，

因此使用當(dāng)前技術(shù)重寫舊服務(wù)變得可行筛严。

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

UI更改网杆。Microservice架構(gòu)模式使連續(xù)部署成為可能伊滋。

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

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

關(guān)鍵點(diǎn)（挑戰(zhàn)）：多服務(wù)運(yùn)維難度虐沥，系統(tǒng)部署依賴，服務(wù)間通信成本镐依，數(shù)據(jù)一致性槐壳，系統(tǒng)集成測試秋秤，重復(fù)工作，性能監(jiān)控等

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

②微服務(wù)器的另一個主要缺點(diǎn)是分布式系統(tǒng)而產(chǎn)生的復(fù)雜性拍嵌。開發(fā)人員需要選擇和實(shí)現(xiàn)基于消息傳遞或RPC的進(jìn)程間通信機(jī)制横辆。此外茄猫，他們還必須編寫代碼來處理部分故障困肩，

因?yàn)檎埱蟮哪康牡乜赡芎苈虿豢捎谩?/p>

③微服務(wù)器的另一個挑戰(zhàn)是分區(qū)數(shù)據(jù)庫架構(gòu)僻弹。更新多個業(yè)務(wù)實(shí)體的業(yè)務(wù)交易是相當(dāng)普遍的他嚷。但是筋蓖，在基于微服務(wù)器的應(yīng)用程序中退敦，您需要更新不同服務(wù)所擁有的多個數(shù)據(jù)庫。使用分布式事務(wù)

通常不是一個選擇瓮下，而不僅僅是因?yàn)镃AP定理讽坏。許多今天高度可擴(kuò)展的NoSQL數(shù)據(jù)庫都不支持它們例证。你最終不得不使用最終的一致性方法，這對開發(fā)人員來說更具挑戰(zhàn)性胀葱。

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

⑤Microservice架構(gòu)模式的另一個主要挑戰(zhàn)是實(shí)現(xiàn)跨越多個服務(wù)的更改姜胖。例如淀散，我們假設(shè)您正在實(shí)施一個需要更改服務(wù)A蚜锨，B和C的故事亚再，其中A取決于B和B取決于C.在單片應(yīng)用程序中晨抡，

您可以簡單地更改相應(yīng)的模塊耘柱，整合更改，并一次性部署镜遣。相比之下士袄，在Microservice架構(gòu)模式中娄柳，您需要仔細(xì)規(guī)劃和協(xié)調(diào)對每個服務(wù)的更改。例如讶舰，您需要更新服務(wù)C需了，然后更新服務(wù)B肋乍，

然后再維修A.幸運(yùn)的是，大多數(shù)更改通常僅影響一個服務(wù)堪伍，而需要協(xié)調(diào)的多服務(wù)變更相對較少觅闽。

⑥部署基于微服務(wù)的應(yīng)用程序也更復(fù)雜蛉拙。單一應(yīng)用程序簡單地部署在傳統(tǒng)負(fù)載平衡器后面的一組相同的服務(wù)器上。每個應(yīng)用程序?qū)嵗寂渲糜谢A(chǔ)架構(gòu)服務(wù)（如數(shù)據(jù)庫和消息代理）

的位置（主機(jī)和端口）吮廉。相比之下宦芦，微服務(wù)應(yīng)用通常由大量服務(wù)組成。例如抡砂，每個服務(wù)將有多個運(yùn)行時實(shí)例恬涧。更多的移動部件需要進(jìn)行配置气破，部署餐抢，擴(kuò)展和監(jiān)控旷痕。此外，您還需要實(shí)現(xiàn)服務(wù)

發(fā)現(xiàn)機(jī)制售碳，使服務(wù)能夠發(fā)現(xiàn)需要與之通信的任何其他服務(wù)的位置（主機(jī)和端口）绞呈。傳統(tǒng)的基于故障單和手動操作的方法無法擴(kuò)展到這種復(fù)雜程度佃声。因此，成功部署微服務(wù)應(yīng)用程序需要

開發(fā)人員更好地控制部署方法十拣，并實(shí)現(xiàn)高水平的自動化夭问。

九曹铃、思考：意識的轉(zhuǎn)變

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

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

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

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

3、頭狼戰(zhàn)隊(duì)蚂会，全椥沧。化

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

5娱挨、VM->Docker （to PE）

6、DevOps (to PE)

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

在此我向大家推薦一個架構(gòu)學(xué)習(xí)交流群啸澡。交流學(xué)習(xí)群號：478030634 ?里面會分享一些資深架構(gòu)師錄制的視頻錄像：有Spring，MyBatis洛姑，Netty源碼分析皮服，高并發(fā)硫眯、高性能、分布式戈盈、微服務(wù)架構(gòu)的原理塘娶，JVM性能優(yōu)化、分布式架構(gòu)等這些成為架構(gòu)師必備的知識體系脏里。還能領(lǐng)取免費(fèi)的學(xué)習(xí)資源迫横，目前受益良多

大家覺得文章對你還是有一點(diǎn)點(diǎn)幫助的矾踱，大家可以點(diǎn)擊下方二維碼進(jìn)行關(guān)注疏哗。 《Java爛豬皮》 公眾號聊的不僅僅是Java技術(shù)知識，還有面試等干貨贝搁，后期還有大量架構(gòu)干貨雷逆。大家一起關(guān)注吧关面！關(guān)注爛豬皮，你會了解的更多..............