nacos 簡介
在 nacos-0.3 的時候我就開始關注，期間還寫過一篇作爲 Spring Cloud 配置中心的使用記錄的博客。在前不久，nacos 終於出了正式版，趕個時髦出篇博客吹一波。
nacos 特性
服務發現和服務健康監測
支持基於 DNS 和基於 RPC 的服務發現（可替代 eureka ）。Nacos 提供對服務的實時的健康檢查，阻止向不健康的主機或服務實例發送請求。Nacos 支持傳輸層 ( PING 或 TCP )和應用層 (如 HTTP、MySQL、用戶自定義）的健康檢查。 對於複雜的雲環境和網絡拓撲環境中（如 VPC、邊緣網絡等）服務的健康檢查，Nacos 提供了 agent 上報模式和服務端主動檢測2種健康檢查模式。Nacos 還提供了統一的健康檢查儀表盤，幫助開發者根據健康狀態管理服務的可用性及流量。
動態配置服務
動態配置服務可以讓開發者以中心化、外部化和動態化的方式管理所有環境的應用配置和服務配置（可以作爲配置中心）。動態配置消除了配置變更時重新部署應用和服務的需要，讓配置管理變得更加高效和敏捷。配置中心化管理讓實現無狀態服務變得更簡單，讓服務按需彈性擴展變得更容易。Nacos 提供了一個簡潔易用的 UI 幫助開發者管理所有的服務和應用的配置。Nacos 還提供包括配置版本跟蹤、金絲雀發佈、一鍵回滾配置以及客戶端配置更新狀態跟蹤在內的一系列開箱即用的配置管理特性，幫助開發者更安全地在生產環境中管理配置變更和降低配置變更帶來的風險。
動態 DNS 服務
動態 DNS 服務支持權重路由，讓開發者更容易地實現中間層負載均衡、更靈活的路由策略、流量控制以及數據中心內網的簡單DNS解析服務（可做負載均衡）。動態DNS服務還能讓開發者更容易地實現以 DNS 協議爲基礎的服務發現，以幫助開發者消除耦合到廠商私有服務發現 API 上的風險。
服務及其元數據管理
Nacos 能讓開發者從微服務平臺建設的視角管理數據中心的所有服務及元數據，包括管理服務的描述、生命週期、服務的靜態依賴分析、服務的健康狀態、服務的流量管理、路由及安全策略、服務的 SLA 以及最首要的 metrics 統計數據。
nacos的相關概念
•地域 （Region）：物理的數據中心，資源創建成功後不能更換。•可用區（Available Zone）：同一地域內，電力和網絡互相獨立的物理區域。同一可用區內，實例的網絡延遲較低。•接入點（Endpoint）：地域的某個服務的入口域名。•命名空間（Namespace）：用於進行租戶粒度的配置隔離。不同的命名空間下，可以存在相同的 Group 或 Data ID 的配置。Namespace 的常用場景之一是不同環境的配置的區分隔離，例如開發測試環境和生產環境的資源（如配置、服務）隔離等。•元信息(Metadata)：Nacos 數據（如配置和服務）描述信息，如服務版本、權重、容災策略、負載均衡策略、鑑權配置、各種自定義標籤 (label)，從作用範圍來看，分爲服務級別的元信息、集羣的元信息及實例的元信息。•實例（Instance）：提供一個或多個服務的具有可訪問網絡地址（IP:Port）的進程。•權重（Weight）：實例級別的配置。權重爲浮點數。權重越大，分配給該實例的流量越大。•健康檢測（Health Check）：以指定方式檢查服務下掛載的實例 (Instance) 的健康度，從而確認該實例 (Instance) 是否能提供服務。根據檢查結果，實例 (Instance) 會被判斷爲健康或不健康。對服務發起解析請求時，不健康的實例 (Instance) 不會返回給客戶端。•健康保護閾值（Protect Threshold）：爲了防止因過多實例 (Instance) 不健康導致流量全部流向健康實例 (Instance) ，繼而造成流量壓力把健康 健康實例 (Instance) 壓垮並形成雪崩效應，應將健康保護閾值定義爲一個 0 到 1 之間的浮點數。當域名健康實例 (Instance) 佔總服務實例 (Instance) 的比例小於該值時，無論實例 (Instance) 是否健康，都會將這個實例 (Instance) 返回給客戶端。這樣做雖然損失了一部分流量，但是保證了集羣的剩餘健康實例 (Instance) 能正常工作。•服務分組（Service Group）：不同的服務可以歸類到同一分組。•虛擬集羣（Virtual Cluster）：同一個服務下的所有服務實例組成一個默認集羣, 集羣可以被進一步按需求劃分，劃分的單位可以是虛擬集羣。
nacos 使用
安裝
可在 GitHub 上下載安裝包安裝，或者採用 docker 安裝。
Windows 上運行：
在 GitHub 查看該項目的 releases 並下載最新版，解壓後進入 bin 目錄 運行 startup.cmd 。
docker 上運行：
docker run --name nacos-standalone -e MODE=standalone -p 8848:8848 nacos/nacos-server:latest 可運行一個單機版nacos
瀏覽器上訪問 ip:8848/nacos 進入登陸界面，用戶名和密碼都是 nacos；登陸成功就能看到控制檯 UI 界面了。在安裝包的 ./conf 目錄下有一個 application.properties 文件，這是 nacos 的配置文件。
作爲配置中心
示例
這裏爲方便講解，我們現在 Windows 環境下運行一個單機版 nacos ，啓動後登陸，創建一個 SpringBoot 應用，導入依賴
<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-alibaba-nacos-config</artifactId><version>0.9.0.RELEASE</version></dependency>
然後刪除 application.properties 新建一個 bootstrap.properties 。這裏可能還有同學不知道 application 和 bootstrap 的區別，在這裏科普一下：在 Spring Boot 中有兩種上下文，一種是 bootstrap , 另外一種是 application , bootstrap 是應用程序的父上下文，也就是說 bootstrap 加載優先於 application 。bootstrap 主要用於從額外的資源來加載配置信息，還可以在本地外部配置文件中解密屬性。這兩個上下文共用一個環境，它是任何 Spring 應用程序的外部屬性的來源。bootstrap 裏面的屬性會優先加載，它們默認也不能被本地相同配置覆蓋。bootstrap 比 application 要先加載，bootstrap 只在 cloud 項目中使用。
添加配置：
#服務名spring.application.name=nacos-config-example# 配置中心urlspring.cloud.nacos.config.server-addr=127.0.0.1:8848# 配置中心的配置語法spring.cloud.nacos.config.file-extension=properties
現在在 nacos 配置中心新建配置：
dataId:nacos-config-example.properties
啓動項目，發現項目端口號是8082，我們的配置成功了。
說明
注意 圖中幾個選項 TEXT\JSON\ XML \YAML\ HTML\Propertiest 這些並不是指定 nacos 以何種語法去解析配置文件，僅僅是提供語法提示，代碼高亮輔助樣式；第一次使用的人很容易被誤導。我們要指定配置文件語法要在bootstrap做如下配置：
spring.cloud.nacos.config.file-extension=propertiesspring.cloud.nacos.config.file-extension=yaml
配置中心配置依靠dataId將配置信息和客戶端綁定，我們來看看dataId組成規則：
${prefix}-${spring.profile.active}.${file-extension}•
prefix 默認爲 spring.application.name 的值，也可以通過配置項 spring.cloud.nacos.config.prefix 來配置。
•
spring.profile.active 即爲當前環境對應的 profile ， 注意：當 spring.profile.active 爲空時，對應的連接符 - 也將不存在，dataId 的拼接格式變成 ${prefix}.${file-extension}
•
file-exetension 爲配置內容的數據格式，可以通過配置項 spring.cloud.nacos.config.file-extension 來配置。目前只支持 properties 和 yaml 類型。
也就是說我們這個配置中心的 dataId 和我們平時用 Spring Boot 命名配置文件只有一個 prefix 的區別
現在我們來修改一下配置文件，bootstrap 加一項：
spring.cloud.nacos.config.prefix=config-testspring.profiles.active=dev
配置中心弄兩個配置方便比較，一個 dataId 是 config-test-dev.properties ，一個 dataId 是 config-test-prod.properties 配置端口號分別爲 8081 和 8082 測試。啓動項目後發現項目端口號爲 8081，然後修改配置重啓：
spring.profiles.active=prod此時端口變成了 8082。用法和 Spring Boot 的配置文件區別不大。
命名空間和分組
命名空間和分組相當於一個配置文件的"年級和班次"，在同一個 group 下，配置文件名不能重複，所以當需要創建文件名稱相同的兩個配置文件時，將兩個配置文件創建在不同的 group 下即可。而 namespace 範圍比 group 大，目的是一樣的。
定義命名空間方式如圖
在bootstrap中對應配置
=命名空間ID分組則在配置中心新建配置的時候可指定，在bootstrap中對應配置
spring.cloud.nacos.config.group=group配置自動更新
通過 Spring Cloud 原生註解 @RefreshScope 實現配置自動更新，示例：
@Service@RefreshScopepublic class ConfigController {@Value("${config.test}")private String test;public void testStr(){System.out.print(test)}}
當你在配置中心更新 config.test 的 客戶端的 test 的值也會刷新，並且你還能在客戶端看到值變更的相關日誌。
小結
別的不說，這比 Spring Cloud Config 好用太多了有木有! 和 apollo 比起來配置太容易了有木有!這麼好用的東西，出正式版了，等坑都排完了妥妥的神器有木有!我選 nacos ，你呢？
作爲註冊中心
剛纔是作爲配置中心，接下來再來看看 nacos 作註冊中心。
介紹
服務治理是微服務架構中最爲核心和基礎的模塊。它主要用來實現各個微服務實例的自動化註冊與發現。隨着服務的越來越多，越來越雜，服務之間的調用會越來越複雜，越來越難以管理。而當某個服務發生了變化，或者由於壓力性能問題，多部署了幾臺服務，怎麼讓服務的消費者知曉變化，就顯得很重要了。不然就會存在調用的服務其實已經下線了，但調用者不知道等異常情況。這個時候有個服務組件去統一治理就相當重要了。註冊中心便是做這個事情的，我們的服務上下線和發現服務都要依賴於註冊中心。
nacos 註冊中心有哪些特性呢？首先 nacos 從 cap 的角度來說，它能針對不同模式採用 cp 還是 ap 原則。然後它對服務發現的支持種類也有很多，比如：gRpc、Dubbo RpcService、Spring Cloud RESTful Service 。並且 nacos 本身提供了很直觀的註冊中心管理界面。方便我們查看管理服務，其 api 也很豐富，我們完全可以在做二次開發去寫一個我們自己滿意的管理頁面。Nacos 提供對服務的實時的健康檢查，阻止向不健康的主機或服務實例發送請求。Nacos 支持傳輸層 (PING 或 TCP)和應用層 (如 HTTP、MySQL、用戶自定義）的健康檢查。
示例
新建一個 Spring Boot 項目，添加如下依賴:
<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId><version>0.9.0.RELEASE</version></dependency><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter</artifactId><version>2.1.1.RELEASE</version></dependency>
在啓動類上加上 @EnableDiscoveryClient 註解
@SpringBootApplication@EnableDiscoveryClientpublic class MytestApplication {public static void main(String[] args) {SpringApplication.run(MytestApplication.class, args);}}
application添加配置:
server.port=8081spring.application.name=service-mytestspring.cloud.nacos.discovery.server-addr=127.0.0.1:8848
啓動服務後，我們能看到nacos管理頁面註冊上了一個服務。點擊查看詳情：
列表上有一列是臨時實例，臨時實例通常使用 AP 一致性，因此如果發生網絡分區，註冊臨時實例仍然有效。持久化實例使用 CP 一致性，這保證了數據的一致性。而持久化配置則是配置集羣和數據庫，本文不做介紹。後期搭建集羣的時候我們在做測試。權重則是指調用服務時路由到該實例的優先係數，數字越大優先級越高，爲0則不會使用該實例。
總結
我們能用 nacos 作爲配置中心或者註冊中心，其本身提供管理界面也很方便。nacos 的使用企業也很多，下面放出一張 github 上 nacos 的使用企業截圖：
官方文檔還有提到 nacos 支持動態 DNS，也就是說支持 DNS 的負載均衡，但本人沒找到很好的資料，後續再做研究。關於 nacos 集羣和持久化配置搭建後續更新，感謝閱讀。
關注我，你不會失望的！！
本文分享自微信公衆號 - JAVA開發大本營（gh_42999193133a）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。