1. 程式人生 > >微服務架構的優點和挑戰

微服務架構的優點和挑戰

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