Nacos發佈0.5.0版本，輕鬆玩轉動態 DNS 服務

阿里巴巴微服務開源項目Nacos於近期發佈v0.5.0版本，該版本主要包括了DNS-basedService Discovery，對Java 11的支持，持續優化Nacos產品用戶體驗，更深度的與Spring Cloud體系的網關集成等方面作了演進。

1、發佈 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的plugin nacos-coredns-plugin,這樣打通了CoreDNS與Nacos服務,這種實現方式爲將來進一步打通Kubernetes集羣內部的服務發現與應用服務發現（如SpringCloud)提供了通路，爲Nacos在將來幫助應用以統一的視圖管理Kubernetes內部和應用自身的服務及域名提供了基礎，從而幫助用戶簡化基於kubernetes體系的微服務平臺的構建與管理。

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

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

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

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

以Zookeeper爲例子，Zookeeper質量比較好的客戶端僅有Java和C的客戶端，那麼非這兩個語言體系的服務和系統就很難經過Zookeeper來註冊與發現，而DNS自然是各類語言都支持的，使用DNS作服務發現對應用的侵入很是的小，很是適合應用往新微服務平臺上的遷移。

---

以阿里巴巴爲例，基於DNS-F模式的服務發現已是阿里巴巴生產環境中的最重要方式之一，其對發現和打通像阿里媽媽、高德、優酷和搜索等這樣的非Java語言體系的業務系統提供的服務，起到了舉足輕重的做用。距離阿里巴巴內部發布的第一個Python版本的DNS-F客戶端已通過去5個年頭，而DNS-F的總體裝機使用量對全部內部VIPServer各語言客戶端的佔比已經超過40%，可見其應用之普遍，而不用綁定在私有的VIPServerAPI上也是衆多業務線願意優先考慮DNS-F客戶端的首要緣由。

DNS協議自己是爲www而生，並不是爲服務發現而生，因此在協議上，用在服務發現場景下DNS依然有很多的小瑕疵須要在將來從協議層面解決，好比DNS緩存TTL收斂的問題，好比操做系統以及各語言對SRV Record字段的支持問題,DNS包大小限制的問題等等，但隨着Kubernetes以及微服務體系在各行業的深刻應用，能夠說DNS協議已經有爲服務發現場景作進一步向前演進的必要，這方面阿里巴巴&Nacos會作持續的探索和推動。

2、支持 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

因此，如今狀態是都已經支持。

3、實現Spring CloudGateway的動態路由

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

4、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輸出的需求，爲後續的融合作好了初步的準備。

5、支持 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 都已一網而聚之。

6、持續優化用戶體驗

提高產品易用性永遠是Nacos團隊的核心關注點，在Nacos 0.5.0 版本就社區反饋的一些局部體驗問題作了積極的修復，這包括前端UI的優化，啓動狀態展現的優化、性能調優等。

原文連接本文爲雲棲社區原創內容，未經容許不得轉載。