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