虎牙直播在微服务改造方面的实践和总结
相比文字和图片,直播提供了人与人之间更丰富的沟通形式,其对平台稳定性的考验很大,那么倡导“以技术驱动娱乐”的虎牙直播(以下简称“虎牙”)是如何在技术上赋能娱乐,本文将为您介绍虎牙在DNS、服务注册、CMDB和服务配置中心等方面的实践。为什么选用Nacos
以下内容摘自我们考虑引入Nacos时,在服务注册中心方案上的选型对比:
Nacos提供DNS-F功能, 可以与Kubernetes、Spring Cloud和Dubbo等多个开源产品进行集成,实现服务的注册功能。
其次,在服务配置中心方案的选型过程中,我们希望配置中心和注册中心能够打通,这样可以省去我们在微服务治理方面的一些投入。因此,我们也同步比较了一些服务配置中心的开源方案:
例如Spring Cloud Config Server、ZooKeeper和etcd,总体评估下来,基于我们微服务体系现状以及业务场景,我们决定使用Nacos作为我们的服务注册和服务发现的方案。使用过程中,我们发现,随着社区版本的不断更新和虎牙的深入实践,Nacos的优势远比我们调研过程中发现的更多,接下来,我将围绕DNS-F、Nacos-Sync、 CMDB和负载均衡4方面来分享虎牙的实践。
第二,DNS-F解决了服务端端到端面临的挑战,即延时大、解析不准、故障牵引慢的问题。
如何去理解呢?
当内部有多个微服务体系的时候,每一个体系的成熟度是不同的。例如,有一些微服务框架对同机房或CMDB路由是不支持的,当一个服务注册到了多个IDC中心,去调用它的服务的时候,即便是同机房,也可能调用到一个不是同机房的节点。这样就会无端的造成服务的延时和解析不准。
即使我们基于DNS做一些解析的优化,但仍然无法完全解决服务的延时和解析不准。这是因为DNS都是IP策略的就近解析,无法根据服务的物理状态、物理信息进行路由。此外,当一个核心服务出现问题,如果缺少一个融合了多个调用方和被调用方的信息的统一的注册中心,就很难去准确判断如何去牵引,从而导致故障牵引慢。有了Nacos后,就可以接入一个统一的注册中心以及配置中心,去解决这些问题。(目前,虎牙还在微服务体系的改造过程中,未完全实现统一的注册中心)
第三,提供专线流量牵引能力。虎牙的核心机房的流量互通,是使用专线来实现的。专线的特性就是物理建设的,而且我们的专线建设可能不像BAT那么大,例如我们专线容量的冗余只有50%,假设某个直播异常火爆,突发流量高于平常的两百倍,超过了专线的建设能力,这时候一个服务就有可能会导致全网故障。但是,通过全局的注册中心和调动能力,我们就可以把流量牵引到其他地方,例如迁移到公网,甚至牵引到一个不存在的地址,来平衡一下。即便某个服务出现问题,也不会影响我们的全局服务。
第四,支持服务端的多种调度需求,包括同机房路由、同机器路由,以及同机架路由,Nacos都可以去做适配。此外,基于Nacos 的DNS-F功能,我们还实现了加速外部域名解析和服务故障牵引秒级生效。
以数据库高可用的应用场景为例,我们的数据库切换效率比较低,依赖业务方修改配置,时效不确定,通常需要10分钟以上(备注:我们的数据库实际上已经实现了主备的功能,但当一个主服务出现问题的时候,总是要去切换IP。)切换IP的过程中,依赖运维和开发的协作,这是一个比较长的过程。
引入DNS后,当主出现问题的时候,就可以很快的用另外一个主的IP来进行替换,屏蔽故障,而且节点的故障检测和故障切换都可以自动完成,并不依赖运维和开发的协作,节省了时间。当然,这个场景的解法有很多,比如说使用MySQL - Proxy也可以去解这个问题,但我们的MySQL - Proxy还在建设中,想尽快的把这个问题解决,所以采用了DNS的方式。
下面我们再着重分享下基于DNS-F对LocalDNS的优化。虎牙还没有去建设自己的LocalDNS,大部分使用的是一些公共的DNS,大致有以下这些组成。
这种组成方式会存在一个问题。假设服务突然一下崩溃后,之后服务又马上正常了,这种情况我们无法重现去找到崩溃原因。因为很多场景下,是一个公共DNS的请求超时导致的,甚至一个解析失败导致的,在那一刻,因为无法保留现场的,所以就发现不了问题。
以我们的监测数据来看,DNS解析错误的比例达到1‰左右,超时比例将更高。意思是在使用公共DNS的情况下,服务有1‰的几率是会超时或失败,如果服务没有做好容错,就会出现异常。同时,一些公共DNS解析的延时都是不定的,比如在亚马逊上一些比较不好的节点,它的延时会比较高,平均超过三四十毫秒。
然后我们基于DNS-F对LocalDNS做了一些优化。优化结果如下:
当然,Nacos不只是一个注册中心,它具备了融合多个数据中心的能力,支持多数据源的同步,例如,我们目前已经支持了Taf(虎牙内部的一个重要微服务体系)、Nacos自身、ZooKeeper、以及Kubernetes上一些服务注册的同步。
同时,基于Nacos集群的双向同步功能(Nacos-Sync),我们实现了国内的两个可用区,以及国外的多个可用区之间的数据值同步,最终实现了一处注册、多地可读。
Nacos-Sync是事件机制,即同步任务通过事件触发,可以灵活地开启和关闭你要同步的任务,然后根据服务变化事件触发监听,保证实时性,最后通过定时的全量突发同步事件,保证服务数据的最终一致。同时,Nacos-Sync也支持服务心跳维持,即多个数据中心的心跳,可以使用Nacos-Sync代理要来实现远端同步。此外,也支持心跳与同步任务绑定,便于灵活控制。
由于Taf上有数万个注册服务,同步的量特别大,所以我们在Nacos-Sync做了一些改造,通过任务分片来实现数万服务同步的可用性保障。改造步骤是先以服务为粒度定义任务,然后在多个分片上分散任务负载,最后以单分片多副本来保证任务可用性。
Nacos定义了一个SPI接口,里面包含了与第三方CMDB约定的一些方法。用户依照约定实现了相应的SPI接口后,将实现打成Jar包放置到Nacos安装目录下,重启Nacos即可让Nacos与CMDB的数据打通。
在实际的落地过程中,我们是在DNS-F接入Taf,在DNS-F上实现Taf的中控接口,无缝对接Taf的SDK。DNS-F提供缓存负载均衡和实例信息,Nacos则提供负载均衡信息的查询接口。
传统的配置下发方式是通过服务端下发文件更新配置,更新配置生效时间长,由于需要预先知道负责均衡集群的机器信息,扩缩容需要等元信息同步以后才能接入流量,扩容流量的接入时间较长。
引入Nacos后,我们采用了配置中心监听方式,通过客户端主动监听配置更新,配置便可秒级生效,新扩容服务主动拉取全量配置,流量接入时长缩短3分钟+。
一是在DNS-F上,我们增加了对外部域名的预缓存的支持,Agent的监控数据对接到公司的内部监控,日志输出也对接到内部的日志服务,然后和公司的CMDB对接,并实现了DNS-F Cluster集群。我们之所以去构建一个DNS-FCluster集群,是为了避免内存、硬盘或版本问题导致的DNS服务无效,有了DNS-F Cluster集群,当本地Agent出现问题的时候,就可以通过集群去代理和解析DNS请求。
二是在Nacos-Sync上,我们对接了TAF注册服务和Kubernetes注册服务,以及解决了多数据中心环形同步的问题。
三是在Nacos CMDB上,我们对Nacos CMDB进行了扩展,对接了虎牙自己的CMDB,并对接了内部的负载均衡策略。
本文转载自公众号:阿里巴巴中间件,点击查看原文。
以下内容摘自我们考虑引入Nacos时,在服务注册中心方案上的选型对比:
Nacos提供DNS-F功能, 可以与Kubernetes、Spring Cloud和Dubbo等多个开源产品进行集成,实现服务的注册功能。
其次,在服务配置中心方案的选型过程中,我们希望配置中心和注册中心能够打通,这样可以省去我们在微服务治理方面的一些投入。因此,我们也同步比较了一些服务配置中心的开源方案:
例如Spring Cloud Config Server、ZooKeeper和etcd,总体评估下来,基于我们微服务体系现状以及业务场景,我们决定使用Nacos作为我们的服务注册和服务发现的方案。使用过程中,我们发现,随着社区版本的不断更新和虎牙的深入实践,Nacos的优势远比我们调研过程中发现的更多,接下来,我将围绕DNS-F、Nacos-Sync、 CMDB和负载均衡4方面来分享虎牙的实践。
第二,DNS-F解决了服务端端到端面临的挑战,即延时大、解析不准、故障牵引慢的问题。
如何去理解呢?
当内部有多个微服务体系的时候,每一个体系的成熟度是不同的。例如,有一些微服务框架对同机房或CMDB路由是不支持的,当一个服务注册到了多个IDC中心,去调用它的服务的时候,即便是同机房,也可能调用到一个不是同机房的节点。这样就会无端的造成服务的延时和解析不准。
即使我们基于DNS做一些解析的优化,但仍然无法完全解决服务的延时和解析不准。这是因为DNS都是IP策略的就近解析,无法根据服务的物理状态、物理信息进行路由。此外,当一个核心服务出现问题,如果缺少一个融合了多个调用方和被调用方的信息的统一的注册中心,就很难去准确判断如何去牵引,从而导致故障牵引慢。有了Nacos后,就可以接入一个统一的注册中心以及配置中心,去解决这些问题。(目前,虎牙还在微服务体系的改造过程中,未完全实现统一的注册中心)
第三,提供专线流量牵引能力。虎牙的核心机房的流量互通,是使用专线来实现的。专线的特性就是物理建设的,而且我们的专线建设可能不像BAT那么大,例如我们专线容量的冗余只有50%,假设某个直播异常火爆,突发流量高于平常的两百倍,超过了专线的建设能力,这时候一个服务就有可能会导致全网故障。但是,通过全局的注册中心和调动能力,我们就可以把流量牵引到其他地方,例如迁移到公网,甚至牵引到一个不存在的地址,来平衡一下。即便某个服务出现问题,也不会影响我们的全局服务。
第四,支持服务端的多种调度需求,包括同机房路由、同机器路由,以及同机架路由,Nacos都可以去做适配。此外,基于Nacos 的DNS-F功能,我们还实现了加速外部域名解析和服务故障牵引秒级生效。
以数据库高可用的应用场景为例,我们的数据库切换效率比较低,依赖业务方修改配置,时效不确定,通常需要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‰,现在基本上没有了。
当然,Nacos不只是一个注册中心,它具备了融合多个数据中心的能力,支持多数据源的同步,例如,我们目前已经支持了Taf(虎牙内部的一个重要微服务体系)、Nacos自身、ZooKeeper、以及Kubernetes上一些服务注册的同步。
同时,基于Nacos集群的双向同步功能(Nacos-Sync),我们实现了国内的两个可用区,以及国外的多个可用区之间的数据值同步,最终实现了一处注册、多地可读。
Nacos-Sync是事件机制,即同步任务通过事件触发,可以灵活地开启和关闭你要同步的任务,然后根据服务变化事件触发监听,保证实时性,最后通过定时的全量突发同步事件,保证服务数据的最终一致。同时,Nacos-Sync也支持服务心跳维持,即多个数据中心的心跳,可以使用Nacos-Sync代理要来实现远端同步。此外,也支持心跳与同步任务绑定,便于灵活控制。
由于Taf上有数万个注册服务,同步的量特别大,所以我们在Nacos-Sync做了一些改造,通过任务分片来实现数万服务同步的可用性保障。改造步骤是先以服务为粒度定义任务,然后在多个分片上分散任务负载,最后以单分片多副本来保证任务可用性。
Nacos定义了一个SPI接口,里面包含了与第三方CMDB约定的一些方法。用户依照约定实现了相应的SPI接口后,将实现打成Jar包放置到Nacos安装目录下,重启Nacos即可让Nacos与CMDB的数据打通。
在实际的落地过程中,我们是在DNS-F接入Taf,在DNS-F上实现Taf的中控接口,无缝对接Taf的SDK。DNS-F提供缓存负载均衡和实例信息,Nacos则提供负载均衡信息的查询接口。
传统的配置下发方式是通过服务端下发文件更新配置,更新配置生效时间长,由于需要预先知道负责均衡集群的机器信息,扩缩容需要等元信息同步以后才能接入流量,扩容流量的接入时间较长。
引入Nacos后,我们采用了配置中心监听方式,通过客户端主动监听配置更新,配置便可秒级生效,新扩容服务主动拉取全量配置,流量接入时长缩短3分钟+。
一是在DNS-F上,我们增加了对外部域名的预缓存的支持,Agent的监控数据对接到公司的内部监控,日志输出也对接到内部的日志服务,然后和公司的CMDB对接,并实现了DNS-F Cluster集群。我们之所以去构建一个DNS-FCluster集群,是为了避免内存、硬盘或版本问题导致的DNS服务无效,有了DNS-F Cluster集群,当本地Agent出现问题的时候,就可以通过集群去代理和解析DNS请求。
二是在Nacos-Sync上,我们对接了TAF注册服务和Kubernetes注册服务,以及解决了多数据中心环形同步的问题。
三是在Nacos CMDB上,我们对Nacos CMDB进行了扩展,对接了虎牙自己的CMDB,并对接了内部的负载均衡策略。
本文转载自公众号:阿里巴巴中间件,点击查看原文。