前言
NacosAP模式原始碼分析目錄
Nacos原始碼結構介紹
Nacos版本基於1.4.0版本，整體的專案結構如下：
看到目錄，第一眼的感覺就是職責分明，給人的感覺就是高手，關於原始碼部分我也沒全看完，目前只是註冊中心相關看完了，配置中心的就是略微看了一下，我先給大家介紹下重點的模組的作用的，到時候大家再結合上面幾篇文章去理解原始碼:
- address模組: 主要查詢nacos叢集中節點個數以及IP的列表;
- api模組: 主要給客戶端呼叫的api介面的抽象;
- client模組: 主要是對依賴api模組和common模組,對api的介面的實現,給nacos的客戶端使用;
- cmdb模組: 主要是操作的資料的儲存在記憶體中,該模組提供一個查詢資料標籤的介面;
- config模組: 主要是服務配置的管理, 提供api給客戶端拉去配置資訊,以及提供更新配置 的,客戶端通過長輪詢的更新配置資訊.資料儲存是Mysql;
- naming模組: 主要是作為服務註冊中心的實現模組,具備服務的註冊和服務發現的功能;
- console模組: 主要是實現與前端進行互動.具有許可權校驗、服務狀態、健康檢查等功能;
- core模組: 主要初始化屬性載入，監聽器相關內容，用於載入nacos的default的配置資訊，config和naming都依賴於這個包；
我覺得上面8個模組相對來說是比較重要，對於大家研究Nacos原始碼是必須要掌握的，關係間的依賴如下:
模組之間的呼叫關係如下:
看到呼叫關係就可以感覺出來，整體上原始碼不算太難，耐心看看還是可以看懂的。
Nacos AP模式原始碼核心部分介紹
服務註冊
Nacos Client通過/nacos/v1/ns/instance介面將服務資訊(包括服務的名稱、IP、埠、狀態等資訊)註冊到Nacos Server的登錄檔中，存放於類ServiceManager的內部物件Map<String, Map<String, Service>> serviceMap，這是一個兩層Map的巢狀結構，第一層的Key是Namesapce名稱，第二層的Key是Group名稱和Service名稱的組合，第二層的Value是Service的物件。
服務心跳
使用者服務和訂單服務註冊後，每個客戶端會通過定時任務來維持一個定時心跳來持續通知Nacos Server，預設 5s傳送一次心跳;
服務健康檢查
Nacos Server通過定時任務檢查註冊服務例項的健康狀況，對於超過15s沒有收到客戶端心跳的例項會將它的 healthy屬性置為false(客戶端服務發現時不會發現)，如果某個例項超過30秒沒有收到心跳，直接剔除該例項(被剔除的例項如果恢復傳送 心跳則會重新註冊);
服務同步
服務同步我覺得主要分為兩方面同步，一是Nacos Server叢集之間的同步，會過/nacos/v1/ns/instance/distro/datum互相同步服務例項的資訊，二是服務的消費者同步變更新到客戶端,服務消費者(Nacos Client)會接收服務端的UDP推送過來的服務變更資訊(檢測到不正常的服務的時候服務發生變更)，及時更新到本地快取中，這是Nacos的亮點和其他註冊中心不一樣的地方，面試的時候可以和麵試官聊，會讓面試官眼前一亮的，因為UDP本身是不可靠的，不能保證所有的變更資訊都可以同步到客戶端，所以消費者還有一個定時任務的兜底機制;
談談收穫
看完這部分原始碼收穫我覺得主要有兩方面的收穫:
技術方面
技術方面的收穫的是最多的，這裡簡單聊幾個例子:
- 從整體的框架的設計，還是到模組中類實現的設計，單一原則體現的淋淋盡致，下圖是整體框架設計，體現到程式碼上就是每個模組職責很清晰，依賴關係很明確，另外框架層面的做的外掛化的思想、高可用的思想，都是我們可以借鑑學習的;
- 很多技術細節的實現很精妙，比如服務變更時候的非同步佇列的設計、CopyOnWrite的思想、Spring事件機制的應用等等，這些都在我的部落格中原始碼分析的細節中講到,大家可以稍微花一些功夫看看;
寫作方面
這部分其實還沒形成一個完整的思想，只是初步的一個思考，關於這種原始碼分析的，以後會採用以下方式:
- 框架選型的思考, 分析類似中介軟體對比；
- 框架搭建和使用介紹;
- 原始碼程式碼模組介紹和框架模組功能性的描述，類似就是做一個整體功能介紹;
- 每個模組功能原始碼的分析，附帶時序圖和類圖關係，後面我會對Nacos系列的文章的內容進行一個改造;
- 完成每個模組的介紹以後會統一做程式碼的整體關鍵步驟的原始碼分析圖和總結；
結束
歡迎大家點點關注，點點贊!
