阿里巴巴微服務開源專案Nacos於近期釋出v0.5.0版本，該版本主要包括了DNS-basedService Discovery，對Java 11的支援，持續優化Nacos產品使用者體驗，更深度的與Spring Cloud體系的閘道器整合等方面做了演進。

什麼是Nacos

Nacos 是阿里巴巴的新開源專案，其核心定位是 “一個更易於幫助構建雲原生應用的動態服務發現、配置和服務管理平臺”。

Nacos 有三大主要功能:

服務發現與服務管理

在採用以“服務(Service)”為中心的諸如微服務及雲原生方式的現代應用架構時，動態服務發現至關重要。 Nacos同時支援基於DNS和基於RPC（如Dubbo/gRPC）的服務發現，併為您提供服務的實時的健康檢查以防止將請求傳送給不健康的主機，基於Nacos您也可以更方便的實現服務斷路器。Nacos提供的強大的服務的元資料管理，路由及流量管理策略也能夠幫助您更好的構建更強壯的微服務平臺。

動態配置管理

動態配置服務允許您在所有環境中以集中和動態的方式管理所有應用程式或服務的配置。動態配置消除了配置更新時重新部署應用程式和服務的需要。可以更方便的幫助您實現無狀態服務，更輕鬆地實現按需彈性擴充套件服務例項。

動態DNS服務

支援權重路由的動態DNS服務使您可以更輕鬆地在資料中心內的生產環境中實施中間層負載平衡，靈活的路由策略，流量控制和簡單的DNS解析服務，幫助您更容易的實現DNS-based服務發現。

最近，Nacos釋出了0.5.0版本，看下有哪些新特性吧。

釋出 DNS-F

為了進一步降低微服務多語言生態、異構系統、Kubernetes體系的服務註冊與發現的實現成本，Nacosv0.5.0 釋出了一款DNS-F客戶端，以便支援將註冊在Nacos上的服務以域名的方式暴露端點，讓三方應用方便的查閱及發現。

不同於Nacos的Client SDK服務發現模式，DNS-F 提供獨立於應用程序的Agent, 通過攔截應用的域名解析請求，讓Nacos對應用提供域名資料動態推送更新、健康檢查、異常節點下線、以及統一的域名管理檢視等服務。

Nacos提供基於DNS 協議的服務發現能力，旨在幫助使用者解決三個方面的問題:

Kubernetes體系的服務發現

毫無疑問，Kubernetes體系的服務發現方案一直都是基於DNS的，Nacos DNS-F目前開源提供的版本，是在CoreDNS的基礎上提供了Nacos的pluginnacos-coredns-plugin,這樣打通了CoreDNS與Nacos服務,這種實現方式為未來進一步打通Kubernetes叢集內部的服務發現與應用服務發現（如SpringCloud)提供了通路，為Nacos在未來幫助應用以統一的檢視管理Kubernetes內部和應用自身的服務及域名提供了基礎，從而幫助使用者簡化基於kubernetes體系的微服務平臺的構建與管理。

服務發現迄今仍然沒有標準協議

到目前為止，市面上的服務發現的解決方案有很多，僅在JavaSpring生態中，就有Zookeeper，Consul，Eureka，Nacos等解決方案，更不用說在其它的語言和框架中，Nacos通過提供DNS-F，可以讓使用者更容易地實現以DNS協議為基礎的服務發現（DNS-SD），而DNS協議是一個成熟的標準協議，可以有效的幫助使用者消除耦合到廠商私有服務發現API上的風險。

異構及多語言系統的服務發現

在一箇中大型企業中，傳統企業架構要升級為雲原生微服務架構，遺留系統和異構系統的服務註冊與發現無疑是必須首要解決的問題。另外採用微服務架構的一大承諾收益點也在於每個微服務本身可以獨立選擇語言棧，但是到目前為止沒有個一個服務發現產品能提供各種語言客戶端的100%的完全覆蓋。

DNS協議本身是為www而生，並非為服務發現而生，所以在協議上，用在服務發現場景下DNS依然有不少的小瑕疵需要在未來從協議層面解決，比如DNS快取TTL收斂的問題，比如作業系統以及各語言對SRV Record欄位的支援問題,DNS包大小限制的問題等等，但隨著Kubernetes以及微服務體系在各行業的深入應用，可以說DNS協議已經有為服務發現場景做進一步向前演進的必要，這方面阿里巴巴&Nacos會做持續的探索和推進。

