1.微服務應該具備的功能
- 服務註冊發現
- 服務負載均衡
- 服務容錯
- 服務網關
- 服務配置中心
- 服務鏈路追蹤
- 服務實時日誌
2.服務註冊發現
由於微服務系統的服務力度較小，服務熟練多，所以需要一個共同的註冊中心來統一管理微服務實例
註冊中心會提供服務的健康檢查方案，檢查該註冊服務收費可用。通常是一個服務實例註冊後， 會定時的向服務中心提供‘心跳’檢測
3.服務負載均衡
網絡往往有不可靠性，爲了保證服務高可用性，服務往往都是集羣部署的。
4.服務容錯
微服務，小而多，一般落地到實際項目中後，服務的數量基本上會非常多，各個服務之間相互調用關聯也會錯綜複雜，一個功能往往需要請求調用多個服務才能完成，如果一個服務暫時不可用了，會影響到依賴於這個不可用的服務的其他服務。一個不可用服務的線程資源消耗完後，進而會調用依賴於它們的服務也不可用，最好導致整個系統處於癱瘓狀態了
爲了解決這個問題，分佈式系統引進了熔斷器機制。如果服務處理用戶請求失敗的次數大於了設定的閥值時，就說明服務出現了故障，打開熔斷器，所有請求進行快速失敗，不再執行業務邏輯。當處於打開狀態的熔斷時，過一段時間處於半打開狀態，執行一定量的請求，剩餘的依然執行快速失敗，若執行的請求失敗了，繼續保持熔斷，如果成功了，就關閉熔斷器
5.服務網關
網關，對API接口資源進行統一暴露，內部服務部直接對外提供API資源，將內部服務隱藏起來。網關通常有請求轉發，安全驗證，權限認證等功能，可以實現流量監控，實時日誌輸出，記錄請求訪問情況等。
6.配置中心
實際開發中，每一個服務都需要有大量的配置文件，而這些配置文件通常會有dev本地的，test測試的，prod線上的，每個環境也是不一樣的。服務越多，配置文件的管理也越複雜。
7.服務鏈路追蹤
微服務按業務劃分爲多個服務單元，一個用戶的請求可能通過前端A,請求到中間件B,或者C,在到達後端服務D或者F,最後纔將數據返回給用戶。這麼一段請求過程，就需要服務鏈路追蹤，快速定位出現問題的地方。