微服务架构中基于DNS的服务发现
当前,微服务架构已经成为企业尤其是互联⽹企业技术选型的⼀个重要参考。微服务架构中涉及到很多模块,本⽂将重点介绍微服务架构的服务注册与发现以及如何基于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服务,免费体验。相关链接:。
总结
本⽂介绍了微服务架构中如何基于DNS做服务发现。⾸先,介绍了服务法注册与发现的概念、服务注册与发现的⼏种⽅式及其优缺点;然后,介绍基于DNS的服务发现的两种⽅式及其优缺点;最后,介绍了阿⾥巴巴基于DNS做服务发现的实践,主要是基于⾃研的软负载系统VIPServer。基于DNS的服
务发现要解决的问题远不⽌本⽂描述的这些,敬请期待后续系列⽂章(:。

版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198,我们将在24小时内删除。