微服務確實很受歡迎，但是對於微服務的誤解也是事實，本文對這些誤解一一來介紹下：
一、微服務不夠「微」?
儘管微服務定義的很明確，但是開發者社群對它的解釋卻頗有爭議,主要的一些問題如下：
1.它是否是單體架構的代表？
2.它是否是單體服務的代表？
3.它是否是邏輯功能的組合？
下面讓我們以銀行應用為例來討論一下：三層架構解決了技術元件之間的緊耦合問題，允許它們各自獨立改變而不相互依賴。例如： web端的改變不會影響到後端服務。 但是三層架構沒有把基於元件分組的功能和特性考慮進去,為此我想出了乙個「功能型」架構的名稱，以表明架構需要通過產品的特徵來劃分。這對於現代應用的效能和吞吐量是至關重要的，我會在文章中對細節做進一步的解釋。
二、 微服務可伸縮性
1.這意味著什麼呢， 101個請求中，購買請求能達到100個，而預定請求只有1個；
2.這就敲響了警鐘！預定需要的資源遠遠小於購買所占用的資源，為何不將整個系統按照期望比例縮放成100：1呢？
三、 微服務幫助維護和執行
「滾動式重啟」， 「熱部署」， 「輪詢式部署， 」是不是聽起來很熟悉？用最短的停機時間來維護應用系統，是現代應用系統的乙個狀態優先順序典型表現。 讓我們舉個例子，改變應用將會貫穿整個三層架構，包括資料庫應用程式的變化。如果資料的語義被修改了，任何上述技術是注定要失敗（（例如： orm（物件對映關係）一旦看到了物件的變化，就需要重新啟動所有的節點）。關於微服務：功能型-層架構給高可用性和維護帶來了乙個新的局面。即使銀行報表微服務奔潰了也不會影響銀行系統其他的功能。你將會為90%的消費者不用銀行報表功能感到慶幸。
四、 微服務需要進一步發掘
好吧，任何關於自動伸縮的系統都需要被挖掘。
1.在微服務中有10個節點是購物的，兩個節點是預定的；
2.由於假日季節，流入流量比較高；
3.你期望通過人工分拆購物例項得到什麼？
4.假設分拆出了多個例項，那負載平衡器又是怎麼實現負責均衡的呢？
傳統的負載均衡器在靜態環境中能夠執行良好，但是當動態增加節點或執行指令碼新增新例項的就很糟糕了。如果微服務能夠實現縮放，微服務專案就需要被挖掘、註冊、新增實現負載均衡；對，大部分的軟體問題，通過引用間接層來解決。每個微服務在關閉或啟動時都需要自我註冊。這就需要乙個註冊管理員-負載均衡器，對微服務的載入很敏感。如何檢查呢，
netflix解決了這個問題， netflix在開源eureka aws上實現了負載均衡。
五、 微服務是否支援多元化程式語言？
顧名思義微服務是以協議驅動的服務，這些服務是基於http/rest（ xml/ json資料傳輸）的。微服務與輕量級協議之間的清晰的定義邊界，有助於建立乙個多元化的程式設計團隊，因為他們的焦點是功能而不在於選擇語言。
六、 微服務和容器是天作之合？
虛擬機器的笨重和現代應⽤程式的性質，將他們分拆和拆卸為微服務，使微服務成為容器的理想搭配。這是真正意義上的devops，打的包不僅僅是微服務的容器也是整體的乙個執行環境。缺點是，應用團隊將成為基礎設施團隊，需要對貨櫃有個很好的理解。
七、 微服務新增額外的複雜性？
1.jenkins簡單通道把兩個應用部署到2個tomcats裡，以此類推，將膨脹出無數個微服務；
2.隨著部署的數量增加，部署的時間也跟著顯著上公升；
3.需要有乙個良好的容器管理，部署和分發工具和技術；
4.每個微服務將擁有更多的日誌檔案，如果沒有stash、 splunk這種合適的工具，對接除錯事務將成為一場噩夢；
5.如果每個tomcat有10個連線，你會發現數百個來自不同微服務資料庫連線，因為不能共享資料庫連線（沒有連線資料庫的微服務）；
總結
所有的事情都是有代價的，微服務也是一樣，並不是所有的應用都有同樣的架構，也不是所有應用對高可用性、可擴充套件性、可維修性都有著同樣的要求。
微服務與微服務架構
微服務 微服務強調的是服務的大小，它關注的是某乙個點，是具體解決某乙個問題 提供落地對應服務的乙個服務應用,狹意的看,可以看作eclipse裡面的乙個個微服務工程 或者module。例如 訂單服務 支付服務 微服務架構 馬丁.福勒 martin fowler 微服務架構介紹 微服務架構是 種架構模式...
SpringCloud 微服務與微服務對接心德
對方已經提供好乙個api文件，然後傳一堆傳輸，返回給我一些資訊。如下 我這邊建立實體類，返回值這些東西，如下 介面如下 feignclient還有以下標籤 name 指定feignclient的名稱，如果專案使用了ribbon，name屬性會作為微服務的名稱，用於服務發現 url url一般用於除錯...
恕我直言，你可能誤解了微服務
隨著雲計算和容器技術的普及，網際網路it基礎設施已經發生了很大的變革，也推動了微服務技術的大量採用和落地。現在的技術人，不談微服務已經要跟不上形勢了。但是你真的對微服務有正確的理解嗎？要向微服務轉型，有哪些問題和挑戰擺在面前？如何撥開現代各種技術棧的迷霧看清微服務的發展趨勢，選擇最適合團隊的技術方向...