微服务架构中基于DNS的服务发现

Posted 2021-04-14 程序你好

当前，微服务架构已经成为企业尤其是互联网企业技术选型的一个重要参考。微服务架构中涉及到很多模块，本文将重点介绍微服务架构的服务注册与发现以及如何基于DNS做服务发现。最后，简单介绍下阿里巴巴内部是如何基于DNS做服务发现的。

服务发现交互协议

微服务架构中，服务注册与发现的通信协议大致可以分为两类：一类是“私有”协议，如dubbo + zk及eureka；另一类是通用的DNS协议，如k8s + coredns。

“私有”协议

“私有”协议具有很高的定制性，可以和具体产品一起实现更高级的功能，如zk + dubbo，可以支持推送和长连接。但是，“私有”协议也带来了另外一个问题，就是开放性很差，第三方接入需要使用特定的SDK，跨语言特性不好。而在微服务或云环境下，跨语言服务注册和发现是非常常见的一个场景。

DNS协议为基础的服务发现

DNS协议是一个“古老”的协议，也是最基本、最通用的协议之一。基于DNS协议的服务发现具备非常好的通用性，几乎所有语言都可以无缝接入。与“私有”协议的服务发现相比，基于DNS协议的服务发现还有一些问题需要解决，如端口问题、语言框架的缓存问题。这些问题已经有了对应的解决方案，将在后续文章中向大家介绍，本文重点放在基于DNS的服务发现的大概玩法。

服务注册与发现

微服务体系中，服务注册与服务发现是两个最核心的模块。服务A调用服务B时，需要通过服务发现模块找到服务B的IP和端口列表，而服务B的实例在启动时需要把提供服务的IP和端口注册到服务注册中心。一个典型的结构如下图：

 

服务注册

目前，流行的注册中心比较多，常见的有zookeeper、ectd、consul、eureka等。服务注册通常有三种：自注册、第三方注册、注册中心主动同步。

• 自注册
  自注册，顾名思义，就是服务提供方在启动服务时自己把提供服务的IP和端口发送到注册中心，并通过心跳方式维持健康状态；服务下线时，自己把相应的数据删除。典型的像使用eureka客户端发布微服务。

• 第三方注册
  第三方注册是指，存在一个第三方的系统负责在服务启动或停止时向注册中心增加或删除服务数据。典型的用法是devops系统或容器调度系统主动调注册中心接口注册服务；

• 注册中心主动同步
  与第三方注册方式类似，主动注册方式是指注册中心和调度或发布系统打通，主动同步最新的服务IP列表；一个例子是kubernetes体系中，coredns订阅api server数据。

服务发现

在真正发起服务调用前，调用方需要从注册中心拿到相应服务可用的IP和端口列表，即服务发现。服务发现从对应用的侵入性上可以分为两大类：

• SDK-Based
  这类的服务发现方式，需要调用方依赖相应的SDK，显式调用SDK代码才可以实现服务调用，即对业务有侵入性，典型例子如eureka、zookeeper等。

• DNS-Based
  DNS本身是一种域名解析系统，可以满足简单的服务发现场景，如双方约定好端口、序列化协议等等。但是，这远远不能满足真正的微服务场景需求。近几年，基于DNS的服务发现渐渐被业界提了出来。后面将重点介绍基于DNS的服务发现及阿里巴巴的实践。

基于DNS的服务发现

DNS协议是目前最为通用的协议之一，几乎所有操作系统都会有DNS客户端实现。所以，其天然具有跨语言特性。这也是快速接入微服务体系最快的一个方式。要基于DNS做服务发现，首先注册中心的数据应该可以以DNS的数据格式暴露出来，让任何系统的DNS 客户端都可以通过DNS协议获取服务列表。

基于DNS的服务发现方式，大致可以归结两类：

独立DNS服务器

独立DNS Server模式的基本架构如下图：

如上图所示，这种架构中，需要独立的DNS服务器。DNS服务器从注册中心获取所有已注册的服务及对应的IP端口列表。调用方Service A 通过DNS查询某个服务下的IP列表，然后发起调用。

 

这种类型的服务发现方式优缺点分别如下：

• 优点

1. 集中的DNS服务器，便于升级维护

• 缺点

1. 对DNS服务器性能要求高