支援 Java 11

9月25日，Oracle 官方宣佈Java 11正式釋出，這是繼 Java 8 後的首個長期支援版本，Java11 在諸如ZGC，TLS 1.3，新的演算法金鑰協議，Lambda 區域性變數語法支援，Standardize HTTPClient API 等不少方面做了改進，值得關注。

劃重點~ github上給Nacos提issue是實現你的需求和想法的最佳手段!

Nacos支援Java 11, 主要是指2個方面:

Nacos支援執行在Java11上

將Nacos原始碼開發及構建環境升級到Java11

所以，現在狀態是都已經支援。

實現Spring CloudGateway的動態路由

要實現微服務架構，微服務閘道器必不可少，Nacos 社群目前正在努力跟 Spring Cloud 的微服務閘道器做更多的打通與整合，Spring Cloud 中文社群建立者,《重新定義Spring Cloud實戰》的作者 @許進 與近期貢獻了如何基於Spring Cloud Gateway與Nacos實現動態路由能力的示例，毫無疑問，Spring Cloud Gateway作為所有請求流量的入口，在實際生產環境中為了保證高可靠和高可用，儘量避免重啟,需要實現Spring Cloud Gateway 動態路由配置，等到這塊足夠成熟，會將其包含在Nacos的官方推薦實現中。

TTL & Health Status Aggregation

在Nacos之前的幾個版本中，使用者往往會在使用過程中產生疑惑，為什麼註冊的例項已經下線(宕掉)了，但是依然可以在Nacos控制檯上看到例項的資訊。這源於SpringCloud以及Dubbo等服務體系中，Eureka或者Zookeeper都有自動登出例項的能力，而且將自動登出作為註冊中心的預設行為。但其實當服務的例項下線(宕掉)之後，註冊中心有兩種可能的行為，一個是將這個例項從服務下的例項列表中剔除出去，一個是保留該例項，只將例項狀態置為不健康。Eureka和Zookeeper等註冊中心，其實也支援持久化的例項註冊，而Nacos只是將這種持久化的註冊設成了預設的行為。

Nacos的服務發現模組，是基於內部的VIPServer演化而來。在VIPServer的主要場景中，服務是以域名的方式通過控制檯註冊到VIPServer的，並且VIPServer非常注重服務級別的元資料資訊的定義帶來的靈活“軟負載”流量排程的能力，所以首要選擇的是服務及例項的元資料的永續性儲存，弱化了服務的提供端持續向VIPServer服務端傳送心跳的能力，所以前期並沒有將VIPServer 上報和匯聚例項健康狀態的功能放出來。之前版本的服務例項的健康檢查，必須由VIPServer服務端來主動發起來完成。但是如Nacos開源之初規劃的那樣，Nacos會同時支援兩種模式。

對於複雜的雲環境和網路拓撲環境中（如 VPC、邊緣網路等）服務的健康檢查，Nacos 提供了心跳上報模式和服務端主動探測2種健康檢查模式。

所以隨著Nacos 0.5.0 版本的釋出，我們很高興的宣佈，Nacos已經正式支援基於TTL的服務例項自動登出功能。這個功能一部分是響應社群關於TTL功能的需求，更重要的一部分，這也是Nacos服務發現自然演進的一個方向。

從 0.5.0 版本開始，使用者通過客戶端SDK註冊的例項，將預設開啟TTL功能，例項會預設每5秒向服務端傳送一次心跳，如果Nacos服務端15秒內沒有收到例項的心跳，則會將例項置為不健康，如果30秒沒有收到心跳，則會將直接將例項刪除。Nacos的TTL功能，補充了Nacos作為註冊中心在處理例項下線的另一種行為，通過靈活可動態配置的引數，使用者還可以根據實際的應用場景任意切換使用這兩種行為中的一種。

Nacos的TTL功能雖然還處在實驗性質，主要有以下特色：

進一步無縫融入SpringCloud生態和Dubbo生態

