文章整理自虎牙根本保障部中间件团队卖力人张波(社区ID:zhangjimmy)在Dubbo Meetup 广州站沙龙上的分享,阿里巴巴中间件授权发布,分享议题如下:
为什么选用NacosDNS-F的技能代价和运用处景做事注册的实践CMDB的运用和实践做事配置的实践为什么选用 Nacos虎牙关注 Nacos 是从v0.2 开始的(最新版本:Pre-GA v0.8),我们也参与了社区的培植,可以说是比较早期的企业用户。
Nacos 是一个更易于帮助构建云原生运用的动态做事创造、配置和做事管理平台,供应「注册中央」、「配置中央」和「动态DNS做事」三大功能。

首先,在虎牙的微做事场景中,起初有多个注册中央,每一个注册中央做事于某一部分微做事,短缺一个能领悟多个注册中央,并把他们逐一打通,然后实现一个能管理全体微做事体系的大的注册中央。
以下内容摘自我们考虑引入Nacos时,在做事注册中央方案上的选型比拟:
Nacos供应 DNS-F功能, 可以与K8S、Spring Cloud和Dubbo等多个开源产品进行集成,实现做事的注册功能。
其次,在做事配置中央方案的选型过程中,我们希望配置中央和注册中央能够打通,这样可以省去我们在微做事管理方面的一些投入。因此,我们也同步比较了一些做事配置中央的开源方案:
例如Spring Cloud Config Server、Zookeeper和ETCD,总体评估下来,基于我们微做事体系现状以及业务场景,我们决定利用Nacos作为我们的做事注册和做事创造的方案。利用过程中,我们创造,随着社区版本的不断更新和虎牙的深入实践,Nacos的上风远比我们调研过程中创造的更多,接下来,我将环绕DNS-F、Nacos-Sync、 CMDB和负载均衡4方面来分享虎牙的实践。
DNS - F 的技能代价Nacos 供应的DNS-F功能的第一个技能代价在于,填补了我们内部微做事没有一个全局动态调度能力的空缺。刚才提到,虎牙有多个微做事体系,但并没有一个微做事具备全局动态调度的能力,由于它们各自都是独立的。目前,我们通过Nacos已经领悟了四个微做事体系的注册中央,终极目标是把所有的微做事都领悟在一起,实现全局动态调动的能力。
第二,DNS-F办理了做事端端到端面临的寻衅,即延时大、解析不准、故障牵引慢的问题。
如何去理解呢?
当内部有多个微做事体系的时候,每一个体系的成熟度是不同的。例如,有一些微做事框架对同机房或CMDB路由是不支持的,当一个做事注册到了多个IDC中央,去调用它的做事的时候,即便是同机房,也可能调用到一个不是同机房的节点。这样就会无端的造成做事的延时和解析不准。
纵然我们基于DNS做一些解析的优化,但仍旧无法完备办理做事的延时和解析不准。这是由于DNS都是IP策略的就近解析,无法根据做事的物理状态、物理信息进行路由。此外,当一个核心做事涌现问题,如果短缺一个领悟了多个调用方和被调用方的信息的统一的注册中央,就很难去准确判断如何去牵引,从而导致故障牵引慢。有了Nacos后,就可以接入一个统一的注册中央以及配置中央,去办理这些问题。(目前,虎牙还在微做事体系的改造过程中,未完备实现统一的注册中央)
第三,供应专线流量牵引能力。虎牙的核心机房的流量互通,是利用专线来实现的。专线的特性便是物理培植的,而且我们的专线培植可能不像BAT那么大,例如我们专线容量的冗余只有50%,假设某个直播非常火爆,突发流量高于平常的两百倍,超过了专线的培植能力,这时候一个做事就有可能会导致全网故障。但是,通过全局的注册中央和调动能力,我们就可以把流量牵引到其他地方,例如迁移到公网,乃至牵引到一个不存在的地址,来平衡一下。即便某个做事涌现问题,也不会影响我们的全局做事。
第四,支持做事真个多种调度需求,包括同机房路由、同机器路由,以及同机架路由,Nacos都可以去做适配。此外,基于Nacos 的DNS-F功能,我们还实现了加速外部域名解析和做事故障牵引秒级生效。
DNS - F 的运用处景
这张图是Nacos DNS-F的一个详细实现,实际上是拦截了OS层的DNS要求。如果经由DNS的域名是内部做事,它就会从Nacos Server 获取结果,如果不是,就会转发到其它的LocalDNS进行解析。
以数据库高可用的运用处景为例,我们的数据库切换效率比较低,依赖业务方修正配置,时效不愿定,常日须要10分钟以上(备注:我们的数据库实际上已经实现了主备的功能,但当一个主理事涌现问题的时候,总是要去切换IP。)切换IP的过程中,依赖运维和开拓的协作,这是一个比较长的过程。
引入DNS后,当主涌现问题的时候,就可以很快的用其余一个主的IP来进行更换,屏蔽故障,而且节点的故障检测和故障切换都可以自动完成,并不依赖运维和开拓的协作,节省了韶光。当然,这个场景的解法有很多,比如说利用MySQL - Proxy也可以去解这个问题,但我们的MySQL - Proxy还在培植中,想尽快的把这个问题办理,以是采取了DNS的办法。
下面我们再着重分享下基于DNS-F对LocalDNS的优化。虎牙还没有去培植自己的LocalDNS,大部分利用的是一些公共的DNS,大致有以下这些组成。
这种组成办法会存在一个问题。假设做事溘然一下崩溃后,之后做事又立时正常了,这种情形我们无法重现去找到崩溃缘故原由。由于很多场景下,是一个公共DNS的要求超时导致的,乃至一个解析失落败导致的,在那一刻,由于无法保留现场的,以是就创造不了问题。
以我们的监测数据来看,DNS解析缺点的比例达到1‰旁边,超时比例将更高。意思是在利用公共DNS的情形下,做事有1‰的几率是会超时或失落败,如果做事没有做好容错,就会涌现非常。同时,一些公共DNS解析的延时都是不定的,比如在亚马逊上一些比较不好的节点,它的延时会比较高,均匀超过三四十毫秒。
然后我们基于DNS-F对LocalDNS做了一些优化。优化结果如下:
均匀解析韶光从之前的超过两百毫秒降落到两毫秒以下;缓存命中率从92%提升到了99%以上;解析失落败率之前是1‰,现在基本上没有了。优化的效果也表示在我们的风控做事上,均匀延迟低落10ms,做事超时比例低落25%,降落了因延迟或做事超时导致的用户上传的图片或笔墨违规但未被审核到的风险。
做事注册的实践虎牙的核心业务是跑在Tars上的。
Tars:腾讯开源的一款微做事框架。
Tars紧张是支持C++,但对Java、PHP等开拓措辞的支持力度比较差,这就使得我们非C++的业务方去调用它就会很别扭。引入Nacos往后,我们通过Nacos支持的DNS协议来实现做事创造过程中对全措辞的支持。
当然,Nacos不但是一个注册中央,它具备了领悟多个数据中央的能力,支持多数据源的同步,例如,我们目前已经支持了Taf(虎牙内部的一个主要微做事体系)、Nacos自身、ZooKeeper、以及K8S上一些做事注册的同步。
同时,基于Nacos集群的双向同步功能(Nacos-Sync),我们实现了海内的两个可用区,以及国外的多个可用区之间的数据值同步,终极实现了一处注册、多地可读。
Nacos-Sync是事宜机制,即同步任务通过事宜触发,可以灵巧地开启和关闭你要同步的任务,然后根据做事变革事宜触发监听,担保实时性,末了通过定时的全量突发同步事宜,担保做事数据的终极同等。同时,Nacos-Sync也支持做事心跳坚持,即多个数据中央的心跳,可以利用Nacos-Sync代理要来实现远端同步。此外,也支持心跳与同步任务绑定,便于灵巧掌握。
由于Taf上有数万个注册做事,同步的量特殊大,以是我们在Nacos-Sync做了一些改造,通过任务分片来实现数万做事同步的可用性保障。改造步骤是先以做事为粒度定义任务,然后在多个分片上分散任务负载,末了以单分片多副本来担保任务可用性。
对接 CMDB,实现就近访问
在做事进行多机房或者多地域支配时,跨地域的做事访问每每延迟较高,一个城市内的机房间的范例网络延迟在1ms旁边,而跨城市的网络延迟,例如上海到北京大概为30ms。此时自然而然的一个想法便是能不能让做事消费者和做事供应者进行同地域访问。
Nacos定义了一个SPI接口,里面包含了与第三方CMDB约定的一些方法。用户依照约定实现了相应的SPI接口后,将实现打成Jar包放置到Nacos安装目录下,重启Nacos即可让Nacos与CMDB的数据打通。
在实际的落地过程中,我们是在DNS-F接入Taf,在DNS-F上实现Taf的中控接口,无缝对接Taf的sdk。DNS-F供应缓存负载均衡和实例信息,Nacos则供应负载均衡信息的查询接口。
做事配置的实践虎牙的域名(www.huya.com)会接入华南、华中、华北多个IDC机房,每个机房都会培植一个Nginx去做负载均衡,经由负载均衡的流量会通过专线返回到我们的后端做事器上。在这个过程中,如果我们去修正一个在中间的配置,须要下发到多个机房的上百个卖力负载均衡的机器上,如果涌现配置下发不及时,或下发配置失落败,极大可能会涌现故障,同时,卖力均衡做事的机器对弹性能力的哀求较高,在业务高峰如果不能快速扩容,随意马虎涌现全网故障。
传统的配置下发办法是通过做事端下发文件更新配置,更新配置生效韶光长,由于须要预先知道卖力均衡集群的机器信息,扩缩容须要等元信息同步往后才能接入流量,扩容流量的接入韶光较长。
引入Nacos后,我们采取了配置中央监听办法,通过客户端主动监听配置更新,配置便可秒级生效,新扩容做事主动拉取全量配置,流量接入时长缩短3分钟+。
虎牙对 Nacos 改造和升级的总结引入Nacos的过程中,我们所做的改造和升级总结如下。
一是在DNS-F上,我们增加了对外部域名的预缓存的支持,Agent的监控数据对接到公司的内部监控,日志输出也对接到内部的日志做事,然后和公司的CMDB对接,并实现了DNS-F Cluster集群。我们之以是去构建一个DNS-FCluster集群,是为了避免内存、硬盘或版本问题导致的DNS做事无效,有了DNS-F Cluster集群,当本地Agent涌现问题的时候,就可以通过集群去代理和解析DNS要求。
二是在Nacos-Sync上,我们对接了TAF注册做事和K8S注册做事,以及办理了多数据中央环形同步的问题。
三是在Nacos CMDB上,我们对Nacos CMDB进行了扩展,对接了虎牙自己的CMDB,并对接了内部的负载均衡策略。
本文作者
张波,社区ID zhangjimmy,Nacos Committer,虎牙根本保障部中间件团队卖力人,阿里云MVP。
本文为云栖社区原创内容,未经许可不得转载。