什麼是微服務
微服務和單體應用恰恰相反，把各個模組拆分成不同的專案，每個模組都只關注一個特定的業務功能，釋出時每一個專案都是一個獨立的包，執行在獨立的程式上。微服務應該足夠小，小到即使全部重寫也不需要過多的時間。微服務化是SOA（Service-Oriented Architecture，面向服務的架構）的一種方法。微服務架構的核心目標是把複雜問題簡單化，通過服務劃分，把一個完整的系統拆分成多個高內聚、低耦合的小的子系統。使每個子系統可以獨立的執行、升級和測試。然後再通過一些整合手段將這些子系統組合在一起，對外提供完整功能的過程。
微服務設計原則
- 單一職責原則： 每個服務應該只關注特定的某一類業務。
- 服務自治原則： 每個服務具備獨立的業務能力、依賴和執行環境，與其他服務高度解耦，每個服務都應當可以獨立執行，不應該依賴其他服務。
- 輕量級通訊機制： 應該使用輕量級的、語言無關的、跨平臺的協議，如REST、MQTT等。
微服務的優點：
- 易於開發，可維護性高： 一個服務只會關注一個特定的業務模組，程式碼比較少，可維護性就高。
- 釋出風險低： 釋出單個服務不需要重新發布整個應用。
- 技術棧不受限（異構）： 微服務之間通過輕量級的通訊機制進行通訊，比如RESTful API，因此不同專案可以隨意選擇合適的技術來實現。
- 按需伸縮： 可以針對特定的服務，結合業務特點分配不同的硬體規格。
微服務的缺點：
- 運維要求高： 對於單體應用只要部署一個服務，微服務化後可能需要部署幾十幾百個服務.
- 分散式固有的複雜性： 開發人員需要考慮分散式事務、系統的容錯性等，比如服務A的某個介面依賴服務B，通過RESTful API呼叫服務B的介面但發生了錯誤，需要提供重試等機制。
- 修改介面成本增加： 修改介面本就是一件繁瑣的事，微服務化後成本更高，因為各個服務之間只通過輕量級通訊機制訪問，耦合度比較低，需要排查哪些服務的介面受到了影響，而在單體應用中通常只是方法間的依賴，如果修改了某個方法的簽名，那麼在編譯時就會報錯。
- 重複勞動： 當一個單體應用微服務化後，不同的服務之間會有重複程式碼產生，比如Gradle指令碼、Maven依賴都非常類似，使用到的某些函式每個服務都造了一遍等，如果都是用同一種語言實現的還能用共享庫解決，如果有多種語言那就難以避免重複勞動了。
- 資料一致性
- 系統整合測試：在動態環境下服務間的互動會產生非常微妙的行為，難以視覺化及全面測試。經典微服務往往不太重視測試，更多的是通過監控發現生產環境的異常，進而快速回滾或採取其他必要的行動。但對於特別在意風險規避監管或投產環境錯誤會產生顯著影響的場景下需要特別注意。
解決方案：
- 服務註冊與發現，服務監控，日誌監控，呼叫追蹤
- 服務容錯：需要引入熔斷、隔離、限流和降級、超時機制等服務容錯機制來保證服務持續可用性
- 服務安全
參考：