© Dmitri Popov
阿里巴巴微服務開源項目Nacos於近期發佈v0.5.0版本，該版本主要包括了DNS-basedService Discovery，對Java 11的支持，持續優化Nacos產品用戶體驗，更深度的與Spring Cloud體系的網關集成等方面做了演進。
一、發佈 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會做持續的探索和推進。
二、支持 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的優化，啟動狀態展示的優化、性能調優等，例如：
#177 Consolesupports registering new empty service and delete empty service.
#222 printmore nacos server start status info in start.log.
#251 ConsoleEditor Optimization.
#254 DataIdand group are required in historical version and listener query.
#258 Removethe Balloon of DataId/Group.
更多優化和release信息見 Nacos Github
正在蓬勃發展的 Nacos 社區DISSis cheap, show me your hand比吐槽更重要的是搭把手，參與社區一起發展NacosNacos社區正在蓬勃發展，截止到發文為止，Nacos已經有5個微信群，4個已滿員，1個QQ群，1個釘釘群，關注Nacos的社區人數已經近3000人，在群裡切磋技術，招聘交友，搶搶紅包...不亦樂乎。
閱讀更多 中間件小哥 的文章
