前言

本文以ZK為例介紹下注冊中心

ZK功能

檔案系統

資料儲存是檔案機制非檔案儲存所有節點在zk中都是一個樹

通知機制

透過watch tcp長連線實現

分散式程式協調服務節點選主

圖1

上圖是應該基於zk選主的模式zk內部主從模式：本身主節點掛了 使用ZAB協議選主 

配置管理

zk的葉子節點當然也可以儲存超時時間等配置資訊 只是不優雅

粗力度分散式鎖

zk和etcd都可以做分散式鎖 etcd社群比較活躍 效能較好

主備高可用切換

主節點掛了 從節點選主的過程 類似圖1主掛了 zk心跳知道主掛了從3個slave節點中 選擇主誰寫成功 誰就是主

服務註冊發現

註冊和發現不是zk擅長的 用的比較多前面幾點才是zk擅長的 但用的不多

服務註冊和發現產品比較

1、ZAB是Paxos輕量級實現2、Euraka追求資料最終一致性 所以不需要一致性保證(apollo配置中心內部是用euraka做的)3、多資料中心就是多機房在多個機房中只部署了一套zk一旦出現了網路劃分 整個zk節點就不可用只有consul可用 基於同步協議Gossip來做的redis cluster也是用的Gossip協議來實現的(Gosship 是明文傳呼 可以先加密資料再透過該協議傳輸或者內部服務之間明文傳輸也沒有關係)4、所有CP模型都是支援KV儲存的5、a、zk服務健康檢查其實很弱僅僅支援心跳 實質tcp層面的ping服務假死情況 它發現不了b、consual服務健康檢測做的比較好c、euraka最弱預設配置不支援 必須要顯示做一些配置d、metrics 埋的一些點 記錄請求響應時間 耗時情況

Long Polling

zk不是服務發現領域最佳選擇

1、服務註冊發現是AP模型 ZK是CP模型2、幾百臺zk叢集 最多1000臺 沒有問題超過了一定的數量比如幾萬臺 zk就會不堪重負

服務註冊發現是AP模型還是CP模型?要從資料一致性需求分析

註冊中心作用：丟給註冊中心一個 server name返回一個對應的ip和port如果呼叫方獲取到的伺服器給的ip不一樣 會有什麼影響？

服務註冊發現對資料一致性要求不高 最終一致性即可

在多個機房中只部署了一套zk 一旦出現了網路劃分 整個zk節點就不可用

假設 機房3突然和機房2和機房1的網路斷了即機房3出現了網路分割槽 網路劃分機房間網路劃分機房3 機房內還是通的理論層zk叢集還可以用實際情況整個zk叢集都不可用了一旦網路發生分割槽 就會選舉多個主節點 就會不一致了

原因是

ServerB2作為新服務 此時註冊ZK不成功因為機房3中的ZK節點已經脫離了ZK叢集不能透過ZK對服務進行擴容、重啟、部署

期望的效果

期望的是跨機房不可用但機房3中的ServiceA呼叫ServiceB是可以用的雖然說有多機房 很多情況下更鼓勵在同一個機房內服務之間呼叫機房內服務呼叫 服務內響應延遲會變的很低服務每個機房都成了孤島 每個機房呼叫只拿到本機房的服務列表反而有更好的服務鏈路呼叫效果千萬不能因為自身的任何問題 破壞了服務之間的聯通性

原生ZK

但原生的ZK同機房的服務呼叫也不可用因為ZK是CP模型為了保證網路分割槽下P （腦裂下）C一致性 A的可用性也讓它不可用

ZK儲存了大量的資訊

1、寫到zk裡面的任何一個寫操作 為了保證cp 都會在從節點上都會在寫一份2、keepalive 、心跳資訊、節點註冊 全部都會在叢集中同步3、服務釋出大量註冊寫請求4、毫秒級服務健康狀態的寫請求

ZK叢集最多支援1000臺

zk是分散式的根據paxios協議 選zk主 zk從zk主 是寫入單點 不能水平擴充套件從節點可以擴充套件 類似mysql 主從主只能有一個zk叢集規模不能很多 1000臺撐死了叢集有1萬臺 就會不堪負載

根據業務功能 垂直拆分叢集?

根據業務功能 垂直拆分叢集58 房產、招聘、二手車房產有自己的zk叢集招有自己的zk叢集二手車有自己的zk叢集破壞了公司整體服務的連通性彼此不可以呼叫了業務整合聯通性不可預知比如搜尋業務1000臺機器zk推薦業務1000臺機器zk若將搜尋和推薦做一個叢集zk 2000臺 就不行了

為什麼zk 到1000臺就不行了？

有大量的持久化儲存和事務

其實不需要儲存 目的是為了做cp 所以儲存了

ZK 2PC 兩階段提交事務

leader和其他節點資料提交 全部是二階段提交 2PC(Propose ACK Commit)強一致性 每一步都是2pc 同步阻塞寫

ZK探活機制

track機制即tcp長連線 向網路發一個ping命令

logic1服務死了 zk不知道因為zk的KeepAline機制太弱了 太淺層了

應該怎麼處理?

1、tcp活性探測即每隔段時間心跳檢測 如果服務死了就踢出2、服務健康與否的邏輯開放給服務方 讓服務方自定義zk server只管服務方定製的狀態具體死活 zk不需要判斷

註冊中心容災

zk原生客戶端有很多問題

zk clinet和zk server很多情況下是弱依賴很多情況下 不需要與zk強依賴zk的ip節點存在本地 每次啟動會從zk拉取如果拉不到 用本地ip需要強依賴的場景就是服務釋出、上下線、擴容zk原生客戶端沒有快取資料機制(沒有快取ip列表)

綜上:zk完全不適合做註冊中心

ZK使用場景

低頻事務適合（tps低的）

這些元件的分散式協調器都是zk

如何模擬網路異常

zk叢集其中一臺機器網路斷掉或防火牆進出設定下

如果模擬服務假死

在業務邏輯層while(True)

自研資料中心如何設計

註冊中心業務流程及熔斷機制

1、服務管理平臺：服務展示、呼叫關係展示（梳理服務之間呼叫關係）以及入口、引數配置（超時時間、熔斷規則、降級規則、IP:Port）、控制中心註冊資訊、有自己的db儲存2、服務發現不需要直接連線控制中心3、熔斷極端情況下 熔斷不了 影響也不大 可損4、服務管理平臺不需要和業務邏輯層互動業務邏輯層需要和服務管理平臺互動（服務質量情況 監控 流量情況）5、服務控制：註冊資訊儲存、指令下發6、控制中心（服務版本資訊、ip:port、服務名稱） 無狀態化 多個節點 多個控制中心之間 指令同步控制中心多個節點服務相互探活7、全部都是服務叢集 熔斷其中一臺資料訪問層推送給業務邏輯層的所有叢集8、服務發現方第一次獲取服務列表 若拿不到就採用本地配置上線的時候 肯定是知道 下游是哪一臺拿到的資訊更新本地配置9、推送指令有沒有到達業務邏輯層？ccp和控制中心通訊 長連線推送 給ack沒有給ack再推送10、服務管理平臺也會在記憶體中快取一份快取有髒資料 無所謂 流量不均衡而已11、服務管理平臺還是控制中心 全是去中心化的12、熔斷是針對api粒度的

服務權重配置

機器配置高 允許流量高 權重配置高些 比如10 其他就是8

服務分組

物理隔離

後續

後續會推出配置中心實踐