背景介紹
前幾篇文章介紹了Nacos配置中心服務的能力機制，接下來壶硅，我們來介紹Nacos另一個非常重要的特性就是服務注冊與發(fā)現(xiàn)葬荷，說到服務的注冊與發(fā)現(xiàn)相信大家應該都不陌生坑夯，在微服務盛行的今天岖寞，服務是非常重要的，而在 Nacos 中服務更被稱為他的一等公民柜蜈。Nacos 支持幾乎所有主流類型的 “服務” 的發(fā)現(xiàn)仗谆、配置和管理。
服務 (Service)
服務是指一個或一組軟件功能（例如特定信息的檢索或一組操作的執(zhí)行）淑履，其目的是不同的客戶端可以為不同的目的重用（例如通過跨進程的網(wǎng)絡調用）隶垮。Nacos 支持主流的服務生態(tài)，如 Kubernetes Service秘噪、gRPC|Dubbo RPC Service 或者 Spring Cloud RESTful Service狸吞。
nacos的架構圖所示
(dubbo) RPC微服務的基礎架構
圖中的6個步驟的含義解釋如下：
- 服務容器負責啟動指煎，加載蹋偏，運行服務提供者。
- 服務提供者在啟動時至壤，向注冊中心注冊自己提供的服務威始。
- 服務消費者在啟動時，向注冊中心訂閱自己所需的服務像街。
- 注冊中心返回服務提供者地址列表給消費者黎棠，如果有變更，注冊中心將基于長連接推送變更數(shù)據(jù)給消費者镰绎。
- 服務消費者脓斩，從提供者地址列表中，基于軟負載均衡算法畴栖，選一臺提供者進行調用俭厚，如果調用失敗，再選另一臺調用驶臊。
- 服務消費者和提供者挪挤，在內存中累計調用次數(shù)和調用時間叼丑，定時每分鐘發(fā)送一次統(tǒng)計數(shù)據(jù)到監(jiān)控中心。
服務注冊中心 (Service Registry)
上圖中Registry就是注冊中心扛门，負責服務的注冊與發(fā)現(xiàn)鸠信，Dubbo服務體系之前使用Zookeeper或者自己的Registry 實現(xiàn)，而 Nacos 則是另一種 Registry的實現(xiàn)论寨。
服務注冊中心星立，它是服務，其實例及元數(shù)據(jù)的數(shù)據(jù)庫（Dubbo3已經(jīng)將源數(shù)據(jù)中心葬凳、配置服務全部提取獨立出來了）绰垂，服務實例在啟動時注冊到服務注冊表，并在關閉時注銷火焰。
服務和路由器的客戶端查詢服務注冊表以查找服務的可用實例劲装，服務注冊中心可能會調用服務實例的健康檢查 API 來驗證它是否能夠處理請求。
服務元數(shù)據(jù) (Service Metadata)
服務元數(shù)據(jù)是指包括服務端點(endpoints)昌简、服務標簽占业、服務版本號、服務實例權重纯赎、路由規(guī)則谦疾、安全策略等描述服務的數(shù)據(jù)。
邏輯架構及其組件介紹
- 服務管理：實現(xiàn)服務CRUD犬金，域名CRUD念恍，服務健康狀態(tài)檢查，服務權重管理等功能
- 配置管理：實現(xiàn)配置管CRUD晚顷，版本管理樊诺，灰度管理，監(jiān)聽管理音同，推送軌跡词爬，聚合數(shù)據(jù)等功能
- 元數(shù)據(jù)管理：提供元數(shù)據(jù)CURD 和打標能力
- 插件機制：實現(xiàn)三個模塊可分可合能力，實現(xiàn)擴展點SPI機制
- 事件機制：實現(xiàn)異步化事件通知权均，sdk數(shù)據(jù)變化異步通知等邏輯
- 日志模塊：管理日志分類顿膨，日志級別，日志可移植性（尤其避免沖突）叽赊，日志格式恋沃，異常碼+幫助文檔
- 回調機制：sdk通知數(shù)據(jù)，通過統(tǒng)一的模式回調用戶處理必指。接口和數(shù)據(jù)結構需要具備可擴展性
- 尋址模式：解決ip囊咏，域名，nameserver、廣播等多種尋址模式梅割，需要可擴展
- 推送通道：解決server與存儲霜第、server間、server與sdk間推送性能問題
- 容量管理：管理每個租戶户辞，分組下的容量泌类，防止存儲被寫爆，影響服務可用性
- 流量管理：按照租戶底燎，分組等多個維度對請求頻率刃榨，長鏈接個數(shù)，報文大小双仍，請求流控進行控制
- 緩存機制：容災目錄枢希，本地緩存，server緩存機制朱沃。容災目錄使用需要工具
- 啟動模式：按照單機模式苞轿，配置模式，服務模式为流，dns模式呕屎，或者all模式让簿，啟動不同的程序+UI
- 一致性協(xié)議：解決不同數(shù)據(jù)敬察，不同一致性要求情況下，不同一致性機制
- 存儲模塊：解決數(shù)據(jù)持久化尔当、非持久化存儲莲祸，解決數(shù)據(jù)分片問題
- Nameserver：解決namespace到clusterid的路由問題，解決用戶環(huán)境與nacos物理環(huán)境映射問題
- CMDB：解決元數(shù)據(jù)存儲椭迎，與三方cmdb系統(tǒng)對接問題锐帜，解決應用，人畜号，資源關系
- Metrics：暴露標準metrics數(shù)據(jù)缴阎，方便與三方監(jiān)控系統(tǒng)打通
- Trace：暴露標準trace，方便與SLA系統(tǒng)打通简软，日志白平化蛮拔，推送軌跡等能力，并且可以和計量計費系統(tǒng)打通
- 接入管理：相當于阿里云開通服務痹升，分配身份建炫、容量、權限過程
- 用戶管理：解決用戶管理疼蛾，登錄肛跌，sso等問題
- 權限管理：解決身份識別，訪問控制，角色管理等問題
- 審計系統(tǒng)：擴展接口方便與不同公司審計系統(tǒng)打通
- 通知系統(tǒng)：核心數(shù)據(jù)變更衍慎，或者操作转唉，方便通過SMS系統(tǒng)打通，通知到對應人數(shù)據(jù)變更
- OpenAPI：暴露標準Rest風格HTTP接口西饵，簡單易用酝掩，方便多語言集成
- Console：易用控制臺，做服務管理眷柔、配置管理等操作
- SDK：多語言sdk
- Agent：dns-f類似模式期虾，或者與mesh等方案集成
- CLI：命令行對產(chǎn)品進行輕量化管理，像git一樣好用
Nacos 的服務注冊與發(fā)現(xiàn)
服務提供方 (Service Provider)
是指提供可復用和可調用服務的應用方驯嘱。
模擬服務注冊
服務注冊最重要的就是將服務注冊到哪里镶苞，在注冊中心服務端，肯定有一個用來管理服務的容器鞠评，他保存著所有服務的實例茂蚓。不需要知道該容器具體的實現(xiàn)細節(jié)，只需要知道有這樣一個概念剃幌。
- 將同一個服務的兩個實例注冊到 Nacos 中：
- 雙注冊模式注入進入
- 維持服務在線狀態(tài)
demo代碼如下：
通過 NamingService 接口的 registerInstance 方法就可以將服務進行注冊了聋涨，該方法有很多重載的方法，這里我們選擇一個簡單的來調用就好了负乡。注冊完成后牍白，通過調用 getAllInstances 方法，立即獲取所有可用的實例抖棘，然后讓主線程等待茂腥，打印如下：
可以發(fā)現(xiàn)naming客戶端成功獲取到了兩個實例。
服務消費方 (Service Consumer)
服務注冊到注冊中心后切省，服務的消費者就可以進行服務發(fā)現(xiàn)的流程了最岗，消費者可以直接向注冊中心發(fā)送獲取某個服務實例的請求，這種情況下注冊中心將返回所有可用的服務實例給消費者朝捆，但是一般不推薦這種情況般渡。另一種方法就是服務的消費者向注冊中心訂閱某個服務，并提交一個監(jiān)聽器芙盘，當注冊中心中服務發(fā)生變更時驯用，監(jiān)聽器會收到通知，這時消費者更新本地的服務實例列表何陆，以保證所有的服務均是可用的晨汹。
Nacos消費服務機制
是指會發(fā)起對某個服務調用的應用方。服務注冊之后贷盲，服務的消費者就可以向注冊中心訂閱自己所需要的服務了淘这，注冊中心會將所有服務的實例“推送”給消費者剥扣，實際上獲取服務是客戶端主動輪詢的，跟客戶端獲取配置中心的配置項的原理一樣铝穷。
現(xiàn)在我創(chuàng)建一個服務消費者钠怯，然后向注冊中心訂閱一個服務，當接收到注冊中心返回的服務列表之后曙聂，執(zhí)行5次 select 服務實例的操作晦炊，相當于進行一個模擬的服務請求，具體的代碼如下圖所示：
其中的 printInstances 方法主要是打印出所有服務的實例宁脊，將 ServiceConsumer 類啟動之后断国，打印出如下的日志：
Nacos機制負載均衡
負載均衡有很多中實現(xiàn)方式，包括輪詢法榆苞，隨機方法法稳衬，對請求ip做hash后取模等等，從負載的維度考慮又分為：服務端負載均衡和客戶端負載均衡坐漏。Nacos 的客戶端在獲取到服務的完整實例列表后薄疚，會在客戶端進行負載均衡算法來獲取一個可用的實例，模式使用的是隨機獲取的方式赊琳。
Nacos 服務注冊與訂閱的完整流程
Nacos客戶端進行服務注冊有兩個部分組成街夭，一個是將服務信息注冊到服務端，另一個是像服務端發(fā)送心跳包躏筏，這兩個操作都是通過NamingProxy 和服務端進行數(shù)據(jù)交互的板丽。
Nacos客戶端進行服務訂閱時也有兩部分組成，一個是不斷從服務端查詢可用服務實例的定時任務寸士，另一個是不斷從已變服務隊列中取出服務并通知 EventListener 持有者的定時任務檐什，更新服務訂閱列表碴卧。
