參考：here，here。

優點：

1. 易於開發和維護：一個服務只關注一個特定的業務功能，程式碼量少。
2. 單個服務啟動快(因為程式碼量少)
3. 區域性修改易部署：對單體架構而言，只要有修改，就得重新部署整個應用，微服務解決了整個問題，對某個微服務進行修改，只需要重新部署這個服務即可。
4. 技術棧不受限：在微服務架構中，可結合業務和團隊特點合理選用技術棧。例如部分服務可以使用關係型資料庫MySQL，部分服務可以使用非關係型資料庫Redis，甚至可根據需求，部分服務使用Java開發，部分微服務使用Node.js開發。
5. 按需收縮：可以根據需求，實現細粒度的擴充套件。(例如系統中的某某個微服務遇到了瓶頸，可以結合微服務的特點，增加記憶體、升級CPU或增加節點。)

缺點：

1. 運維要求高：更多服務意味著更多的運維投入，在單體架構中，只需要保證一個應用的執行即可，在微服務架構中，需要保證幾十甚至幾百個伺服器的正常執行和協作。
2. 分戶式固有的複雜性：使用微服務架構的是分散式系統。對於一個分散式系統，系統容錯，網路延遲都會帶來巨大挑戰。
3. 介面成本高：微服務之間通過介面進行通訊。

應用場景：

　　淘寶+支付寶+微信+微博(目前蘋果或者安卓系統手機上的應用，基本上都是微服務架構，其業務模式決定了架構不可能採用一種單體架構取解決所有問題。)

　　電商類、微博微信社交類、支付類、直播類、遊戲類等業務都適合，一個架構的拆分，本質上反映的是一個業務的拆分。

【Over】