分佈式技術原理於算法解析01

註冊中心原理

• 服務提供者註冊流程
• 服務提供者反註冊流程
• 服務消費者查詢流程
• 服務消費者訂閱變更流程
  
• 第一步檢查節點列表是否存在
• 第二步查看註冊的Cluster（服務的接口名）是否存在？不存在拋出異常
• 第三步查看分組是否存在？不存在拋出異常

節點反註冊

• 第一步查看服務的分組是否存在不存在拋出異常
• 第二步查看服務名稱是否存在不存在拋出異常
• 第三步查看節點是否存在，存在刪除節點，不存在拋出異常
• 第四步更新接口的Sign

查詢節點信息

服務消費者查看節點信息

• 第一步從local cache 本地緩存中查找 （服務消費者把服務信息存在本機內存）主要是因爲服務節點信息並不是總是時刻變化的，並不需要每一次服務都要調服務註冊中心獲取最新的節點信息，只需要本機保存最新的服務提供者的節點列表

• 第二步snapshot（本地快照）中查找，（爲什麼服務消費者要在本地磁盤存儲一份服務提供者的節點列表信息）

• 主要是因爲服務消費者和註冊中心之間的聯繫不一定可靠，服務消費者重啓時，本機內存還不存在服務提供者的節點信息，如果此時調用註冊中心失敗，那麼服務消費者就拿不到服務節點的信息，也就沒有辦法調用了，本地快照就是爲了防止這樣的情況發生，即使服務消費者重啓後請求註冊註冊中心
  失敗，依然可以讀取本地快照，獲取節點服務信息。

訂閱服務變更

• 服務消費者從註冊中心獲取服務信息之後，就訂閱了服務的變化，會在本地保留Cluster的sign值。
  服務消費者每隔一段時間調用getSign()函數，從註冊中心獲取服務端該Cluster的sign值，並與本地保留的sign值作對比如果不一致就從服務端拉取新的節點信息，並更新localcache和snapshot

多註冊中心

• 理論上對於一個服務消費者來說，同一個註冊中心交互最簡單，但是一定會存在於服務消費者同時訂閱了多個服務，多個服務可能是由多個部門提供的，而且不同部門都有自己的註冊中心，提供的服務只在自己的註冊中心裏面有記錄，這樣的話就要求多個註冊中心訂閱服務的能力。

• 對於服務消費者來說，要能夠同時從多個註冊中心訂閱服務；對於服務提供者來說，要同時向多個註冊中心註冊服務。

並行訂閱服務

• 每訂閱一個服務就單獨用一個線程來處理，這樣即使遇到個別服務節點連接超時，其他服務節點也不會受影響，最慢的這個服務就是節點初始化連接所耗費的時間。

批量反註冊服務

• 通常一個服務提供者節點服務提供不止一個服務，所以註冊和反註冊都需要多次調用註冊中心，在與註冊中心的多次交互中可能由於網絡的抖動，註冊中心集羣異常等原因導致個別調用失敗，對於註冊中心來說，偶發的註冊調用失敗對服務調用基本沒有影響，其結果頂多就是某一個服務少了一個可用的節點，但偶發的發註冊調用失敗會導致不可用的節點殘留在註冊中心，變成殭屍節點。

• 通過優化反註冊邏輯，對於下線機器，節點銷燬的場景，通過調用註冊中心的反註冊接口，一次調用就可以把該節點上提供的所有服務反註冊掉，從而避免了“殭屍節點‘的出現

服務變更信息增量更新

• 服務消費者端啓動時，除了會查詢訂閱服務的可用節點列列表做初始化連接還會訂閱服務的變更，每隔一段時間從註冊中心虎丘最新的服務節點信息標記sign,並與本地保持的sign值作對比，如果不一樣則調用註冊中心獲取最新的服務節點信息。

• 一般情況下按照這個過程是沒有問題的，但是在網絡頻繁抖動的時候，服務提供者上報給註冊中心的心跳可能會一會失敗一會成功，這時候註冊中心就會頻繁更新服務的可用節點信息，導致服務消費者從註冊中心拉取最新的服務可用節點信息，嚴重時可能產生網絡風暴，導致註冊中心的帶寬被拉滿
  爲了減少服務消費者從註冊中心拉去的屈服可用節點信息的數據量，這個時候可以通過增量更新的方式，註冊中心只返回變化的那部分節點信息，尤其在只有少數節點信息變更的時。