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