一文了解 Nacos

Nacos 在阿里巴巴起源于 $2008$ 年五彩石項目（完成微服務拆分和業務中臺建設），成長于十年雙十一的洪峰考驗，沉淀了簡單易用、穩定可靠、性能卓越的核心競爭力。 隨著云計算興起，$2018$ 年 Nacos（阿里內部 Configserver/Diamond/ Vipserver 內核）開源，作為阿里十年的沉淀，推動微服務行業發展，加速企業數字化轉型!

1.簡介

1.1 概覽

Nacos /nɑ:k??s/ 是 Dynamic Naming and Configuration Service 的首字母簡稱，一個更易于構建云原生應用的動態服務發現、配置管理和服務管理平臺。

Nacos 致力于幫助您發現、配置和管理微服務。Nacos 提供了一組簡單易用的特性集，幫助您快速實現動態服務發現、服務配置、服務元數據及流量管理。

Nacos 幫助您更敏捷和容易地構建、交付和管理微服務平臺。 Nacos 是構建以 服務 為中心的現代應用架構（例如微服務范式、云原生范式）的服務基礎設施。

1.2 什么是 Nacos

服務（Service）是 Nacos 世界的一等公民。Nacos 支持幾乎所有主流類型的 “服務” 的發現、配置和管理：

• Kubernetes Service
• gRPC & Dubbo RPC Service
• Spring Cloud RESTful Service

Nacos 的關鍵特性包括：

• 服務發現和服務健康監測

  • Nacos 支持基于 DNS 和基于 RPC 的服務發現。服務提供者使用 原生SDK、OpenAPI、或一個 獨立的 Agent TODO 注冊 Service 后，服務消費者可以使用 DNS TODO 或 HTTP&API 查找和發現服務。
  • Nacos 提供對服務的實時的健康檢查，阻止向不健康的主機或服務實例發送請求。Nacos 支持傳輸層 （PING 或 TCP）和應用層（如 HTTP、MySQL、用戶自定義）的健康檢查。 對于復雜的云環境和網絡拓撲環境中（如 VPC、邊緣網絡等）服務的健康檢查，Nacos 提供了 agent 上報模式 和 服務端主動檢測 $2$ 種健康檢查模式。Nacos 還提供了統一的健康檢查儀表盤，幫助您根據健康狀態管理服務的可用性及流量。

• 動態配置服務

  • 動態配置服務可以讓您以中心化、外部化和動態化的方式管理所有環境的應用配置和服務配置。
  • 動態配置消除了配置變更時重新部署應用和服務的需要，讓配置管理變得更加高效和敏捷。
  • 配置中心化管理讓實現無狀態服務變得更簡單，讓服務按需彈性擴展變得更容易。
  • Nacos 提供了一個簡潔易用的UI（控制臺樣例 Demo）幫助您管理所有的服務和應用的配置。Nacos 還提供包括配置版本跟蹤、金絲雀發布、一鍵回滾配置以及客戶端配置更新狀態跟蹤在內的一系列開箱即用的配置管理特性，幫助您更安全地在生產環境中管理配置變更和降低配置變更帶來的風險。

• 動態 DNS 服務

  • 動態 DNS 服務支持權重路由，讓您更容易地實現中間層負載均衡、更靈活的路由策略、流量控制以及數據中心內網的簡單 DNS 解析服務。動態 DNS 服務還能讓您更容易地實現以 DNS 協議為基礎的服務發現，以幫助您消除耦合到廠商私有服務發現 API 上的風險。
  • Nacos 提供了一些簡單的 DNS APIs TODO 幫助您管理服務的關聯域名和可用的 IP:PORT 列表.

• 服務及其元數據管理

  • Nacos 能讓您從微服務平臺建設的視角管理數據中心的所有服務及元數據，包括管理服務的描述、生命周期、服務的靜態依賴分析、服務的健康狀態、服務的流量管理、路由及安全策略、服務的 SLA 以及最首要的 metrics 統計數據。

1.3 Nacos 地圖

