本文系投稿，作者：廖春濤（春少）
https://www.yuque.com/docs/share/17664885-e0d8-40fd-a208-f1b58794d544
經過一年多發展，1.2.0版本已經從安全上解決上生産的最後疑慮，解決使用者主要訴求。
經過社群讨論，從1.3.0版本開始修煉内功，聚焦“簡單”、“性能”、“高可用”這核心的三個點進一步提升Nacos核心競争力。今天很高興能代表社群向大家介紹1.3.0的核心特性
- 内嵌關系型分布式資料庫，簡化叢集部署模式
- 叢集管理下沉統一，提供全新叢集管理能力
- 一緻性協定抽象更新，提供更高的性能
- 安全更新，解決Fastjson和越權風險
下面我們逐個介紹一下這些能力
輕量級的内嵌關系型分布式資料庫
為什麼隻是用服務發現子產品也要我部署MySQL？MySQL叢集搭建的成本有多高？不能把叢集部署簡單一點，像Consul、Etcd那樣子？
這不，為了解決這個問題，Nacos 1.3.0 借鑒了 Etcd 的通過Raft協定将單機KV存儲轉變為分布式的KV存儲的設計思想，基于SOFA-JRaft以及Apache Derby建構了一個輕量級的分布式關系型資料庫，同時保留了使用外置資料源的能力，使用者可以根據自己的實際業務情況選擇其中一種資料存儲方案。
從Nacos 1.3.0版本開始叢集部署可以不依賴MySQL的這個特性，不僅降低中小使用者的叢集運維部署成本，也簡化了其叢集部署的操作以及省去了部署一套資料庫叢集的操作。
新特性的開啟指令為
./startup.sh -p embedded
然後檢視啟動日志是否有出現以下資訊：Nacos started successfully in cluster mode. use embedded storage
同時，為了友善使用者查詢本機節點的資料同步情況，Nacos 1.3.0 配置子產品開放了新的運維 Open-API，供其查詢目前節點本地資料存儲情況，并且該Open-API隻能執行select語句，其他DML語句一概不支援，其使用方式如下
GET /nacos/v1/cs/ops/derby?sql=select * from config_info
使用該指令時，最好加上分頁查詢，避免一次查處大量的資料影響Nacos的正常對外業務工作，如果沒有加上分頁查詢，則會自動添加分頁查詢語句，預設查詢最開始的1k條資料。其分頁查詢的SQL的例子如下。
select * from config_info OFFSET 0 ROWS FETCH NEXT 1000 ROWS ONLY
其資料傳回結果如下
{ "code":200, "message":null, "data":\\\[ { "ID":242149783664332800, "DATA\\\_ID":"application.properties", "GROUP\\\_ID":"DEFAULT\\\_GROUP", "TENANT\\\_ID":"", "APP\\\_NAME":"", "CONTENT":"this.is.test=liaochuntao", "MD5":"bedbfd7069e999edf2adf9d8a1af3083", "GMT\\\_CREATE":"2020-06-03T05:30:47.345+0000", "GMT\\\_MODIFIED":"2020-06-03T05:30:47.345+0000", "SRC\\\_USER":null, "SRC\\\_IP":"127.0.0.1", "C\\\_DESC":null, "C\\\_USE":null, "EFFECT":null, "TYPE":"properties", "C\\\_SCHEMA":null } \\\]}
Nacos 1.3.0 建構的輕量級的分布式關系型存儲，其已滿足事務ACID性質。後面我們會在這基礎之上進一步優化該存儲的性能。
注意事項
分布式ID——Snowflake
Nacos 1.3.0的分布式存儲，其資料的主鍵依賴雪花ID算法進行生成，雪花算法ID需要_DataCenterId_、_WorkerId，預設情況下，WorkerId不需要進行設定，會根據InetAddress.getLocalHost()進行計算生成。如果需要自己指定，則在application.properties進行如下配置設定
# set the dataCenterID manuallynacos.core.snowflake.data-center=Number### set the WorkerID manuallynacos.core.snowflake.worker-id=Number
資料遷移
由于Nacos 1.3.0新增的内嵌存儲模式是全新的資料存儲模式，是以在進行Nacos-Server更新時，如果是需要使用這種新能力，需要另外部署一個Nacos 1.3.0叢集，然後進行資料遷移，由于Nacos 1.3.0 新增的内嵌存儲模式，還無法自動的将原本MySQL的資料直接一鍵進行資料遷移，是以使用者隻能使用控制台的資料導出導入的方式進行（會丢失配置曆史資料），更加完備的資料遷移功能會在後面的版本進行開放。
全新的叢集管理
提供全新叢集管理頁面
Nacos 1.3.0版本開始，對叢集節點管理進行了統一，将原有配置子產品以及服務子產品的叢集節點管理統一下沉到核心子產品，并且優化了叢集節點資訊展示，使得其更貼近Nacos叢集節點的資料資訊展示，其顯示的内容包括如下幾個方面
- 服務發現子產品舊的Raft協定的中繼資料資料
- 配置管理子產品使用新Raft協定的中繼資料
- Nacos節點自身的中繼資料資訊
- 新Raft協定的RPC端口
- 節點的版本資訊
- 節點的權重資訊（該權重的功能暫未提供，以後服務端節點的負載均衡使用）
- 節點中繼資料資訊上次重新整理時間
新的叢集尋址模式設定
Nacos 1.3.0版本開始，對叢集節點的尋址模式做了統一，将原本分散的節點尋址模式整合并抽象，友善将來可以擴寬Nacos的叢集發現機制，使用者可以通過如下設定自己選擇需要使用哪一種尋址模式作為叢集節點的管理
檔案尋址模式
nacos.core.member.lookup.type=file（預設值）
位址服務尋址模式
nacos.core.member.lookup.type=address-server
全新的一緻性協定
Nacos 1.3.0版本開始，将對現有的一緻性協定層進行統一抽象以及下沉。在Raft的選型上，使用了SOFA-JRaf作為CP協定的Backend，并且将其與配置管理子產品進行了對接。使用者可以通過調整下面的參數對Raft協定進行調整。
# Sets the Raft cluster election timeout, default value is 5 second# 設定Raft群集選舉逾時，預設值為5秒nacos.core.protocol.raft.data.election\\\_timeout\\\_ms=5000# Sets the amount of time the Raft snapshot will execute periodically, default is 30 minute# 設定Raft快照定期執行的時間，預設值為30分鐘nacos.core.protocol.raft.data.snapshot\\\_interval\\\_secs=30# Raft internal worker threads# Raft 内部工作線程數量nacos.core.protocol.raft.data.core\\\_thread\\\_num=8# Number of threads required for raft business request processing# Raft 業務請求處理所需的線程數nacos.core.protocol.raft.data.cli\\\_service\\\_thread\\\_num=4# raft 線性讀取政策，預設為ReadOnlySafe，可以選擇ReadOnlyLeaseBasednacos.core.protocol.raft.data.read\\\_index\\\_type=ReadOnlySafe### rpc請求逾時，預設5秒nacos.core.protocol.raft.data.rpc\\\_request\\\_timeout\\\_ms=5000
線性讀參數解析
- ReadOnlySafe
- 該線性讀模式，每次Follower進行讀請求時，需要和Leader同步日志送出位點資訊，而Leader，需要向過半的Follower發起證明自己是Leader的輕量的RPC請求，相當于一個Follower讀，至少需要1 + （n/2）+ 1 次的RPC請求。
- ReadOnlyLeaseBased
- 該線性讀模式，每次Follower進行讀請求時，Leader隻需要判斷自己的Leader租約是否過期了，如果沒有過期，直接可以回複Follower自己是Leader，但是該機制對于機器時鐘要求很嚴格，如果有做時鐘同步的話，可以考慮使用該線性讀模式。
如果說對于配置的釋出、修改操作比較頻繁，可以将Raft快照的時間适當的進行調整，避免新節點加入或者節點重新開機時，由于Raft日志回放操作數太多導緻節點可開始對外服務的時間過長。
JRaft
同時，為了友善運維對新的Raft協定能夠進行一些簡單的運維操作，Nacos 1.3.0 核心子產品開放了相關一緻性協定運維的 Open-API，供其對Raft進行一些運維操作，其相關的運維操作如下
切換某一個Raft Group的Leader節點
POST /nacos/v1/core/ops/raft{ "groupId": "xxx", "command": "transferLeader" "value": "ip:{raft\\\_port} or ip:{raft\\\_port},ip:{raft\\\_port},ip:{raft\\\_port}"}
重置某一個Raft Group的叢集成員
POST /nacos/v1/core/ops/raft{ "groupId": "xxx", "command": "resetRaftCluster", "value": "ip:{raft\\\_port},ip:{raft\\\_port},ip:{raft\\\_port},ip:{raft\\\_port}"}
注意，該操作是一個高危操作，僅僅當Raft叢集的 n/2 + 1節點crash之後無法滿足過半投票的要求才可以使用該運維指令，用于快速讓目前剩餘的節點重組Raft叢集，對外提供服務，但是這個操作很大程度會造成資料的丢失
觸發某一個Raft Group執行快照操作
POST /nacos/v1/core/ops/raft{ "groupId": "xxx", "command": "doSnapshot", "value": "ip:{raft_port}"}
移除某一個Raft Group中的某一成員
POST /nacos/v1/core/ops/raft{ "groupId": "xxx", "command": "removePeer", "value": "ip:{raft_port}"}
批量移除某一個Raft Group中的多個成員
POST /nacos/v1/core/ops/raft{ "groupId": "xxx", "command": "removePeers", "value": "ip:{raft\\\_port},ip:{raft\\\_port},ip:{raft_port},..."}
後續
目前一緻性協定層隻是将CP協定具體實作了，後面會再将AP協定——Distro下沉到一緻性協定層中，并且調整Distro的實作，其協定内部的通信将使用gRPC，以配合Nacos對于整個通信通道的規劃。同時真正實作對整個一緻性協定使用方式的收攏。
安全更新
- 修複fastjson安全漏洞
- 修複tenant越權漏洞
貢獻者
Nacos 1.3.0 版本的開發中，社群同學貢獻了很大的力量，在此表示感謝，他們是（排序不分先後）：@KomachiSion @zongtanghu @wangweizZZ @Maijh97 @jintonghuoya @jzdayz @yfh0918@wolfgangzhu @ObserverYu @langghaha @jiangcaijun @wfnuser @TsingLiang @showkawa @yanlinly @chuntaojun
關注公衆号Java技術棧回複"面試"擷取我整理的2020最全面試題及答案。
推薦去我的部落格閱讀更多：
1.Java JVM、集合、多線程、新特性系列教程
2.Spring MVC、Spring Boot、Spring Cloud 系列教程