贡献Dubbo生态，阿里开源Nacos项目
阿里巴巴微服务开源项目Nacos于近期发布v0.5.0版本，该版本主要包括了DNS-basedService Discovery，对Java 11的支持，持续优化Nacos产品用户体验，更深度的与Spring Cloud体系的网关集成等方面做了演进。
Nacos 是阿里巴巴的新开源项目，其核心定位是 “一个更易于帮助构建云原生应用的动态服务发现、配置和服务管理平台”。
Nacos 有三大主要功能:
服务发现与服务管理
在采用以“服务(Service)”为中心的诸如微服务及云原生方式的现代应用架构时，动态服务发现至关重要。 Nacos同时支持基于DNS和基于RPC（如Dubbo/gRPC）的服务发现，并为您提供服务的实时的健康检查以防止将请求发送给不健康的主机，基于Nacos您也可以更方便的实现服务断路器。Nacos提供的强大的服务的元数据管理，路由及流量管理策略也能够帮助您更好的构建更强壮的微服务平台。
动态配置管理
动态配置服务允许您在所有环境中以集中和动态的方式管理所有应用程序或服务的配置。动态配置消除了配置更新时重新部署应用程序和服务的需要。可以更方便的帮助您实现无状态服务，更轻松地实现按需弹性扩展服务实例。
动态DNS服务
支持权重路由的动态DNS服务使您可以更轻松地在数据中心内的生产环境中实施中间层负载平衡，灵活的路由策略，流量控制和简单的DNS解析服务，帮助您更容易的实现DNS-based服务发现。
最近，Nacos发布了0.5.0版本，看下有哪些新特性吧。
为了进一步降低微服务多语言生态、异构系统、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会做持续的探索和推进。
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
所以，现在状态是都已经支持。
要实现微服务架构，微服务网关必不可少，Nacos 社区目前正在努力跟 Spring Cloud 的微服务网关做更多的打通与集成，Spring Cloud 中文社区创建者,《重新定义Spring Cloud实战》的作者 @许进 与近期贡献了如何基于Spring Cloud Gateway与Nacos实现动态路由能力的示例，毫无疑问，Spring Cloud Gateway作为所有请求流量的入口，在实际生产环境中为了保证高可靠和高可用，尽量避免重启,需要实现Spring Cloud Gateway 动态路由配置，等到这块足够成熟，会将其包含在Nacos的官方推荐实现中。
在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输出的需求，为后续的融合做好了初步的准备。
就像 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
直面Java第175期：Java中如何比较两个时间的大小？
成神之路第015期：深入学习Java中的枚举。
- MORE | 更多精彩文章 -
如果你喜欢本文。
请长按二维码，关注Hollis
转发朋友圈，是对我最大的支持。