「微服務系列 10」微服務框架的治理環節

一個國家若是人多了那麼就須要一個政府，這個政府須要對這個國家的人民進行管理和治理。在微服務的體系也是如此，若是在一個公司的微服務體系多了也須要有管理和治理的能力。

下圖把跟微服務治理相關的環境列舉了出來，一個好的微服務須要關注哪些治理環境

1. 服務註冊發現

微服務當中有不少服務，幾十個上百個，它們當中有錯中複雜的依賴關係，這個時候就存在服務的消費者怎麼發現生產者，這個就是服務註冊發現須要解決的問題。

2. 服務的負載均衡

爲了應對大的流量，咱們的服務提供方通常都是大規模部署，這個時候就存在服務的負載均衡的問題，另外咱們的服務須要路由，這個能力很是重要，若是咱們須要灰度發佈或者藍綠髮布的機制，那麼須要考慮軟路由的機制。

3. 監控-日誌

日誌對於咱們後期排錯找出問題，定位問題是很是關鍵，咱們一套好的監控治理框架須要集成日誌服務

4. 監控-metrics

當咱們須要對服務的調用量進行監控，對服務延遲出錯數有一個好的監控手段，這就是me監控環境

5. 監控-調用鏈埋點

微服務有錯綜複雜的調用關係，就像一個網狀通常，若是沒有好的調用鏈監控，開發人員很容易迷失在當中，出問題很難定位，有了好的調用鏈監控會幫助咱們快速定位問題，更好的理解整套微服務系統。

6. 限流熔斷

微服務是一個分佈式系統，若是沒有好的限流熔斷措施，當一個服務出現故障或者出現延遲，會形成整個系統癱瘓。

7. 安全-訪問控制

有些服務並不但願全部的人都能去調用到，涉及到一些敏感信息，比例跟錢相關的信息，那麼咱們須要安全和訪問的控制策略，來限制對這些服務的訪問。

8. rpc & rest

rpc和rest根據以前的對比，二者各有優劣，若是一個微服務框架中能支持這兩個調用，能兼容更多的技術棧，會更加的靈活

9. 序列化

序列化中，有高性能但對開發人員不優化的二進制序列化，也有對開發人員至關友好的但性能未必最佳的文本式序列化，這個須要根據場景進行靈活的配置，消息系列化協議

10. 代碼生成

如今在大規模開發的狀況下，比較推從一個契約驅動開發的方法，開發人員先定立契約，代碼自動生成的方式生成對應的代碼腳手架，這個在大規模開發的時候更能確保代碼的一致和規整

11. 統一異常處理

咱們但願服務治理的環節能集成統一的服務異常處理的能力，這樣的化異常可以達到更加標準化，出現問題能更好定位好屬於什麼類型的問題。若是說沒有這樣的一個環節，你們各自的玩法不同，拋的異常各異，出現問題難以定位和沒法標準化友好輸出。

12. 文檔

微服務最終是要給消費者去使用，暴露出去的API若是沒有好的文檔，只提供出一些代碼，接入方接入的成本會變成比較高，好的文檔體系是各方協調和效率的保證。

13. 集中配置中心

微服務框架須要集成集中式的配置能力，避免各個服務間各自配置，增快參數調整的速度和規範統一格式。

14. 後臺集成MQ，Cache，DB

微服務治理的核心思路就是把上面講到的各個環節沉澱下來，變成平臺和框架的一部分，開發人員能夠更加專一業務邏輯的實現，在實現業務邏輯的時候不須要去關注外部環節的，從而提高開發的效率，治理環節沉澱在框架之中有專門的平臺架構團隊去進行管控

博客地址：「微服務系列 10」微服務框架的治理環節