Nacos在最初的規劃中，就已經計劃能夠幫助存量使用者做無縫平滑遷移。而無縫平滑遷移除了註冊中心的功能的完整性，體驗、效能、一些重要的認知也能夠從老註冊中心接續過來。例如Eureka作為Spring Cloud裡的主流注冊中心，其預設行為就是會在沒有收到例項心跳90秒後，將例項自動登出。而 Dubbo 裡用的比較多的Zookeeper，也會使用臨時節點，依託於Session超時時間來實現TTL功能。這這兩種場景中，服務例項的註冊基本都是通過服務提供端(Provider)使用註冊中心客戶端來完成的。Nacos目前已經提供了Spring Cloud體系的服務發現的完整解決方案，同時對Dubbo的適配和支援也會在最近的版本中釋放出來。

服務級別"元資料(metadata)"不會自動登出

Nacos支援服務、叢集和例項多級別的元資料資訊，與服務例項可以被自動登出相對的，服務本身的元資料資訊不能隨著服務的下線而丟失,因為這些元資料通常是在建立服務時有人為設定上去的（例如負載均衡策略，權重規則，保護閾值等）。這意味著同一個服務的例項的上上下下，再註冊上來的時候，應該依然保有服務原來設定的相關的元資料資訊。

在Eureka或者Consul中，由於並不支援服務級別設定任何元資訊，因此當例項都臨時下線時，整個服務也就查詢不到任何存在過的痕跡了。而服務級別的元資訊作為Nacos的一個非常重要的特色功能，未來會基於此開放一系列流量控制類的特色功能，都決定了Nacos服務本身的元資料資訊不能隨著服務的下線而丟失，另一方面，在客戶端註冊例項時，不允許提交服務級別的元資訊，這樣也保證了單個例項的註冊或者登出不會影響服務級別的配置。我們提供了控制檯來對服務元資料進行便捷的建立和編輯。

將HSF的註冊中心ConfigServer融入Nacos

在阿里巴巴集團內部，著名的HSF的註冊中心ConfigServer支援的就是長連線註冊模式(renew&TTL)，因此當長連線斷開時，自然而然的就會將例項登出掉。為了支援未來將HSF一些優秀的特性遷移和輸出到Dubbo上，Nacos會逐漸將ConfigServer的核心能力融入到Nacos當中，而TTL則也是這個事情的基礎。

而同時，Nacos非常看中產品在雲上的適用性，在公有云上，因為使用者往往註冊到註冊中心的IP是一個VPC的外部IP，因為公有云安全策略的限制，註冊中心一般是不允許主動發起到VPC內的連線來做健康檢查的，只能通過客戶端上報心跳的模式來檢查健康狀態，也只有在客戶端上報的模式下，才能啟用自動登出功能。Nacos此次的TTL功能，很好的銜接了公有云和內部ConfigServer輸出的需求，為後續的融合做好了初步的準備。

支援 Spring Cloud Alibaba 生態

就像 SpringOne Platform大會上Spring開發者@Roy Clarkson 和@Ollie Hughes 在《Cloud-Native Javawith Spring Cloud Services》裡闡述的那樣，採用微服務設計模式，首要的就是選擇“ExternalConfiguration” “Service Registry” “Circuite Breaker”的實現，而 Spring Cloud forAlibaba 這個專案則旨在通過輸出阿里巴巴在服務化以及雲上的分散式微服務經驗打包在一個stack裡，給你提供支撐大規模微服務的一站式解決方案，正如專案所述：

“The Spring Cloud Alibaba project, consisting of Alibaba’s open-source componentsand several Alibaba Cloud products, aims to implement and expose well knownSpring Framework patterns and abstractions to bring the benefits of Spring Bootand Spring Cloud to Java developers using Alibaba products.”

隨著Spring Cloud for Alibaba 0.2.0 的釋出，Nacos Config, NacosService Discovery 和 Sentinel Circuite Breaker 都已一網而聚之。

持續優化使用者體驗

提升產品易用性永遠是Nacos團隊的核心關注點，在Nacos 0.5.0 版本就社群反饋的一些區域性體驗問題做了積極的修復，這包括前端UI的優化，啟動狀態展示的優化、效能調優等，例如：

更多優化和release資訊見Nacos Github