引言

隨著越來越多的公司應用服務化，總結下這段時間了解到服務化相關的東西，這里不談服務到底是SOA，還是微服務，筆者在網上搜了一些相關資料，看得很是懵逼，所以這里只談談筆者在項目中理解到的一些東西。

image.png

服務化架構圖

image.png

API Gateway

Gateway 層主要給用戶提供統一入口、API配置管理、分流、鑒權、服務監控、協議轉換。

服務化治理

image.png

服務注冊發現

服務在啟動的時候會將服務名，集群名，機器ip，端口號等信息 注冊到服務治理中心。
消費方在調用服務方提供接口時，會向服務治理中心請求服務方的集群信息，并且訂閱集群的變更信息，當集群信息變化時，立即同步給消費方。

image.png

服務配置

在服務治理層改變配置之后，變更會同步給服務。

image.png

鏈路追蹤

服務化之后，服務會有成千上萬個，一個接口可能涉及到好幾個服務，中間件，調用關系復雜，怎么樣讓問題的追蹤和定位會變得比較方便，這時候我們就需要一個鏈路追蹤工具。鏈路追蹤工具的實現，著名的有Google Dapper。

image.png

負載均衡

consumer服務Client SDK 會內置一些負載均衡策略，目前在項目中內置了輪詢、權重輪詢、最少連接均衡策略，但是最少連接分流并不是很均衡。一致性hash負載均衡可以內置，在有些時候是可以提高本地內存緩存命中率。

服務健康檢查

目前項目中go client實現的健康檢查就比較粗暴，只會在拿到一個連接的時候會去調用下provider的ping 接口（接口定義規范）。在java client sdk 中粒度為依賴服務的實例級別的。在應用收到新增服務實例的消息后，會啟動一個此實例的后臺健康檢查線程。刪除服務實例的消息后，會停止并銷毀此實例對應的健康檢查線程。健康檢查在線程中循環執行，間隔為0.5s。連續失敗3次，視為服務死亡。成功1次，即視為服務存活。

服務熔斷

服務熔斷是一種服務自我保護機制。在客戶端實現，粒度為方法級別。

1. 統計策略

    每次請求時統計當前時間點前一定的閾值秒內請求的錯誤率。若滿足以下兩點：
    請求總數 > 一定的閾值；
    請求的錯誤率 = (非業務異常請求數+超時請求數)/總的請求數 > 一定的閾值。
    就會觸發熔斷，不再向服務端發送請求。     

2. 恢復策略

    恢復發生在熔斷保護期之后最小閾值。

1. 如果有請求到來，則放行一條請求用于測試服務端提供服務的質量（其他并發 來的請求還是處于熔斷中。

2. 如果這條測試的請求，正常完成調用，到熔斷保護期之后最大閾值之前會隨機性的通過一些流量，到最大閾值之后恢復正常；否則，繼續1。

3. 熔斷期間的行為

    熔斷之后，client的請求會拋出api 異常。

總結

服務治理設計到很多東西和細節，筆者只是簡單的總結下，還有很多東西沒有列出來，例如授權、限流、降級、超時，服務端內部狀態查詢等。