[[415339]]

本文轉載自微信公眾號「捉蟲大師」，作者捉蟲大師。轉載本文請聯系捉蟲大師公眾號。

前言

在之前的文章中分析了Nacos配置中心，配置中心的核心是配置的創建、讀取、推送。

注冊中心的核心比配置中心多一個服務探活模塊，他倆的相似度非常高，甚至阿里內部的注冊中心就叫ConfigServer。

Nacos注冊中心打算分成幾個模塊來分析，本文重點在于概要設計，基于2.0.0版本。

環境搭建

用Nacos的源碼來搭建源碼閱讀和調試環境，可參考《Nacos配置中心模塊詳解》 Nacos調試環境搭建部分。

其中 JVM參數可以指定只啟動Naming模塊，也可以不指定，默認全都啟動。

example模塊下將NamingExample復制一份進行測試。

設計概要

服務發現模型

客戶端視角的服務發現模型(注意：服務端視角的模型定義與客戶端視角有區別)包含以下幾點內容：

• Service：服務
• Cluster：集群
• Instance：實例

代碼注釋：We introduce a 'service --> cluster --> instance' model, in which service stores a list of clusters, which contains a list of instances

他們的關系如下

Service

• name：服務名
• protectThreshold：保護閾值，限制了實例被探活摘除的最大比例
• appName：服務的應用名，暫無實際用處
• groupName：分組名
• metadata：元數據

Cluster

• serviceName：所屬服務名
• name：集群名
• healthChecker：服務探活配置，此處僅對服務端主動探活生效，有TCP、HTTP、MySQL、None幾種方式，默認TCP
• defaultPort：默認端口
• defaultCheckPort：默認探活端口
• useIPPort4Check：是否使用port進行探活
• metadata：元數據

Instance

• instanceId：實例id，唯一標志，Nacos提供了simple和snowflake兩種算法來生成，默認是simple，其生成方式為ip#port#clusterName#serviceName
• ip：實例ip
• port：實例port
• weight：實例權重
• healthy：實例健康狀態
• clusterName：所屬集群名
• serviceName：所屬服務名
• metadata：元數據
• enabled：是否接收請求，可用于臨時禁用或摘流等場景
• ephemeral：是否為臨時實例，后文會介紹該參數
• getInstanceHeartBeatInterval：獲取實例心跳上報間隔時間，默認5秒，可配置
• getInstanceHeartBeatTimeOut：獲取心跳超時時間，15秒，配置
• getIpDeleteTimeout：獲取ip被刪除的超時時間，默認30秒，可配置
• getInstanceIdGenerator：獲取id生成器

除了上述的三層模型外，Nacos注冊中心和配置中心有著一樣的namespace設計，與client綁定，可隔離環境，租戶。

接口設計

• registerInstance：注冊實例
• deregisterInstance：注銷實例
• getAllInstances：獲取一個服務的所有實例(包括不健康)
• selectInstances：根據條件獲取一個服務的實例
• selectOneHealthyInstance：根據負載均衡策略獲取服務的一個健康的實例
• subscribe：訂閱服務
• unsubscribe：取消訂閱服務
• getServicesOfServer：根據條件分頁獲取所有服務

交互流程

Nacos 2.0 為ephemeral不同的實例提供了兩套流程：

• ephemeral=false，永久實例，與server端的交互采用http請求，server節點間數據同步采用了raft協議，健康檢查采用了server端主動探活的機制
• ephemeral=true，臨時實例，與server端的交互采用grpc請求，server節點間數據同步采用了distro協議，健康檢查采用了TCP連接的KeepAlive模式

臨時實例的交互流程

• client初始化，與server建立連接

只與其中一臺server節點建立長連接

• client 注冊服務，將serviceName+ip+port+clusterName等數據打包發送grpc請求

同時客戶端緩存已注冊過的服務，當client與server連接斷開重連時，client重新將這些數據注冊到server端

• server端接收到client的注冊請求，將注冊信息存入client對象(用于保存client的所有數據)中，并觸發ClientChangedEvent、ClientRegisterServiceEvent、InstanceMetadataEvent
  • ClientChangedEvent觸發server節點之間的數據同步(distro協議)
  • ClientRegisterServiceEvent觸發更新publisherIndexes(保存service => clientId的Map
  • InstanceMetadataEvent，處理元數據，Nacos在2.0中將元數據與基礎數據拆分開，分為不同的處理流程
• client訂閱服務
  • 根據serviceName、groupName、clusters信息生成key，創建eventListener，同時向server端發送訂閱請求，并緩存訂閱信息，用于連接斷開重連后再次向server端發送信息
• server端接收到client的訂閱請求
  • 將訂閱信息打包為subscribers，并存入client對象中，觸發ClientSubscribeServiceEvent事件
  • ClientSubscribeServiceEvent事件更新subscriberIndexes(保存service => clientId的Map
  • ServiceSubscribedEvent事件會延時500ms向該client推送該服務的最新數據
• 反向的操作如注銷、取消訂閱與正向操作類似，不再贅述

最后

本文從總體上分析了Nacos 2.0的模型設計、接口設計以及交互流程，讀完后對Nacos的服務發現有一個整體上的認識。后續篇幅會從細節入手，如dubbo Nacos擴展、一致性協議、探活、CMDB擴展等逐一進行分析。