一圖看懂 Nacos，下面架構部分會詳細介紹。

• 特性大圖：要從功能特性，非功能特性，全面介紹我們要解的問題域的特性訴求。
• 架構大圖：通過清晰架構，讓您快速進入 Nacos 世界。
• 業務大圖：利用當前特性可以支持的業務場景，及其最佳實踐。
• 生態大圖：系統梳理 Nacos 和主流技術生態的關系。
• 優勢大圖：展示 Nacos 核心競爭力。
• 戰略大圖：要從戰略到戰術層面講 Nacos 的宏觀優勢。

1.4 Nacos 生態圖

如 Nacos 全景圖所示，Nacos 無縫支持一些主流的開源生態，例如

• Spring Cloud
• Apache Dubbo and Dubbo Mesh
• Kubernetes and CNCF

使用 Nacos 簡化服務發現、配置管理、服務治理及管理的解決方案，讓微服務的發現、管理、共享、組合更加容易。

2.概念

Nacos 引入了一些基本的概念，系統性的了解一下這些概念可以幫助您更好的理解和正確的使用 Nacos 產品。

• 地域：物理的數據中心，資源創建成功后不能更換。

• 可用區：同一地域內，電力和網絡互相獨立的物理區域。同一可用區內，實例的網絡延遲較低。

• 接入點：地域的某個服務的入口域名。

• 命名空間：用于進行租戶粒度的配置隔離。不同的命名空間下，可以存在相同的 Group 或 Data ID 的配置。Namespace 的常用場景之一是不同環境的配置的區分隔離，例如開發測試環境和生產環境的資源（如配置、服務）隔離等。

• 配置：在系統開發過程中，開發者通常會將一些需要變更的參數、變量等從代碼中分離出來獨立管理，以獨立的配置文件的形式存在。目的是讓靜態的系統工件或者交付物（如 WAR，JAR 包等）更好地和實際的物理運行環境進行適配。配置管理一般包含在系統部署的過程中，由系統管理員或者運維人員完成。配置變更是調整系統運行時的行為的有效手段。

• 配置管理：系統配置的編輯、存儲、分發、變更管理、歷史版本管理、變更審計等所有與配置相關的活動。

• 配置項：一個具體的可配置的參數與其值域，通常以 param-key=param-value 的形式存在。例如我們常配置系統的日志輸出級別（logLevel=INFO|WARN|ERROR）就是一個配置項。

• 配置集：一組相關或者不相關的配置項的集合稱為配置集。在系統中，一個配置文件通常就是一個配置集，包含了系統各個方面的配置。例如，一個配置集可能包含了數據源、線程池、日志級別等配置項。

• 配置集 ID：Nacos 中的某個配置集的 ID。配置集 ID 是組織劃分配置的維度之一。Data ID 通常用于組織劃分系統的配置集。一個系統或者應用可以包含多個配置集，每個配置集都可以被一個有意義的名稱標識。Data ID 通常采用類 Java 包（如 com.taobao.tc.refund.log.level）的命名規則保證全局唯一性。此命名規則非強制。

• 配置分組：Nacos 中的一組配置集，是組織配置的維度之一。通過一個有意義的字符串（如 Buy 或 Trade ）對配置集進行分組，從而區分 Data ID 相同的配置集。當您在 Nacos 上創建一個配置時，如果未填寫配置分組的名稱，則配置分組的名稱默認采用 DEFAULT_GROUP。配置分組的常見場景：不同的應用或組件使用了相同的配置類型，如 database_url 配置和 MQ_topic 配置。

• 配置快照：Nacos 的客戶端 SDK 會在本地生成配置的快照。當客戶端無法連接到 Nacos Server 時，可以使用配置快照顯示系統的整體容災能力。配置快照類似于 Git 中的本地 commit，也類似于緩存，會在適當的時機更新，但是并沒有緩存過期（expiration）的概念。

• 服務：通過預定義接口網絡訪問的提供給客戶端的軟件功能。

• 服務名：服務提供的標識，通過該標識可以唯一確定其指代的服務。

