微服務架構的優勢和挑戰

一 微服務的優勢

1 易於開發和維護：一個微服務只會關注一個特定的業務功能，因此它業務清晰、代碼量少。開發和維護單個微服務至關簡單。而整個應用是若干個微服務構建而成的，因此整個應用也被維持在一個可控狀態。

2單個微服務啓動較快：單個微服務代碼量較少，因此啓動會比較快。

3 局部修改容易部署：單個應用只要有修改，就得從新部署整個應用，微服務解決了這樣的問題。通常來講，對某個微服務進行修改，只須要從新部署這個服務便可。

4 技術棧不受限：在微服務架構中，能夠結合項目業務及團隊的特色，合理選擇技術棧。例如某些服務可使用關係型數據庫Mysql；某些微服務有圖形計算需求，可使用Neo4j；甚至可根據需求，部分微服務使用Java開發，部分微服務使用Node.js開發。

5 按需收縮：可根據需求，實現細粒度的擴展。例如，系統中的某個微服務遇到了瓶頸，能夠結合這個微服務的業務特色，增長內存、升級CPU或者增長節點。

綜上，單體應用架構的缺點，偏偏是微服務的優勢，而這些優勢使得微服務看起來簡直很是完美。然而完美的東西並不存在，就像銀彈不存在同樣。微服務存在一些挑戰。

二 微服務架構面臨的挑戰

1 運維要求較高：更多的服務意味着更多的運維投入。在單體架構中，只須要保證一個應用的正常運行。而在微服務中，須要保證幾十甚至幾百個服務正常運行與協做，這給運維帶來了很大的挑戰。

2 分佈式固有的複雜性：使用微服務構建的是分佈是系統。對於一個分佈式系統，系統容錯、網絡延遲、分佈式事務等都會帶來巨大的挑戰。

3 接口調整成本高：微服務之間經過接口進行通訊。若是修改某一個微服務API，可能全部使用該接口的微服務都須要調整。

4 重複勞動：不少服務可能都會使用相同的功能，而這個功能並無達到分解爲一個微服務的程度，這個時候，可能各個服務都會開放這一功能，從而致使代碼重複。儘管可使用共享庫來解決這個問題（例如能夠將這個功能封裝成公共組件，須要該功能的微服務引用該組件），但共享庫在多語言環境下就不必定行得通。