微服務(wù)確實很受歡迎，但是對于微服務(wù)的誤解也是事實，本文對這些誤解一一來介紹下：
　　一、微服務(wù)不夠“微”？
　　盡管微服務(wù)定義的很明確，但是開發(fā)者社區(qū)對它的解釋卻頗有爭議，主要的一些問題如下：
　　1.它是否是單體架構(gòu)的代表？
　　2.它是否是單體服務(wù)的代表？
　　3.它是否是邏輯功能的組合？
　　下面讓我們以銀行應用為例來討論一下：三層架構(gòu)解決了技術(shù)組件之間的緊耦合問題，允許它們各自獨立改變而不相互依賴。例如： Web端的改變不會影響到后端服務(wù)。 但是三層架構(gòu)沒有把基于組件分組的功能和特性考慮進去，為此我想出了一個“功能型”架構(gòu)的名稱，以表明架構(gòu)需要通過產(chǎn)品的特征來劃分。這對于現(xiàn)代應用的性能和吞吐量是至關(guān)重要的，我會在文章中對細節(jié)做進一步的解釋。
　　
　　二、 微服務(wù)可伸縮性
　　微服務(wù)是一種架構(gòu)風格，它允許你向規(guī)模化的宏偉系統(tǒng)進攻，這是怎么做到的呢？傳統(tǒng)的三層架構(gòu)服務(wù)能伸縮可被擴展，那微服務(wù)有啥特別之處呢？例如：在線旅行預定，購買請求和預定請求比例是100：1
　　1.這意味著什么呢， 101個請求中，購買請求能達到100個，而預定請求只有1個；
　　2.這就敲響了警鐘！預定需要的資源遠遠小于購買所占用的資源，為何不將整個系統(tǒng)按照期望比例縮放成100：1呢？
　　
　　三、 微服務(wù)幫助維護和運行
　　“滾動式重啟”， “熱部署”， “輪詢式部署， ”是不是聽起來很熟悉？用最短的停機時間來維護應用系統(tǒng)，是現(xiàn)代應用系統(tǒng)的一個狀態(tài)優(yōu)先級典型表現(xiàn)。 讓我們舉個例子，改變應用將會貫穿整個三層架構(gòu)，包括數(shù)據(jù)庫應用程序的變化。如果數(shù)據(jù)的語義被修改了，任何上述技術(shù)是注定要失敗（（例如： ORM（對象映射關(guān)系）一旦看到了對象的變化，就需要重新啟動所有的節(jié)點）。關(guān)于微服務(wù)：功能型-層架構(gòu)給高可用性和維護帶來了一個新的局面。即使銀行報表微服務(wù)奔潰了也不會影響銀行系統(tǒng)其他的功能。你將會為90%的消費者不用銀行報表功能感到慶幸。
　　四、 微服務(wù)需要進一步發(fā)掘
　　好吧，任何關(guān)于自動伸縮的系統(tǒng)都需要被挖掘。
　　1.在微服務(wù)中有10個節(jié)點是購物的，兩個節(jié)點是預定的；
　　2.由于假日季節(jié)，流入流量比較高；
　　3.你期望通過人工分拆購物實例得到什么？
　　4.假設(shè)分拆出了多個實例，那負載平衡器又是怎么實現(xiàn)負責均衡的呢？
　　傳統(tǒng)的負載均衡器在靜態(tài)環(huán)境中能夠運行良好，但是當動態(tài)增加節(jié)點或執(zhí)行腳本添加新實例的就很糟糕了。如果微服務(wù)能夠?qū)崿F(xiàn)縮放，微服務(wù)項目就需要被挖掘、注冊、添加實現(xiàn)負載均衡；對，大部分的軟件問題，通過引用間接層來解決。每個微服務(wù)在關(guān)閉或啟動時都需要自我注冊。這就需要一個注冊管理員-負載均衡器，對微服務(wù)的加載很敏感。如何檢查呢，
　　Netflix解決了這個問題， Netflix在開源Eureka AWS上實現(xiàn)了負載均衡。
　　五、 微服務(wù)是否支持多元化編程語言？
　　顧名思義微服務(wù)是以協(xié)議驅(qū)動的服務(wù)，這些服務(wù)是基于HTTP/REST（ XML/ JSON數(shù)據(jù)傳輸）的。微服務(wù)與輕量級協(xié)議之間的清晰的定義邊界，有助于建立一個多元化的編程團隊，因為他們的焦點是功能而不在于選擇語言。
　　六、 微服務(wù)和容器是天作之合？
　　虛擬機的笨重和現(xiàn)代應?程序的性質(zhì)，將他們分拆和拆卸為微服務(wù)，使微服務(wù)成為容器的理想搭配。這是真正意義上的DevOps，打的包不僅僅是微服務(wù)的容器也是整體的一個執(zhí)行環(huán)境。缺點是，應用團隊將成為基礎(chǔ)設(shè)施團隊，需要對集裝箱有個很好的理解。
　　七、 微服務(wù)添加額外的復雜性？
　　1.Jenkins簡單通道把兩個應用部署到2個Tomcats里，以此類推，將膨脹出無數(shù)個微服務(wù)；
　　2.隨著部署的數(shù)量增加，部署的時間也跟著顯著上升；
　　3.需要有一個良好的容器管理，部署和分發(fā)工具和技術(shù)；
　　4.每個微服務(wù)將擁有更多的日志文件，如果沒有stash、 splunk這種合適的工具，對接調(diào)試事務(wù)將成為一場噩夢；
　　5.如果每個Tomcat有10個連接，你會發(fā)現(xiàn)數(shù)百個來自不同微服務(wù)數(shù)據(jù)庫連接，因為不能共享數(shù)據(jù)庫連接（沒有連接數(shù)據(jù)庫的微服務(wù)）；
　　總結(jié)
　　所有的事情都是有代價的，微服務(wù)也是一樣，并不是所有的應用都有同樣的架構(gòu)，也不是所有應用對高可用性、可擴展性、可維修性都有著同樣的要求。

普通下載普通下載

相關(guān)電子資料下載

• Spring Cloud ：打造可擴展的微服務(wù)網(wǎng)關(guān) 60
• SpringCloud微服務(wù)架構(gòu)：實現(xiàn)分布式系統(tǒng)的無縫協(xié)作 62
• 類隔離的使用場景 106
• 微服務(wù)架構(gòu)組件分析,看這篇就夠了 285
• 邊緣計算微服務(wù)操作系統(tǒng)的設(shè)計與實現(xiàn) 193
• 【Spring Cloud 】基于微服務(wù)架構(gòu)的智慧工地監(jiān)管平臺源碼帶APP 150
• 聊聊這個有趣的話題：分布式單體 106
• Java版智慧工地云平臺源碼（微服務(wù)+Java+Springboot+Vue+MySQL），支持私有化部署， 369
• Service Mesh：探索分布式系統(tǒng)的幻覺與未來 141
• 微服務(wù)的4種部署策略，你都清楚嗎？ 298