今天開始進入nacos的學習。
nacos是spring-cloud-alibaba下的一個元件，緻力于配置中心和注冊中心。服務（Service）是Nacos世界的一等公民。
既然知道了nacos的作用，那麼我們需要學習哪方面的内容呢？大概整理了一下，後面的學習過程也是按照這些内容一步步進行。
- 作為配置中心如何實作配置資料的遠端管理； 當配置發生變更時如何同步到應用服務。–這部分是spring-cloud-alibaba内容。
- 作為注冊中心，需要實作注冊中心相關功能
- provider端如何以nacos作為注冊中心進行服務注冊–以dubbo為例
- consumer端如何以nacos作為注冊中心進行服務發現–以dubbo為例
- nacos服務端的高可用實作。–raft協定實作。
本系列nacos源碼使用1.4.0版本。 中間可能會涉及到spring-cloud-alibaba 相關源碼，使用的版本是2.2.3.RELEASE。
首先介紹幾個相關概念：
命名空間
用于進行租戶粒度的配置隔離。不同的命名空間下，可以存在相同的 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) 的健康度，進而确認該執行個體 (Instance) 是否能提供服務。根據檢查結果，執行個體 (Instance) 會被判斷為健康或不健康。對服務發起解析請求時，不健康的執行個體 (Instance) 不會傳回給用戶端。
健康保護門檻值
為了防止因過多執行個體 (Instance) 不健康導緻流量全部流向健康執行個體 (Instance) ，繼而造成流量壓力把健康 健康執行個體 (Instance) 壓垮并形成雪崩效應，應将健康保護門檻值定義為一個 0 到 1 之間的浮點數。當域名健康執行個體 (Instance) 占總服務執行個體 (Instance) 的比例小于該值時，無論執行個體 (Instance) 是否健康，都會将這個執行個體 (Instance) 傳回給用戶端。這樣做雖然損失了一部分流量，但是保證了叢集的剩餘健康執行個體 (Instance) 能正常工作。
這些概念在學習源碼的過程中會遇到，是以要先了解清楚，這樣可以更好的了解代碼的實作。
源碼子產品結構：
各子產品的關系：
本篇就先到這裡，總結一下：
- nacos的分析學習要做哪些事情
- nacos的一部分概念說明
- nacos各子產品，以及子產品依賴