2. 这种情况下一般需要LVS设备为DNS服务器集群做请求转发，存在单点问题

DNS Filter

DNS Filter模式我们定义为把DNS服务器集成到服务调用方机器或容器里，如下图所示：

这种模式中，首先要保证ServiceA的DNS查询都被拦截到本机的DNS服务器上（127.0.0.1:53），在获取到服务的IP列表后发起调用。由于这种方式把DNS服务器前置到实际调用的机器上，所以它解决了独立DNS服务器模式的单点问题，完全P2P的模式。但由于需要在应用机器上安装DNS服务器，其维护和升级成本较前者高一些。

 

阿里基于DNS的服务发现实践

阿里巴巴早在2013年就开始了基于DNS做服务发现的尝试了，现在已经形成了较为成熟的模式。是业界比较早开始这方面的探索的公司，公开资料显示比SkyDNS（CoreDNS前身）要早几个月时间。阿里内部以VIPServer作为注册中心，并开发了DNS Filter，部署在应用容器内。目前已经有超过20w个机器或容器上安装了DNS Filter，支持了几乎所有REST服务发现。

注册中心 VIPServer

VIPServer是阿里中间件软负载团队自研的服务注册中心，按照第一章的分类，VIPServer同时支持三种模式的服务注册，并且均有相当规模的应用。除此之外，VIPServer具备如下特性：

• 主动与被动健康检查
  VIPServer同时支持主动与被动健康检查。主动健康检查是指VIPserver服务端主动定期发送健康检查探测包，探测服务提供方是否可以正常提供服务。用户可以配置多种健康检查方式，自定义探测端口和探测URL（HTTP）。主动探测的好处在于服务提供方不用做任何改动即可快融入微服务架构。被动健康检查则是指服务提供方主动注册自己的IP、端口和服务名等信息，并通过心跳方式保持活性。

• 多种负载均衡策略
  同时，VIPServer支持多种负载均衡策略，包括权重、同机房、同地域、同环境等等，是阿里异地多活项目的核心系统之一。后面会有专门的文章介绍如何基于VIPServer实现异地多活，这里不再赘述。

• 多重容灾保护策略
  VIPServer提供了多种容灾保护策略，可以有效减少人为或者底层系统（网络等）异常带来的影响。这些容灾保护包括：

1. 客户端缓存，即使VIPServer服务端挂掉也不影响应用的正常调用；

2. 服务端保护阈值，有效防止应用因压力过大而发生雪崩；

3. 客户端容灾目录，提供人工干预服务IP列表的能力；

4. 客户端空列表保护，有效防止人为误删IP列表操作或VIPServer服务端异常；

DNS-F客户端

出于性能的考虑，我们采用了第二种DNS Filter的服务发现模式。为此，我们单独开发了DNS-F客户端，DNS-F客户端跟应用部署在同一个主机或容器内。其工作原理如下图所示：

 

• 首先，应用ServiceA通过DNS查询获取到ServiceB的可用IP列表；

• DNS-F会拦截到ServiceA的查询请求，判断自己是否该查询的答案，如果有（服务已在VIPServer中注册）则直接返回IP列表；

• 如果查询的服务在VIPServer中没有注册，DNS-F把DNS查询转发给系统的nameserver，由真正的DNS系统解析；

阿里云上的VIPServer服务及开源计划

在阿里云上，我们正在将我们在DNS-Based Service Discovery上的功能及实践经验在Aliware的企业级应用服务(EDAS)产品上逐渐开放。我们也正在规划将VIPServer的核心能力在一个新的开源项目(nacos)里回馈给开源社区，期待跟大家一起在未来探索服务发现领域。如果您想体验阿里巴巴微服务解决方案，可以到阿里云上开通EDAS服务，免费体验。相关链接：Spring Cloud 接入 EDAS 之服务发现篇。

总结

本文介绍了微服务架构中如何基于DNS做服务发现。首先，介绍了服务法注册与发现的概念、服务注册与发现的几种方式及其优缺点；然后，介绍基于DNS的服务发现的两种方式及其优缺点；最后，介绍了阿里巴巴基于DNS做服务发现的实践，主要是基于自研的软负载系统VIPServer。基于DNS的服务发现要解决的问题远不止本文描述的这些，敬请期待后续系列文章