優點：
1、服務解耦將原有的巨大的單體應用拆分為多個獨立的微服務，使得每個服務更專注于自己的業務，滿足高內聚低耦合的設計原則。比如將電商服務差費為用戶服務、賬戶服務、商品服務、購物車服務、訂單服務等。
2、獨立的開發環境將應用拆分為獨立的微服務，服務之間彼此隔離，通過輕量級的通訊機制（比如：dubbo）進行交互，使得開發時無需關注具體的開發環境，只需要協商好通訊機制即可。
3、獨立的部署環境微服務擁有獨立的開發環境，因此需要根據各自的開發環境規劃部署環境，對于訪問量大的服務可以增加服務的部署數量，訪問量小的服務適當的減少部署數量。
4、更高的擴展性基于服務的獨立性，服務之間的耦合性降低，無論從功能上，還是架構上，我們都可以進行更為靈活的擴展，而不影響其他服務。
缺點：
1、通訊機制的不標準問題微服務之間相互獨立，但是服務間的交互需要依賴規范的通訊機制，沒有規范的通訊機制作為橋梁，服務間交互將變得非常復雜。保證規范的通訊機制，是微服務的前提。
2、事務一致性問題單體應用通過數據庫事務保證一致性，拆分為微服務后，會形成分布式處理的業務，進而就會產生分布式事務一致性問題。分布式系統的事務一致性本身就是一個技術難題，目前沒有一種很簡單很完美的方案能夠應對所有場景。分布式系統的一個難點就是因為“網絡通信的不可靠”，只能通過“確認機制”、“重試機制”、“補償機制”等各方面來解決一些問題。在綜合考慮可用性、性能、實現復雜度等各方面的情況上，比較好的選擇是“異步確保最終一致性”，只是具體實現方式上有一些差異。3、服務間的依賴變得復雜需要根據業務的重要性進行系統梳理，定義出關鍵業務和非關鍵業務；梳理服務調用的主要路徑，明確強弱依賴、限流、降級規則等。服務治理就是基于以上規則進行的，否則無法進行系統運維或管理。比如非關鍵業務被關鍵業務所依賴，會導致非關鍵業務變成關鍵業務，服務鏈中就會出現“木桶效應”，即整個服務質量由最差的那個服務所決定。數據庫也需要做相應的隔離：避免非關鍵業務把數據庫拖死，進而導致全站不可用。
4、微服務運維變得復雜微服務的架構一般會包含基礎層、中間件層、應用層、接入層、安全層，同時需要有相應的團隊負責各層的運維。各層之間有比較明確的職責，共同支撐著整個系統的運行。一旦某個環節出現問題，整個系統就會像 “多米諾骨牌”一樣倒下。因此需要統一的運維平臺，實時監控服務調用鏈路，及時發現和定位問題。而建立統一的運維平臺的成本和難度是相當之大的，目前也只有幾家互聯網大公司擁有這種能力。
5、系統監控變得復雜對系統的監控依賴于系統的調用鏈路，鏈路中包含：http請求、服務間調用、消息隊列、數據庫、nosql、線程間調用等，如何將監控整個鏈路將變得非常困難，可能需要修改各中間件的請求數據包。
6、系統測試變得復雜由于服務的依賴變得復雜，在進行系統測試時，要考慮服務間強弱依賴、降級、限流等問題。在進行壓測時要考慮依賴的服務的性能。在制造測試場景時應充分考慮各服務的數據量，避免出現測試誤差。
想要了解更多政策信息可以咨詢中培課程顧問李老師18911709446（同微信）