微服務架構有如下好處：
1：使大型的複雜應用程序可以持續交付和持續部署
持續交付和持續部署是DevOps的一部分，DevOps是一套快速、頻繁、可靠的軟件交付實踐。高效的DevOps組織通常將軟件部署到生產環境時面臨更少的問題和故障。DevOps工具有Docker、Kubernets、Jenkins、Git等。
2：每個服務相對較小並容易維護
微服務架構相比單體應用要小的多，開發者理解服務中的邏輯代碼更容易。代碼庫小，打包，啓動服務速度也快。
3：服務可以獨立部署
每個服務都可以獨立於其他服務進行部署
4：服務可以獨立擴展
服務可以獨立擴展，不論是採用X軸擴展的實例克隆，還是Z軸的流量分區方式。此外每個服務都可以部署到適合它們需求的硬件之上
5：微服務架構可以實現團隊的自治
可以根據服務來把開發團隊拆分。每個團隊都有自己負責的微服務，而不用關心不屬於他們負責的服務。
6：更容易實驗和採納新的技術
最後，微服務可以消除對某個技術棧的長期依賴。因爲服務更小，使用更換的編程語言和技術來重寫一項服務變得有可能，這也意味着，對一項新技術嘗試失敗後，可以直接丟棄這部分工作而不至於給整個應用帶來失敗的風險。
7：更好的容錯性
微服務架構也可以實現更換的故障隔離。例如，某個服務引發的致命錯誤，不會影響其他服務。其他服務仍然正常運行。
微服務架構的主要弊端和問題如下
1：服務拆分和定義是一項挑戰
採用微服務架構首當其衝的問題，就是根本沒有一個具體的、良好定義的算法可以完成服務的拆分工作。與軟件開發一樣，服務的拆分和定義更像一門藝術。更糟糕的是，如果對系統的服務拆分出現了偏差，很有可能會構建出一個分佈式的單體應用；一個包含了一大堆互相之間緊耦合的服務，卻又必須部署在一起的所謂分佈式系統。這將會把單體架構和微服務架構兩者的弊端集於一身。
2：分佈式系統帶來的各種複雜性、使開發、測試和部署變得更困難
使用微服務架構的另一個問題是開發人員必須處理創建分佈式系統的額外複雜性。服務必須是進程間通信。這比簡單的方法調用要複雜的多。
3：當部署跨越多個服務的功能時需要謹慎地協調更多的開發團隊
使用微服務架構的另外一項挑戰在於當部署跨越多個服務的功能時需要謹慎地協調更多開發團隊。必須制定一個發佈計劃，把服務按照依賴關係進行排序。這跟單體架構下部署多個組件的方式截然不同。
4：開發者需要思考到底應該在應用的什麼階段使用微服務架構
使用微服務架構的另一個問題是決定在應用程序生命週期的哪個階段開始使用這種架構。
5：跨服務數據的問題
在單體應用中，所有的數據都在一個數據庫中，而在微服務架構中，每個服務都有自己的數據庫，想要獲取，操作其他服務的數據，只能通過該服務提供API進行調用，這樣就帶來一個問題，進程通信的問題，如果涉及到事務，那麼還需要使用Saga來管理事務，增加了開發的難度
總結：
1：單體架構模式將應用程序構建爲單個可部署單元
2：微服務架構模式系統分解爲一組可獨立部署的服務，每個服務都有自己的數據庫
3：單體架構是簡單應用的不錯選擇，微服務架構通常是大型複雜應用的更好的選擇
4：微服務架構是小型自治團隊能夠並行工作，從而加快開發速度
5：微服務架構不是銀彈：它存在包括複雜性在內的諸多弊端
6：我們需要的不僅僅是通過微服務架構來加速軟件交付。成功的軟件開發還需要DevOps和小而自治的團隊