從個人觀點(diǎn)來講项棠，要學(xué)習(xí)一款產(chǎn)品悲雳，先要了解這個產(chǎn)品能干什么，然后嘗試去使用它香追，接著在深入分析合瓢；建議先使用下在看相關(guān)原理；目前我們使用到的就兩個功能(也是公司目前在用的)透典，一個是配置中心晴楔，一個是注冊中心。

來自于官網(wǎng)概念：Nacos 致力于幫助您發(fā)現(xiàn)峭咒、配置和管理微服務(wù)税弃。Nacos 提供了一組簡單易用的特性集，幫助您快速實現(xiàn)動態(tài)服務(wù)發(fā)現(xiàn)凑队、服務(wù)配置则果、服務(wù)元數(shù)據(jù)及流量管理

1.官網(wǎng)的基礎(chǔ)架構(gòu)圖

nacos.jpeg

其實看上面的圖感覺不太強(qiáng)烈，基本上就是服務(wù)端通過OpenAPI對外提供接口調(diào)用顽决，內(nèi)部有CofigService,NamingService連個服務(wù)短条，底層有核心Core作為基礎(chǔ)設(shè)施構(gòu)建等；控制臺有基于用戶才菠，管理員還有定制化的的界面可以使用，看起來也是相對簡單

2.源碼結(jié)構(gòu)

nacos1.1.3-code-source.png

這是從官網(wǎng)下載的源碼贡定，版本是1.1.3赋访，圖中我標(biāo)示了一些比較重要的模塊，也是我后續(xù)源碼分析的主要模塊：

2.1 配置中心總體配置情況

一般我們做配置中心會考慮到如下情況：

1.服務(wù)器端的配置保存（持久化）
??????數(shù)據(jù)庫/文件。蚓耽。渠牲。
2.服務(wù)器端提供訪問api
??????rpc、http（openapi）
3.數(shù)據(jù)變化之后如何通知到客戶端
?????zookeeper（session manager）
?????push（服務(wù)端主動推送到客戶端）步悠、pull(客戶端主動拉去數(shù)據(jù)）? -> 長輪訓(xùn)( pull數(shù)據(jù)量很大會怎么辦)
4.客戶端如何去獲得遠(yuǎn)程服務(wù)的數(shù)據(jù)（）
5.安全性（）
6.刷盤（本地緩存）->

而我們的nacos的配置中心的處理方式有：

1.服務(wù)端采用derby/mysql做配置中心持久化签杈，對于非單機(jī)或者在使用mysql情況下會在本地磁盤還會緩存一個文件，在這種情況下客戶端獲取配置信息也是直接讀取該磁盤文件鼎兽；集群使用mysql做配置持久化

2.服務(wù)器配置中心數(shù)據(jù)更改
nacos采用pull和'push結(jié)合方式獲取配置信息答姥，采用長連接方式（超時）獲取數(shù)據(jù)；

2.1客戶端長輪詢:
???? 服務(wù)器如果配置數(shù)據(jù)沒有更改會hang住這個請求29.5s;如果期間數(shù)據(jù)發(fā)生變化會直接返回數(shù)據(jù)谚咬，并觸發(fā)客戶端的監(jiān)聽邏輯(長輪訓(xùn)的條件也只是客戶端有監(jiān)聽器的時候才會有長輪訓(xùn))

2.2服務(wù)器端處理邏輯
???? 1）數(shù)據(jù)發(fā)送時鹦付，先保存持久化的mysql數(shù)據(jù)，然后通過觸發(fā)ConfigDataChangeEvent事件- 廣播信息給所有其他節(jié)點(diǎn)有數(shù)據(jù)變化
???? 2）服務(wù)器拿到數(shù)據(jù)后會更新每一個服務(wù)器的本地日志緩存择卦，以及內(nèi)存中每一個dataId對應(yīng)的md5值敲长；最后還會觸發(fā)LocalDataChangeEvent事件，通過hang住的客戶端請求返回數(shù)據(jù)

3.服務(wù)端的api都是基于RESTFUL請求的

4.客戶端可以通過開啟本地緩存在本地文件做緩存

5.集群情況下服務(wù)端全量將數(shù)據(jù)庫文件dump到本地

集群一致性問題：
?????nacos配置中心使用去中心化思想做的秉继，沒有主從節(jié)點(diǎn)概念祈噪，配置變化更新mysql數(shù)據(jù)庫，然后廣播給所有節(jié)點(diǎn)以及客戶端尚辑；如果某個節(jié)點(diǎn)出現(xiàn)某種情況更新失敗钳降，服務(wù)端也有策略，會在6h執(zhí)行一次數(shù)據(jù)庫全量更新服務(wù)器本地磁盤文件

2.2 服務(wù)發(fā)現(xiàn)

服務(wù)發(fā)現(xiàn)相比配置中心稍微復(fù)雜一點(diǎn)腌巾，分析了部分功能遂填。

客戶端

客戶端注冊實例后還會通過定時器檢查實例是否失敗，保證自己的實例注冊到服務(wù)上

客戶端故障轉(zhuǎn)移會定時將本地緩存的服務(wù)實例做磁盤緩存

客戶端通過udp監(jiān)聽遠(yuǎn)端服務(wù)實例變化

服務(wù)節(jié)點(diǎn)數(shù)據(jù)同步

非持久（默認(rèn)）處理-AP

服務(wù)端一致性：數(shù)據(jù)更新后先緩存在本地內(nèi)存中澈蝙，然后遍歷發(fā)給給其他節(jié)點(diǎn)吓坚，不分是否是主從發(fā)送數(shù)據(jù)

節(jié)點(diǎn)采用分片處理，每一個節(jié)點(diǎn)存儲的部分?jǐn)?shù)據(jù)都有定時心跳做數(shù)據(jù)同步