• 服務注冊中心：存儲服務實例和服務負載均衡策略的數據庫。

• 服務發現：在計算機網絡上，（通常使用服務名）對服務下的實例的地址和元數據進行探測，并以預先定義的接口提供給客戶端進行查詢。

• 元信息：Nacos 數據（如配置和服務）描述信息，如服務版本、權重、容災策略、負載均衡策略、鑒權配置、各種自定義標簽（label），從作用范圍來看，分為服務級別的元信息、集群的元信息及實例的元信息。

• 應用：用于標識服務提供方的服務的屬性。

• 服務分組：不同的服務可以歸類到同一分組。

• 虛擬集群：同一個服務下的所有服務實例組成一個默認集群, 集群可以被進一步按需求劃分，劃分的單位可以是虛擬集群。

• 實例：提供一個或多個服務的具有可訪問網絡地址（IP:Port）的進程。

• 權重：實例級別的配置。權重為浮點數。權重越大，分配給該實例的流量越大。

• 健康檢查：以指定方式檢查服務下掛載的實例（Instance）的健康度，從而確認該實例是否能提供服務。根據檢查結果，實例會被判斷為健康或不健康。對服務發起解析請求時，不健康的實例不會返回給客戶端。

• 健康保護閾值：為了防止因過多實例不健康導致流量全部流向健康實例，繼而造成流量壓力把健康實例壓垮并形成雪崩效應，應將健康保護閾值定義為一個 0 到 1 之間的浮點數。當域名健康實例數占總服務實例數的比例小于該值時，無論實例是否健康，都會將這個實例返回給客戶端。這樣做雖然損失了一部分流量，但是保證了集群中剩余健康實例能正常工作。

3.架構

3.1 基本架構及概念

• 服務（Service）：服務是指一個或一組軟件功能（例如特定信息的檢索或一組操作的執行），其目的是不同的客戶端可以為不同的目的重用（例如通過跨進程的網絡調用）。Nacos 支持主流的服務生態，如 Kubernetes Service、gRPC|Dubbo RPC Service 或者 Spring Cloud RESTful Service。

• 服務注冊中心（Service Registry）：服務注冊中心，它是服務，其實例及元數據的數據庫。服務實例在啟動時注冊到服務注冊表，并在關閉時注銷。服務和路由器的客戶端查詢服務注冊表以查找服務的可用實例。服務注冊中心可能會調用服務實例的健康檢查 API 來驗證它是否能夠處理請求。

• 服務元數據（Service Metadata）：服務元數據是指包括服務端點（endpoints）、服務標簽、服務版本號、服務實例權重、路由規則、安全策略等描述服務的數據。

• 服務提供方（Service Provider）：是指提供可復用和可調用服務的應用方。

• 服務消費方（Service Consumer）：是指會發起對某個服務調用的應用方。

• 配置（Configuration）：在系統開發過程中通常會將一些需要變更的參數、變量等從代碼中分離出來獨立管理，以獨立的配置文件的形式存在。目的是讓靜態的系統工件或者交付物（如 WAR，JAR 包等）更好地和實際的物理運行環境進行適配。配置管理一般包含在系統部署的過程中，由系統管理員或者運維人員完成這個步驟。配置變更是調整系統運行時的行為的有效手段之一。

• 配置管理（Configuration Management）：在數據中心中，系統中所有配置的編輯、存儲、分發、變更管理、歷史版本管理、變更審計等所有與配置相關的活動統稱為配置管理。

• 名字服務（Naming Service）：提供分布式系統中所有對象（Object）、實體（Entity）的 “名字” 到關聯的元數據之間的映射管理服務，例如 ServiceName -> Endpoints Info，Distributed Lock Name -> Lock Owner/Status Info，DNS Domain Name -> IP List，服務發現和 DNS 就是名字服務的 $2$ 大場景。

• 配置服務（Configuration Service）：在服務或者應用運行過程中，提供動態配置或者元數據以及配置管理的服務提供者。

3.2 邏輯架構及其組件介紹

