Spring Cloud生態正經歷著一些變化，前有Netflix閉源Eureka，後有Netflix宣佈Hystrix停止開發新功能。同時，Spring Cloud也從依賴生態夥伴提供關鍵元件，演變到自己開發適配關鍵元件，例如提供了Spring Cloud Zuul/Spring Cloud Config/Spring Cloud Loadbalance等開源產品。今天，我們來一起看看Spring Cloud生態中提供註冊中心和配置中心功能的第三方獨立元件 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的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會做持續的探索和推進。

二、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坤宇和他的團隊看來，那些以業務為導向的企業，其“技術的持續投入”總會在業務遇到挑戰時面臨挑戰，只有充分擁抱社群，堅持社群化發展，信仰社群高於程式碼，才有可能讓技術的開源延續。