前言
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系列的文章的內容進行一個改造;
- 完成每個模塊的介紹以后會統一做代碼的整體關鍵步驟的源碼分析圖和總結；
結束
歡迎大家點點關注，點點贊!
