虎牙直播在微服务改造方面的实践和总结

相比文字和图片，直播提供了人与人之间更丰富的沟通形式，其对平台稳定性的考验很大，那么倡导“以技术驱动娱乐”的虎牙直播（如下简称“虎牙”）是如何在技术上赋能娱乐，本文将为您介绍虎牙在DNS、服务注册、CMDB和服务配置中心等方面的实践。

文章整理自虎牙基础保障部中间件团队负责人张波（社区ID：zhangjimmy）在Dubbo Meetup 广州站沙龙上的分享，阿里巴巴中间件受权发布，分享议题以下：

为何选用Nacos

DNS-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。

其余服务化改造实践：网易考拉在服务化改造方面的实践微众银行的金融级消息服务平台建设实践和思考消息规模超千亿，同程艺龙的消息系统建设实践滴滴出行基于RocketMQ构建企业级消息队列服务的实践