• 服務管理：實現服務 CRUD，域名 CRUD，服務健康狀態檢查，服務權重管理等功能。
• 配置管理：實現配置管 CRUD，版本管理，灰度管理，監聽管理，推送軌跡，聚合數據等功能。
• 元數據管理：提供元數據 CURD 和打標能力。
• 插件機制：實現三個模塊可分可合能力，實現擴展點 SPI 機制。
• 事件機制：實現異步化事件通知，sdk 數據變化異步通知等邏輯。
• 日志模塊：管理日志分類，日志級別，日志可移植性（尤其避免沖突），日志格式，異常碼+幫助文檔。
• 回調機制：sdk 通知數據，通過統一的模式回調用戶處理。接口和數據結構需要具備可擴展性。
• 尋址模式：解決 ip，域名，nameserver、廣播等多種尋址模式，需要可擴展。
• 推送通道：解決 server 與存儲、server 間、server 與 sdk 間推送性能問題。
• 容量管理：管理每個租戶，分組下的容量，防止存儲被寫爆，影響服務可用性。
• 流量管理：按照租戶，分組等多個維度對請求頻率，長鏈接個數，報文大小，請求流控進行控制。
• 緩存機制：容災目錄，本地緩存，server 緩存機制。容災目錄使用需要工具。
• 啟動模式：按照單機模式，配置模式，服務模式，dns 模式，或者 all 模式，啟動不同的程序+UI。
• 一致性協議：解決不同數據，不同一致性要求情況下，不同一致性機制。
• 存儲模塊：解決數據持久化、非持久化存儲，解決數據分片問題。
• Nameserver：解決 namespace 到 clusterid 的路由問題，解決用戶環境與nacos物理環境映射問題。
• CMDB：解決元數據存儲，與三方 cmdb 系統對接問題，解決應用，人，資源關系。
• Metrics：暴露標準 metrics 數據，方便與三方監控系統打通。
• Trace：暴露標準 trace，方便與 SLA 系統打通，日志白平化，推送軌跡等能力，并且可以和計量計費系統打通。
• 接入管理：相當于阿里云開通服務，分配身份、容量、權限過程。
• 用戶管理：解決用戶管理，登錄，sso 等問題。
• 權限管理：解決身份識別，訪問控制，角色管理等問題。
• 審計系統：擴展接口方便與不同公司審計系統打通。
• 通知系統：核心數據變更，或者操作，方便通過 SMS 系統打通，通知到對應人數據變更。
• OpenAPI：暴露標準 Rest 風格 HTTP 接口，簡單易用，方便多語言集成。
• Console：易用控制臺，做服務管理、配置管理等操作。
• SDK：多語言 sdk。
• Agent：dns-f 類似模式，或者與 mesh 等方案集成。
• CLI：命令行對產品進行輕量化管理，像 git 一樣好用。

3.3 領域模型

（1）數據模型

Nacos 數據模型 Key 由三元組唯一確定，Namespace 默認是空串，公共命名空間（public），分組默認是 DEFAULT_GROUP。

（2）服務領域模型

（3）配置領域模型

圍繞配置，主要有兩個關聯的實體，一個是配置變更歷史，一個是服務標簽（用于打標分類，方便索引），由 ID 關聯。

（4）類視圖

Nacos-SDK 類視圖（服務部分待續）

3.4 構建物、部署及啟動模式

• 兩種交付工件：Nacos 支持標準 Docker 鏡像（TODO: $0.2$ 版本開始支持）及 zip（tar.gz）壓縮包的構建物。

• 兩種啟動模式：Nacos 支持將注冊中心（Service Registry）與配置中心（Config Center）在一個進程合并部署或者將2者分離部署的兩種模式。

• 免費的公有云服務模式：除了您自己部署和啟動 Nacos 服務之外，在云計算時代，Nacos 也支持公有云模式，在阿里云公有云的商業產品（如 ACM，EDAS）中會提供 Nacos 的免費的公有云服務。我們也歡迎和支持其他的公有云提供商提供 Nacos 的公有云服務。