資料來源：有架構(gòu)給我的一些資料眼虱，以及自己百度和論壇喻奥、社區(qū)找來的一些資料，權(quán)當做一個總結(jié)式的簡介捏悬。撞蚕。。
目錄如下：
一过牙、微服務(wù)架構(gòu)介紹
二甥厦、出現(xiàn)和發(fā)展
三、傳統(tǒng)開發(fā)模式和微服務(wù)的區(qū)別
四寇钉、微服務(wù)的具體特征
五刀疙、SOA和微服務(wù)的區(qū)別
六、如何具體實踐微服務(wù)
七扫倡、常見的微服務(wù)設(shè)計模式和應(yīng)用
八谦秧、微服務(wù)的優(yōu)點和缺點
九、思考：意識的轉(zhuǎn)變
十撵溃、參考資料和推薦閱讀
一疚鲤、微服務(wù)架構(gòu)介紹
微服務(wù)架構(gòu)（Microservice Architecture）是一種架構(gòu)概念，旨在通過將功能分解到各個離散的服務(wù)中以實現(xiàn)對解決方案的解耦缘挑。你可以將其看作是在架構(gòu)層次而非獲取服務(wù)的
類上應(yīng)用很多SOLID原則集歇。微服務(wù)架構(gòu)是個很有趣的概念，它的主要作用是將功能分解到離散的各個服務(wù)當中语淘，從而降低系統(tǒng)的耦合性诲宇，并提供更加靈活的服務(wù)支持际歼。
概念：把一個大型的單個應(yīng)用程序和服務(wù)拆分為數(shù)個甚至數(shù)十個的支持微服務(wù)，它可擴展單個組件而不是整個的應(yīng)用程序堆棧焕窝，從而滿足服務(wù)等級協(xié)議蹬挺。
定義：圍繞業(yè)務(wù)領(lǐng)域組件來創(chuàng)建應(yīng)用，這些應(yīng)用可獨立地進行開發(fā)它掂、管理和迭代巴帮。在分散的組件中使用云架構(gòu)和平臺式部署、管理和服務(wù)功能虐秋，使產(chǎn)品交付變得更加簡單榕茧。
本質(zhì)：用一些功能比較明確、業(yè)務(wù)比較精練的服務(wù)去解決更大客给、更實際的問題用押。
二、出現(xiàn)和發(fā)展
微服務(wù)（Microservice）這個概念是2012年出現(xiàn)的靶剑，作為加快Web和移動應(yīng)用程序開發(fā)進程的一種方法蜻拨，2014年開始受到各方的關(guān)注，而2015年桩引，可以說是微服務(wù)的元年缎讼；
越來越多的論壇、社區(qū)坑匠、blog以及互聯(lián)網(wǎng)行業(yè)巨頭開始對微服務(wù)進行討論血崭、實踐，可以說這樣更近一步推動了微服務(wù)的發(fā)展和創(chuàng)新厘灼。而微服務(wù)的流行夹纫，Martin Fowler功不可沒。
這老頭是個奇人设凹，特別擅長抽象歸納和制造概念舰讹。特別是微服務(wù)這種新生的名詞靖苇，都有一個特點：一解釋就懂以躯，一問就不知，一討論就打架卷哩。
Martin Fowler是國際著名的OO專家监透，敏捷開發(fā)方法的創(chuàng)始人之一桶错，現(xiàn)為ThoughtWorks公司的首
席科學家。在面向?qū)ο蠓治鲈O(shè)計胀蛮、UML院刁、模式、軟件開發(fā)方法學粪狼、XP退腥、重構(gòu)等方面任岸，都是世界頂級的
專家，現(xiàn)為Thought Works公司的首席科學家狡刘。Thought Works是一家從事企業(yè)應(yīng)用開發(fā)和——集
成的公司享潜。早在20世紀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等所有邏輯畦贸。
優(yōu)點：
①開發(fā)簡單，集中式管理
②基本不會重復(fù)開發(fā)
③功能都在本地楞捂，沒有分布式的管理和調(diào)用消耗
缺點：
1薄坏、效率低：開發(fā)都在同一個項目改代碼，相互等待寨闹，沖突不斷
2胶坠、維護難：代碼功功能耦合在一起，新人不知道何從下手
3繁堡、不靈活：構(gòu)建時間長沈善，任何小修改都要重構(gòu)整個項目，耗時
4椭蹄、穩(wěn)定性差：一個微小的問題闻牡，都可能導(dǎo)致整個應(yīng)用掛掉
5、擴展性不夠：無法滿足高并發(fā)下的業(yè)務(wù)需求
常見的系統(tǒng)架構(gòu)遵循的三個標準和業(yè)務(wù)驅(qū)動力：
1绳矩、提高敏捷性：及時響應(yīng)業(yè)務(wù)需求罩润，促進企業(yè)發(fā)展
2、提升用戶體驗：提升用戶體驗翼馆，減少用戶流失
3割以、降低成本：降低增加產(chǎn)品金度、客戶或業(yè)務(wù)方案的成本
基于微服務(wù)架構(gòu)的設(shè)計：
目的：有效的拆分應(yīng)用，實現(xiàn)敏捷開發(fā)和部署
關(guān)于微服務(wù)的一個形象表達：
X軸：運行多個負載均衡器之后的運行實例
Y軸：將應(yīng)用進一步分解為微服務(wù)（分庫）
Z軸：大數(shù)據(jù)量時严沥，將服務(wù)分區(qū)（分表）
四猜极、微服務(wù)的具體特征
官方的定義：
1、一些列的獨立的服務(wù)共同組成系統(tǒng)
2消玄、單獨部署跟伏，跑在自己的進程中
3、每個服務(wù)為獨立的業(yè)務(wù)開發(fā)
4莱找、分布式管理
5酬姆、非常強調(diào)隔離性
大概的標準：
1、分布式服務(wù)組成的系統(tǒng)
2奥溺、按照業(yè)務(wù)辞色，而不是技術(shù)來劃分組織
3、做有生命的產(chǎn)品而不是項目
4浮定、強服務(wù)個體和弱通信（ Smart endpoints and dumb pipes ）
5相满、自動化運維（ 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ī)則和驗證等等焦人。 它還有一個重要功能是消息隊列和事件驅(qū)動的消息傳遞，比如把JMS服務(wù)轉(zhuǎn)化成SOAP協(xié)議重父。 各服務(wù)間可能有
復(fù)雜的依賴關(guān)系花椭。
微服務(wù)通常由重寫一個模塊開始。要把整個巨石型的應(yīng)用重寫是有很大的風險的房午，也不一定必要个从。我們向微服務(wù)遷移的時候通常從耦合度最低的模塊或?qū)U展性要求最高的模塊開始，
把它們一個一個剝離出來用敏捷地重寫，可以嘗試最新的技術(shù)和語言和框架嗦锐，然 后單獨布署嫌松。 它通常不依賴其他服務(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ù)通常有它自己獨立的data store冈爹。 我們在拆分數(shù)據(jù)庫時可以適當?shù)淖鲂?/p>
去范式化(denormalization)，讓它不需要依賴其他服務(wù)的數(shù)據(jù)欧引。
微服務(wù)通常是直接面對用戶的频伤，每個微服務(wù)通常直接為用戶提供某個功能。 類似的功能可能針對手機有一個服務(wù)芝此，針對機頂盒是另外一個服務(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ù)挖出來剥汤。然后針對性的，快速確認業(yè)務(wù)需求排惨，快速開發(fā)迭代吭敢。
六、怎么具體實踐微服務(wù)
要實際的應(yīng)用微服務(wù)暮芭，需要解決一下四點問題：
1鹿驼、客戶端如何訪問這些服務(wù)
2、每個服務(wù)之間如何通信
3辕宏、如此多的服務(wù)畜晰，如何實現(xiàn)？
4瑞筐、服務(wù)掛了凄鼻，如何解決？（備份方案面哼，應(yīng)急處理機制）
1野宜、客戶端如何訪問這些服務(wù)
原來的Monolithic方式開發(fā)，所有的服務(wù)都是本地的魔策，UI可以直接調(diào)用匈子，現(xiàn)在按功能拆分成獨立的服務(wù)，跑在獨立的一般都在獨立的虛擬機上的 Java進程了闯袒』⒍兀客戶端UI如何訪問他的？
后臺有N個服務(wù)政敢，前臺就需要記住管理N個服務(wù)其徙，一個服務(wù)下線/更新/升級，前臺就要重新部署喷户，這明顯不服務(wù)我們 拆分的理念唾那，特別當前臺是移動應(yīng)用的時候，通常業(yè)務(wù)變化的節(jié)奏更快褪尝。
另外闹获，N個小服務(wù)的調(diào)用也是一個不小的網(wǎng)絡(luò)開銷。還有一般微服務(wù)在系統(tǒng)內(nèi)部河哑，通常是無 狀態(tài)的避诽，用戶登錄信息和權(quán)限管理最好有一個統(tǒng)一的地方維護管理（OAuth）。
所以璃谨，一般在后臺N個服務(wù)和UI之間一般會一個代理或者叫API Gateway沙庐，他的作用包括：
① 提供統(tǒng)一服務(wù)入口鲤妥，讓微服務(wù)對前臺透明
② 聚合后臺的服務(wù)，節(jié)省流量拱雏，提升性能
③ 提供安全棉安，過濾，流控等API管理功能
其實這個API Gateway可以有很多廣義的實現(xiàn)辦法铸抑，可以是一個軟硬一體的盒子垂券，也可以是一個簡單的MVC框架，甚至是一個Node.js的服務(wù)端羡滑。他們最重要的作 用是為前臺（通常是
移動應(yīng)用）提供后臺服務(wù)的聚合菇爪，提供一個統(tǒng)一的服務(wù)出口，解除他們之間的耦合柒昏，不過API Gateway也有可能成為單點故障點或者性能的瓶頸凳宙。
用過Taobao Open Platform（淘寶開放平臺）的就能很容易的體會，TAO就是這個API Gateway职祷。
2氏涩、每個服務(wù)之間如何通信
所有的微服務(wù)都是獨立的Java進程跑在獨立的虛擬機上，所以服務(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)用比較簡單泥耀，一致性強饺汹，但是容易出調(diào)用問題，性能體驗上也會差些痰催，特別是調(diào)用層次多的時候兜辞。RESTful和RPC的比較也是一個很有意 思的話題。
一般REST基于HTTP夸溶，更容易實現(xiàn)逸吵，更容易被接受，服務(wù)端實現(xiàn)技術(shù)也更靈活些缝裁，各個語言都能支持扫皱，同時能跨客戶端，對客戶端沒有特殊的要求捷绑，只要封裝了HTTP的
SDK就能調(diào)用韩脑，所以相對使用的廣一些。RPC也有自己的優(yōu)點胎食，傳輸協(xié)議更高效扰才，安全更可控允懂，特別在一個公司內(nèi)部厕怜，如果有統(tǒng)一個 的開發(fā)規(guī)范和統(tǒng)一的服務(wù)框架時，
他的開發(fā)效率優(yōu)勢更明顯些。就看各自的技術(shù)積累實際條件粥航，自己的選擇了琅捏。
而異步消息的方式在分布式系統(tǒng)中有特別廣泛的應(yīng)用，他既能減低調(diào)用服務(wù)之間的耦合递雀，又能成為調(diào)用之間的緩沖柄延，確保消息積壓不會沖垮被調(diào)用方，同時能保證調(diào)用方的
服務(wù)體驗缀程，繼續(xù)干自己該干的活搜吧，不至于被后臺性能拖慢。不過需要付出的代價是一致性的減弱杨凑，需要接受數(shù)據(jù)最終一致性滤奈；還有就是后臺服務(wù)一般要 實現(xiàn)冪等性，因為消息
發(fā)送出于性能的考慮一般會有重復(fù)（保證消息的被收到且僅收到一次對性能是很大的考驗）撩满；最后就是必須引入一個獨立的broker蜒程，如果公司內(nèi)部沒有技術(shù)積累，
對broker分布式管理也是一個很大的挑戰(zhàn)伺帘。
3昭躺、如此多的服務(wù)，如何實現(xiàn)伪嫁？
在微服務(wù)架構(gòu)中领炫，一般每一個服務(wù)都是有多個拷貝，來做負載均衡张咳。一個服務(wù)隨時可能下線驹吮，也可能應(yīng)對臨時訪問壓力增加新的服務(wù)節(jié)點。服務(wù)之間如何相互感知晶伦？服務(wù)如何管理碟狞？
這就是服務(wù)發(fā)現(xiàn)的問題了。一般有兩類做法婚陪，也各有優(yōu)缺點族沃。基本都是通過zookeeper等類似技術(shù)做服務(wù)注冊信息的分布式管理泌参。當服務(wù)上線時脆淹，服務(wù)提供者將自己的服務(wù)信息
注冊到ZK（或類似框架），并通過心跳維持長鏈接沽一，實時更新鏈接信息盖溺。服務(wù)調(diào)用者通過ZK尋址，根據(jù)可定制算法铣缠， 找到一個服務(wù)烘嘱，還可以將服務(wù)信息緩存在本地以提高性能昆禽。
當服務(wù)下線時，ZK會發(fā)通知給服務(wù)客戶端蝇庭。
客戶端做：優(yōu)點是架構(gòu)簡單醉鳖，擴展靈活，只對服務(wù)注冊器依賴哮内。缺點是客戶端要維護所有調(diào)用服務(wù)的地址盗棵，有技術(shù)難度，一般大公司都有成熟的內(nèi)部框架支持北发，比如Dubbo纹因。
服務(wù)端做：優(yōu)點是簡單，所有服務(wù)對于前臺調(diào)用方透明琳拨，一般在小公司在云服務(wù)上部署的應(yīng)用采用的比較多辐怕。
4、服務(wù)掛了从绘，如何解決
前面提到寄疏，Monolithic方式開發(fā)一個很大的風險是，把所有雞蛋放在一個籃子里僵井，一榮俱榮陕截，一損俱損。而分布式最大的特性就是網(wǎng)絡(luò)是不可靠的批什。通過微服務(wù)拆分能降低這個風險农曲，
不過如果沒有特別的保障，結(jié)局肯定是噩夢驻债。所以當我們的系統(tǒng)是由一系列的服務(wù)調(diào)用鏈組成的時候乳规，我們必須確保任一環(huán)節(jié)出問題都不至于影響整體鏈路。相應(yīng)的手段有很多：
①重試機制
②限流
③熔斷機制
④負載均衡
⑤降級（本地緩存）
這些方法基本都很明確通用合呐，比如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ù)實現(xiàn)應(yīng)用程序所需的功能咙咽。它可以是一個簡單的Web頁面，將檢索到的數(shù)據(jù)進行處理展示淤年。它也可以是一個更高層次的組合微服務(wù)钧敞，對檢索到的數(shù)據(jù)增加業(yè)務(wù)邏輯后進一步
發(fā)布成一個新的微服務(wù)蜡豹，這符合DRY原則。另外犁享，每個服務(wù)都有自己的緩存和數(shù)據(jù)庫。如果聚合器是一個組合服務(wù)豹休，那么它也有自己的緩存和數(shù)據(jù)庫炊昆。聚合器可以沿X軸和Z軸獨立擴展。
2威根、代理微服務(wù)設(shè)計模式
這是聚合模式的一個變種凤巨，如下圖所示：
在這種情況下，客戶端并不聚合數(shù)據(jù)洛搀，但會根據(jù)業(yè)務(wù)需求的差別調(diào)用不同的微服務(wù)敢茁。代理可以僅僅委派請求，也可以進行數(shù)據(jù)轉(zhuǎn)換工作留美。
3彰檬、鏈式微服務(wù)設(shè)計模式
這種模式在接收到請求后會產(chǎn)生一個經(jīng)過合并的響應(yīng)，如下圖所示：
在這種情況下谎砾，服務(wù)A接收到請求后會與服務(wù)B進行通信逢倍，類似地，服務(wù)B會同服務(wù)C進行通信景图。所有服務(wù)都使用同步消息傳遞较雕。在整個鏈式調(diào)用完成之前，客戶端會一直阻塞挚币。
因此亮蒋，服務(wù)調(diào)用鏈不宜過長，以免客戶端長時間等待妆毕。
4慎玖、分支微服務(wù)設(shè)計模式
這種模式是聚合器模式的擴展，允許同時調(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ù)之間存在強耦合關(guān)系時才可以。對于基于微服務(wù)的新建應(yīng)用程序而言拱她，這是一種反模式二驰。
6、異步消息傳遞微服務(wù)設(shè)計模式
雖然REST設(shè)計模式非常流行秉沼，但它是同步的桶雀，會造成阻塞。因此部分基于微服務(wù)的架構(gòu)可能會選擇使用消息隊列代替REST請求/響應(yīng)唬复，如下圖所示：
八矗积、優(yōu)點和缺點
1、微服務(wù)的優(yōu)點：
關(guān)鍵點：復(fù)雜度可控敞咧，獨立按需擴展棘捣，技術(shù)選型靈活，容錯休建，可用性高
①它解決了復(fù)雜性的問題乍恐。它會將一種怪異的整體應(yīng)用程序分解成一組服務(wù)。雖然功能總量 不變测砂，但應(yīng)用程序已分解為可管理的塊或服務(wù)禁熏。每個服務(wù)都以RPC或消息驅(qū)動的API的
形式定義了一個明確的邊界；Microservice架構(gòu)模式實現(xiàn)了一個模塊化水平邑彪。
②這種架構(gòu)使每個服務(wù)都能夠由專注于該服務(wù)的團隊獨立開發(fā)瞧毙。開發(fā)人員可以自由選擇任何有用的技術(shù)，只要該服務(wù)符合API合同寄症。當然宙彪，大多數(shù)組織都希望避免完全無政府狀態(tài)并
限制技術(shù)選擇。然而有巧，這種自由意味著開發(fā)人員不再有義務(wù)使用在新項目開始時存在的可能過時的技術(shù)释漆。在編寫新服務(wù)時，他們可以選擇使用當前的技術(shù)篮迎。此外男图，由于服務(wù)相對較小，
因此使用當前技術(shù)重寫舊服務(wù)變得可行甜橱。
③Microservice架構(gòu)模式使每個微服務(wù)都能獨立部署逊笆。開發(fā)人員不需要協(xié)調(diào)部署本地服務(wù)的變更。這些變化可以在測試后盡快部署岂傲。例如难裆，UI團隊可以執(zhí)行A | B測試，并快速迭代
UI更改。Microservice架構(gòu)模式使連續(xù)部署成為可能乃戈。
④Microservice架構(gòu)模式使每個服務(wù)都可以獨立調(diào)整褂痰。您可以僅部署滿足其容量和可用性限制的每個服務(wù)的實例數(shù)。此外症虑，您可以使用最符合服務(wù)資源要求的硬件缩歪。
2、微服務(wù)的缺點
關(guān)鍵點（挑戰(zhàn)）：多服務(wù)運維難度谍憔，系統(tǒng)部署依賴匪蝙，服務(wù)間通信成本，數(shù)據(jù)一致性韵卤，系統(tǒng)集成測試厉碟，重復(fù)工作兵扬，性能監(jiān)控等
①一個缺點是名稱本身而账。術(shù)語microservice過度強調(diào)服務(wù)規(guī)模酌儒。但重要的是要記住刻诊，這是一種手段驻襟，而不是主要目標憨募。微服務(wù)的目標是充分分解應(yīng)用程序薯鳍，以便于敏捷應(yīng)用程序開發(fā)和部署涕烧。
②微服務(wù)器的另一個主要缺點是分布式系統(tǒng)而產(chǎn)生的復(fù)雜性月而。開發(fā)人員需要選擇和實現(xiàn)基于消息傳遞或RPC的進程間通信機制。此外议纯，他們還必須編寫代碼來處理部分故障父款，
因為請求的目的地可能很慢或不可用。
③微服務(wù)器的另一個挑戰(zhàn)是分區(qū)數(shù)據(jù)庫架構(gòu)瞻凤。更新多個業(yè)務(wù)實體的業(yè)務(wù)交易是相當普遍的憨攒。但是，在基于微服務(wù)器的應(yīng)用程序中阀参，您需要更新不同服務(wù)所擁有的多個數(shù)據(jù)庫肝集。使用分布式事務(wù)
通常不是一個選擇，而不僅僅是因為CAP定理蛛壳。許多今天高度可擴展的NoSQL數(shù)據(jù)庫都不支持它們杏瞻。你最終不得不使用最終的一致性方法，這對開發(fā)人員來說更具挑戰(zhàn)性衙荐。
④測試微服務(wù)應(yīng)用程序也更復(fù)雜捞挥。服務(wù)類似的測試類將需要啟動該服務(wù)及其所依賴的任何服務(wù)（或至少為這些服務(wù)配置存根）。再次忧吟，重要的是不要低估這樣做的復(fù)雜性树肃。
⑤Microservice架構(gòu)模式的另一個主要挑戰(zhàn)是實現(xiàn)跨越多個服務(wù)的更改。例如瀑罗，我們假設(shè)您正在實施一個需要更改服務(wù)A胸嘴，B和C的故事雏掠，其中A取決于B和B取決于C.在單片應(yīng)用程序中，
您可以簡單地更改相應(yīng)的模塊劣像，整合更改乡话，并一次性部署。相比之下耳奕，在Microservice架構(gòu)模式中绑青，您需要仔細規(guī)劃和協(xié)調(diào)對每個服務(wù)的更改。例如屋群，您需要更新服務(wù)C闸婴，然后更新服務(wù)B，
然后再維修A.幸運的是芍躏，大多數(shù)更改通常僅影響一個服務(wù)邪乍，而需要協(xié)調(diào)的多服務(wù)變更相對較少。
⑥部署基于微服務(wù)的應(yīng)用程序也更復(fù)雜对竣。單一應(yīng)用程序簡單地部署在傳統(tǒng)負載平衡器后面的一組相同的服務(wù)器上庇楞。每個應(yīng)用程序?qū)嵗寂渲糜谢A(chǔ)架構(gòu)服務(wù)（如數(shù)據(jù)庫和消息代理）
的位置（主機和端口）。相比之下否纬，微服務(wù)應(yīng)用通常由大量服務(wù)組成吕晌。例如，每個服務(wù)將有多個運行時實例临燃。更多的移動部件需要進行配置睛驳，部署，擴展和監(jiān)控膜廊。此外乏沸，您還需要實現(xiàn)服務(wù)
發(fā)現(xiàn)機制，使服務(wù)能夠發(fā)現(xiàn)需要與之通信的任何其他服務(wù)的位置（主機和端口）溃论。傳統(tǒng)的基于故障單和手動操作的方法無法擴展到這種復(fù)雜程度屎蜓。因此，成功部署微服務(wù)應(yīng)用程序需要
開發(fā)人員更好地控制部署方法钥勋，并實現(xiàn)高水平的自動化炬转。
九、思考：意識的轉(zhuǎn)變
微服務(wù)對我們的思考算灸，更多的是思維上的轉(zhuǎn)變扼劈。對于微服務(wù)架構(gòu)：技術(shù)上不是問題，意識比工具重要菲驴。
關(guān)于微服務(wù)的幾點設(shè)計出發(fā)點：
1荐吵、應(yīng)用程序的核心是業(yè)務(wù)邏輯，按照業(yè)務(wù)或客戶需求組織資源（這是最難的）
2、做有生命的產(chǎn)品先煎，而不是項目
3贼涩、頭狼戰(zhàn)隊，全検硇化
4遥倦、后臺服務(wù)貫徹Single Responsibility Principle（單一職責原則）
5、VM->Docker （to PE）
6占锯、DevOps (to PE)
同時袒哥，對于開發(fā)同學，有這么多的中間件和強大的PE支持固然是好事消略，我們也需要深入去了解這些中間件背后的原理堡称，知其然知其所以然，在有限的技術(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
Has anything you've done made your life better?