推送客戶端：通過udp推送給客戶端數(shù)據(jù)更新

持久化處理-CP

服務(wù)端一致性：Raft實現(xiàn)灯荧；轉(zhuǎn)發(fā)給leader 緩存在內(nèi)存中礁击，存儲進(jìn)磁盤，待超過一半follower處理成功返回成功逗载。

服務(wù)采用leader發(fā)送心跳包給follower節(jié)點(diǎn)做數(shù)據(jù)同步

推送客戶端：通過udp推送給客戶端數(shù)據(jù)更新

2.3 集群

nacos的集群選舉算法是自己實現(xiàn)的Raft算法哆窿，主要是對于naming服務(wù)，動態(tài)配置服務(wù)是沒有用到這個raft集群心跳和數(shù)據(jù)更新的功能的厉斟；

功能點(diǎn)主要有三點(diǎn)：

leader選舉：使用Raft的leaderdue時間挚躯，到期后發(fā)起選舉，投票過半為leader
心跳：leader定時發(fā)送心跳給follower擦秽，心跳還可能打包datum(可以關(guān)閉)信息給follower節(jié)點(diǎn)码荔；follower節(jié)點(diǎn)收到心跳重置選舉leaderdue避免發(fā)生選舉漩勤，并且如果發(fā)現(xiàn)datum數(shù)據(jù)有變化會更新內(nèi)存和本地文件緩存，數(shù)據(jù)變化term會增加100缩搅，會刪除dead的datum
數(shù)據(jù)更新：每次數(shù)據(jù)更新的時候越败，如果請求發(fā)送到follower節(jié)點(diǎn)會轉(zhuǎn)發(fā)給leader處理數(shù)據(jù)，由leader先更新本地數(shù)據(jù)硼瓣，然后分別異步發(fā)送給其他follower究飞，如果超過半數(shù)的follower更新成功那么數(shù)據(jù)就更新成功了。

注：
????1）datum指的的對于注冊的服務(wù)和實例抽象包裝
???? 2）term類似于zookeeper的zxid堂鲤；term投票時會添加1亿傅，數(shù)據(jù)更新會增加100；zk的是分為前 32位和后32位分別累計選舉年代和數(shù)據(jù)更新遞增筑累，這里不贅述袱蜡。

參考官網(wǎng)：https://nacos.io

Nacos整體概況