相对于文字和图片，直播提供了更丰富的人与人之间的交流形式，这对平台的稳定性是一个极大的考验，那么倡导“科技驱动娱乐”的虎牙直播如何技术赋能娱乐。本文将分为以下几个部分介绍虎牙在DNS、服务注册、CMDB和服务配置中心的实践：为什么选择NacosDNS-F技术价值及应用场景服务注册实践CMDB应用与实践服务配置实践Nacos改造升级总结为什么选择Nacos虎牙专注于Nacos从v0.2（***版本：Pre-GAv0.8）开始，我们也参与了社区的建设，可以说是比较早的企业用户。Nacos是一个动态的服务发现、配置和服务管理平台，更容易帮助构建云原生应用。提供注册中心、配置中心、动态DNS服务三大功能。首先，在虎牙的微服务场景中，最初有多个注册中心，每个注册中心服务于某一部分微服务。一直缺少一个可以集成多个注册中心，一个一个连接起来，然后实现一个可以管理整个微服务的大型服务系统的注册中心。以下内容摘自我们考虑引入Nacos时的服务注册方案选型对比：Nacos提供DNS-F功能，可与K8S、SpringCloud、Dubbo等多种开源产品集成，实现服务注册功能.其次，在服务配置中心方案的选择过程中，我们希望配置中心和注册中心能够打通，这样可以为我们节省一些微服务治理的投入。因此，我们也对比了一些服务配置中心的开源方案：如SpringCloudConfigServer、Zookeeper、ETCD。经过综合评估，结合我们微服务系统的现状和业务场景，我们决定使用Nacos作为我们服务改造场景中的服务进行注册和服务发现。在使用过程中，我们发现随着社区版本的不断更新和虎牙实践的深入，Nacos的优势远不止我们研究时发现的。接下来我将分享虎牙围绕DNS-F、Nacos-Sync、CMDB和负载均衡的实践。DNS-F的技术价值和应用场景Nacos提供的DNS-F功能的第一个技术价值就是弥补了我们内部微服务不具备全局动态调度能力的空白。刚才说了，虎牙有多个微服务系统，但是没有一个微服务具备全局动态调度的能力，因为它们都是独立的。目前我们已经通过Nacos整合了四个微服务系统的注册中心，最终目的是将所有的微服务整合在一起，实现全局动态调动的能力。其次，DNS-F解决了服务器面临的端到端挑战，即延迟长、解析不准确、故障牵引慢等问题。怎么理解呢？当内部有多个微服务系统时，每个系统的成熟度是不一样的。比如有些微服务框架不支持同机房或者CMDB路由。当一个服务注册到多个IDC中心并调用其服务时，即使在同一个机房??，也可能调用不在同一个机房??的服务。节点。这将不合理地导致服务延迟和分析不准确。即使我们基于DNS做一些解析优化，仍然不能完全解决服务延迟和解析不准确的问题。这是因为DNS是IP策略的最近解析，不能根据业务的物理状态和物理信息进行路由。另外，当一个核心服务出现问题时，如果缺少一个统一的注册中心，整合多个调用者和被调用者的信息，将难以准确判断如何拉取，导致拉取缓慢失败。有了Nacos，就可以接入统一的注册中心和配置中心来解决这些问题。（目前虎牙还在微服务体系改造中，还没有完全实现统一注册中心。）第三，提供专线流量牵引能力。虎牙核心机房的流量互通采用专线实现。专线的特点是物理建设，我们的专线建设可能没有BAT那么大。比如我们专线容量的冗余度只有50%。假设一场直播异常火爆，突发流量比平时高出200倍，超过了专线的建设能力。这时，一项服务可能会导致整个网络出现故障。但是，通过全局注册中心和动员能力，我们可以将流量引流到其他地方，比如迁移到公网，甚至可以引流到一个不存在的地址来平衡。即使某项服务出现问题，也不会影响我们的全球服务。第四，支持服务器端多种调度需求，包括同机房路由、同机路由、同机架路由。Nacos都可以适配。另外，基于Nacos的DNS-F功能，我们还实现了外部域名解析的加速和服务故障牵引的秒级效果。DNS-F的应用场景这张图是NacosDNS-F的具体实现，它实际上是在OS层拦截DNS请求。如果通过DNS的域名是内部服务，则从NacosServer获取结果，如果不是，则转发给其他LocalDNS解析。以数据库的高可用应用场景为例，我们的数据库切换效率比较低，依赖业务方修改配置，时效性不确定，一般需要10分钟以上（注：我们的数据库有其实实现了主备的功能，但是当一个主服务出现问题的时候，总是需要切换IP的。）在切换IP的过程中，依赖于运维和开发的配合，就是一个比较长的过程。引入DNS后，当master出现问题时，可以快速更换为另一个master的IP，起到屏蔽故障的作用，自动完成节点的故障检测和故障转移，无需依赖运维人员的配合维护开发，节省时间。当然，这个场景有很多解决方案。比如使用MySQL-Proxy也可以解决这个问题，但是我们的MySQL-Proxy还在建设中，想尽快解决这个问题，所以就使用了DNS。接下来重点分享LocalDNS基于DNS-F的优化。虎牙目前还没有搭建自己的LocalDNS，大部分使用的是一些公有的DNS，大致有以下几个组成部分。这种组合方式存在一个问题：假设服务突然崩溃，然后服务立即恢复正常。我们无法重现这种情况来找出崩溃的原因。因为在很多场景下，是公共DNS请求超时，甚至是解析失败导致的。那个时候，因为站点无法保存，所以找不到问题。根据我们的监控数据，DNS解析错误的比例达到1%左右，超时的比例会更高。这意味着在使用公共DNS的情况下，有1%的几率服务会超时或失败。如果服务不是容错的，就会发生异常。同时，部分公共DNS解析的延迟存在不确定性。比如亚马逊上一些较差的节点会有比较高的延迟，平均在30到40毫秒以上。然后我们基于DNS-F对LocalDNS做了一些优化，优化结果如下：平均解析时间从之前的200多毫秒减少到不到2毫秒。缓存效率从92%提高到99%以上。之前解析失败率为1%，现在基本没有了。优化的效果也体现在我们的风控服务上。平均延迟降低10ms，服务超时率降低25%，降低用户上传的图片或文字因延迟或服务超时等违规而未被审核的风险。服务注册实践虎牙核心业务运行在Tars（腾讯开源的微服务框架）之上。Tars主要支持C++，但是对Java、PHP等开发语言的支持比较差，导致我们非C++的业务方调用起来比较尴尬。引入Nacos后，我们在服务发现过程中使用Nacos支持的DNS协议来支持所有语言。当然，Nacos不仅仅是一个注册中心，它具备整合多个数据中心的能力，支持多个数据源的同步。比如我们目前支持同步Taf（虎牙内部重要的微服务系统），Nacos本身，ZooKeeper，以及一些服务在K8S上的注册。同时，基于Nacos集群的双向同步功能（Nacos-Sync），我们实现了国内两个可用区和国外多个可用区之间数据值的同步，最终实现了一次注册和多位置可读性。Nacos-Sync是一种事件机制，即同步任务由事件触发，可以灵活开启和关闭你要同步的任务，然后根据服务变化事件触发监听，保证实时性。保证业务数据的最终一致性。同时Nacos-Sync还支持服务心跳维护，即多个数据中心的心跳，可以使用Nacos-Syncagent实现远程同步。另外还支持心跳和同步任务绑定，灵活控制。由于Taf上有上万个注册服务，同步量特别大，所以我们在Nacos-Sync上做了一些改动，通过任务分片来实现上万个服务同步的可用性保证。改造步骤是在服务的粒度上定义任务，然后将任务负载分散到多个分片上，最后使用单个分片的多个副本来保证任务可用性。与CMDB对接，实现就近访问当业务部署在多个机房或多个地域时，跨地域的业务访问往往存在较高的延迟。一个城市的机房典型的网络延迟在1ms左右，而跨城市的网络延迟，比如上海到北京需要30ms左右。这时候一个很自然的想法就是服务消费者和服务提供者是否可以访问同一个区域。Nacos定义了一个SPI接口，其中包含了一些与第三方CMDB约定的方法。用户按照约定实现相应的SPI接口后，将实现打成Jar包放在Nacos安装目录下，重启Nacos即可连接Nacos和CMDB数据。在实际落地过程中，我们将Taf接入DNS-F，在DNS-F上实现了Taf的中控接口，并无缝对接了Taf的SDK。DNS-F提供缓存负载均衡和实例信息，Nacos提供负载均衡信息的查询接口。服务配置实践虎牙域名（www.huya.com）将接入华南、华中、华北多个IDC机房。每个机房都会搭建一个Nginx做负载均衡，负载均衡后的流量通过专线返回给我们。在后端服务器上。在这个过程中，如果我们在中间修改了一个配置，需要发到多个机房的几百台机器上负责负载均衡。如果没有及时下发配置，或者配置下发失败，很可能会出现故障。同时，负责均衡服务的机器对灵活性有很高的要求。如果在业务高峰期不能快速扩容，很容易出现全网故障。传递配置的传统方式是通过从服务器发送文件来更新配置。更新的配置需要很长时间才能生效。由于需要提前知道负责均衡集群的机器信息，所以扩缩容需要等待元信息同步后才能访问流量。访问时间长。引入Nacos后，我们采用了配置中心的监控方式。通过客户端主动监听配置更新，配置秒级生效。新扩容服务主动拉动全量配置，流量接入时间缩短3分钟+。Nacos改造升级总结在引入Nacos的过程中，我们所做的改造升级总结如下：①在DNS-F上，增加了对外部域名预缓存的支持，Agent的监控数据接入到公司内部监控，日志输出也连接到内部日志服务，再连接到公司的CMDB，实现DNS-FCluster。我们之所以搭建DNS-FCluster集群，是为了避免内存、硬盘或版本问题导致DNS服务失效。有了DNS-FCluster集群，当本地Agent出现问题时，可以使用集群来代理解析DNS请求。②在Nacos-Sync上，我们打通了TAF注册服务和K8S注册服务，解决了多数据中心环同步的问题。③在NacosCMDB上，我们对NacosCMDB进行了扩展，对接了虎牙自有的CMDB，对接了内部的负载均衡策略。
