一 微服務的優點1 易於開發和維護：一個微服務只會關注一個特定的業務功能，所以它業務清晰、程式碼量少。開發和維護單個微服務相當簡單。而整個應用是若干個微服務構建而成的，所以整個應用也被維持在一個可控狀態。2單個微服務啟動較快：單個微服務程式碼量較少，所以啟動會比較快。3 區域性修改容易部署：單個應用只要有修改，就得重新部署整個應用，微服務解決了這樣的問題。一般來說，對某個微服務進行修改，只需要重新部署這個服務即可。4 技術棧不受限：在微服務架構中，可以結合專案業務及團隊的特點，合理選擇技術棧。例如某些服務可以使用關係型資料庫Mysql；某些微服務有圖形計算需求，可以使用Neo4j；甚至可根據需求，部分微服務使用Java開發，部分微服務使用Node.js開發。5 按需收縮：可根據需求，實現細粒度的擴充套件。例如，系統中的某個微服務遇到了瓶頸，可以結合這個微服務的業務特點，增加記憶體、升級CPU或者增加節點。綜上，單體應用架構的缺點，恰恰是微服務的優點，而這些優點使得微服務看起來簡直非常完美。然而完美的東西並不存在，就像銀彈不存在一樣。微服務存在一些挑戰。二 微服務架構面臨的挑戰1 運維要求較高：更多的服務意味著更多的運維投入。在單體架構中，只需要保證一個應用的正常執行。而在微服務中，需要保證幾十甚至幾百個服務正常執行與協作，這給運維帶來了很大的挑戰。2 分散式固有的複雜性：使用微服務構建的是分佈是系統。對於一個分散式系統，系統容錯、網路延遲、分散式事務等都會帶來巨大的挑戰。3 介面調整成本高：微服務之間通過介面進行通訊。如果修改某一個微服務API，可能所有使用該介面的微服務都需要調整。4 重複勞動：很多服務可能都會使用相同的功能，而這個功能並沒有達到分解為一個微服務的程度，這個時候，可能各個服務都會開放這一功能，從而導致程式碼重複。儘管可以使用共享庫來解決這個問題（例如可以將這個功能封裝成公共元件，需要該功能的微服務引用該元件），但共享庫在多語言環境下就不一定行得通。