導語：近期，國外HashiCorp在官網宣佈，不允許中國境內使用、部署和安裝該企業旗下的企業版產品和軟件，其中包括Consul。那麼國內企業有沒有類似的服務可以提供呢？答案是有！我們一起來看看華爲雲ServiceStage。
近年來越來越多的企業開始實踐微服務，而微服務在企業應用落地的過程，面臨着微服務開發框架的選型，無論是自研還是選擇第三方框架都不得不考慮的問題包括：微服務框架是否具備高可靠性，任何時間不能中斷業務；微服務框架是否能夠實現高速通信性能，保證業務從單體架構向微服務架構切換時，性能下降不會太多。本文從服務管理中心、通信處理兩個模塊來介紹華爲開源微服務框架 SeviceComb 如何幫助企業應用快速具備高性能的通信能力以及高可靠的服務管理能力。上篇先介紹微服務的服務管理中心。
ServiceCenter 整體介紹
圖 1 ServiceCenter 整體介紹
ServiceCenter 是一個具有微服務實例註冊 / 發現能力的微服務組件，提供一套標準的 RESTful API 對微服務元數據進行管理。ServiceComb 的微服務註冊及動態發現能力也是依賴其實現的。
除了以上描述的微服務動態發現外，ServiceCenter 幫助應用具備以下能力：
-
實例緩存機制
基於 SDK 開發的微服務，會在第一次消費 Provider 微服務時，會進行一次實例發現操作，此時內部會請求 ServiceCenter 拉取 Provider 當前存活的實例集合，並保存到內存緩存當中，後續消費請求就依據該緩存實例集合，按照自定義的路由邏輯發送到 Provider 的一個實例服務中。
這樣處理的好處是，已經運行態的 SDK 進程，始終保留一份實例緩存；雖然暫時無法感知實例變化及時刷新緩存，但當重新連上 ServiceCenter 後會觸發一緩存刷新，保證實例緩存是最終有效的；在此過程中 SDK 保證了業務始終可用。
圖 4 微服務實例緩存機制
-
異步緩存機制
在 ServiceCenter 內部，因爲本身不存儲數據，如果設計上單純的僅作爲一個 Proxy 服務轉發外部請求到 etcd，這樣的設計可以說是不可靠的，原因是因爲一旦後端服務出現故障或網絡訪問故障，必將導致 ServiceCenter 服務不可用，從而引起客戶端實例信息無法正確拉取和刷新的問題。所以在設計之初，ServiceCenter 引入了緩存機制。
圖 6 異步緩存機制
1. 啓動之初，ServiceCenter 會與 etcd 建立長連接（watch），並實時監聽資源的變化。
2. 每次 watch 前，爲防止建立連接時間窗內發生資源變化，ServiceCenter 無法監聽到這些事件，會進行一次全量 list 查詢資源操作。
3. 運行過程中，List & watch 所得到的資源變化會與本地緩存比對，並刷新本地緩存。
4. 微服務的實例發現或靜態數據查詢均使用本地緩存優先的機制。
異步刷新緩存機制，可以讓 ServiceCenter 與 etcd 的緩存同步是異步的，微服務與 ServiceCenter 間的讀請求，基本上是不會因爲 etcd 不可用而阻塞的；雖然在資源刷新到 ServiceCenter watch 到事件這段時間內，會存在一定的對外呈現資源數據更新延時，但這是可容忍範圍內的，且最終呈現數據一致；這樣的設計即大大提升了 ServiceCenter 的吞吐量，同時保證了自身高可用。
-
自我保護機制
前面提到的緩存機制，保證了 ServiceCenter 在 etcd 出現網絡分區故障時依然保持可讀狀態，ServiceCenter 的自我保護 (Self-preservation) 機制保證了 Provider 端與 ServiceCenter 在出現網絡分區故障時依然保持業務可用。
現在可以假設這樣的場景：全網大部分的 Provider 與 ServiceCenter 之間網絡由於某種原因出現分區，Provider 心跳無法成功上報心跳。這樣的情況下，在 ServiceCenter 中會出現大量的 Provider 實例信息老化下線消息，ServiceCenter 將 Provider 實例下線事件推送到全網大部分的 Consumer 端，最終導致一個結果，用戶業務癱瘓。可想而知對於 ServiceCenter 乃至於整個微服務框架是災難性的。
爲了解決這一問題，ServiceCenter 需要有一個自我保護機制（Self-preservation）：
圖 8 ServiceCenter 的自我保護機制
1. ServiceCenter 在一個時間窗內監聽到 etcd 有 80% 的實例下線事件，會立即啓動自我保護機制。
2. 保護期間內，所有下線事件均保存在待通知隊列中。
3. 保護期間內，ServiceCenter 收到隊列中實例上報註冊信息則將其從隊列中移除，否則當實例租期到期，則推送實例下線通知事件到 consumer 服務。
4. 隊列爲空，則關閉自我保護機制。
有了自我保護機制後，即使 etcd 存儲的數據全部丟失，這種極端場景下，SDK 與 ServiceCenter 之間可在不影響業務的前提下，做到數據自動恢復。雖然這個恢復是有損的，但在這種災難場景下還能保持業務基本可用。
以上就是 ServiceComb 的服務管理中心在分佈式系統下的高可靠架構設計，在進行大規模、高併發的企業應用開發時，可靠的服務管理中心能夠使得分佈式系統運行更加穩定，同時高性能的通信也使得分佈式系統更高效地處理密集的業務。
點擊這裏，瞭解更多精彩內容