探秘 Spring Cloud 生态微妙变化下的第三方独立组件发展现状

原创
2018/11/28 14:46
阅读数 850

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坤宇和他的团队看来,那些以业务为导向的企业,其“技术的持续投入”总会在业务遇到挑战时面临挑战,只有充分拥抱社区,坚持社区化发展,信仰社区高于代码,才有可能让技术的开源延续。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部