域名动态解析_为什么选用Nacos？虎牙直播微服务改造实践

“

与文本和图片相比，实时广播提供了人们之间更丰富的沟通形式，对平台的稳定性进行了很好的测试。那么，Huya如何倡导“以技术为导向的娱乐”来赋予娱乐技术？

本文将分为以下各节，以在DNS，服务注册，CMDB和服务配置中心介绍Huya的实践：

为什么选择NACOS

Huya对NACOS的关注始于V0.2（最新版本：PER-GA V0.8）。我们还参加了社区的建设，可以说是相对较早的企业用户。

NACOS是一种动态服务发现，配置和服务管理平台，更容易帮助构建云本地应用程序，提供三个主要功能：注册中心，配置中心和动态DNS服务。

首先，在Huya的微服务方案中，首先有多个登记中心，每个注册中心都服务于微服务的某些部分，缺少一个可以集成多个注册中心并将它们连接到一个大型注册中心，然后实施一个可以管理整个微服务系统的大型注册中心的注册中心。

当我们考虑NACOS的引入时，从对服务注册计划的选择的比较中摘录了以下内容：

NACOS提供了DNS-F功能，可以与多个开源产品（例如K8S，Cloud和Dubbo）集成，以实现服务注册功能。

其次，在选择服务配置中心解决方案的过程中，我们希望可以连接配置中心和注册中心，这可以节省我们对微服务治理的投资。

因此，我们还同步比较了一些服务配置中心的开源解决方案：

例如，根据我们的微服务系统和业务方案的当前状态，Cloud和ETCD决定在我们的服务转换中使用NACO作为服务注册和服务发现的解决方案。

在使用过程中，我们发现，随着社区版本的持续更新和Huya的深入实践，NACOS的优势远远超出了我们在研究中的发现。

接下来，我将分享Huya的实践，围绕四个方面：DNS-F，NACOS-SYNC，CMDB和负载平衡。

DNS-F的技术价值和应用程序方案

DNS-F的技术价值

NACOS提供的DNS-F功能的第一个技术值是在没有我们内部微服务的全局动态调度能力的情况下弥补差距。

如前所述，Huya具有多个微服务系统，但是它们都没有能力进行全局动态调度，因为它们各自是独立的。

目前，我们已经通过NACOS整合了四个微服务登记中心。最终目标是将所有微服务集成在一起，以实现推动全球动态的能力。

其次，DNS-F解决了服务器末端所面临的挑战，即大延迟，不准确的分辨率和慢速故障牵引力的问题。

如何理解？当内部有多个微服务系统时，每个系统的成熟度不同。

例如，某些微服务框架不支持同一计算机室或CMDB路线。当一项服务在多个IDC中心注册并调用其服务时，即使在同一计算机室中，它也可能会调用不是同一计算机室的节点。

这将导致不合理的延误和服务的解决方案不准确。即使我们基于DNS进行了一些分辨率优化，我们仍然无法完全解决服务延迟和不准确的解决方案。

这是因为DNS是IP策略的附近解决方案，并且无法根据服务的身体状况和物理信息进行路由。

此外，当核心服务有问题时，如果缺少统一的注册中心，这些中心将来自多个呼叫者和被称为党派的信息组合在一起，则很难准确判断如何拉动，从而导致由于失败而导致牵引力缓慢。

使用NACOS，您可以访问统一的注册中心和配置中心来解决这些问题。 （目前，Huya仍在转换微服务系统，尚未完全实现统一的注册中心）

第三，提供专用的线路交通牵引功能。 Huya的核心计算机室的交通互操作性是使用专用行实现的。专用线的特征是物理上建立的，我们的专用线可能不如蝙蝠大。

例如，我们专用的线路容量的冗余仅为50％。假设某个实时流非常受欢迎，并且突然的流量比通常的水平高200倍，超过了专用线的施工能力，目前，服务可能会导致整个网络故障。

但是，通过全球注册中心和动员功能，我们可以将流量吸引到其他地方，例如迁移到公共网络，甚至牵引到不存在的地址以平衡它。即使某个服务有问题，它也不会影响我们的全球服务。

第四，它支持服务器上的各种调度需求，包括在同一计算机室中的路由，在同一台计算机中进行路由以及在同一机架中进行路由。 NACO可以适应。

此外，基于NACOS的DNS-F函数，我们还实现了外部域名分辨率和服务故障牵引力的加速，以在几秒钟内生效。

DNS-F应用程序方案

这张图是NACOS DNS-F的特定实现，该实现实际上是从OS层拦截DNS请求的。

如果通过DNS的域名是一项内部服务，它将从NACO中获得结果，如果没有，它将转发给其他解析的结果。

以高度可用的数据库为例，采用应用程序场景，我们的数据库切换效率相对较低，并且取决于业务团以修改配置，并且及时性不确定，这通常需要超过10分钟（注意：我们的数据库实际上已经实现了主要和备份功能，但是在启用了一个问题时，它始终是启用的，它始终是启用ip of ip。操作，维护和开发，这是一个相对较长的过程。

引入DNS后，当主人出现问题时，它可以快速用另一个主人的IP替换它以阻止故障。此外，节点的故障检测和故障转移可以自动完成，并且不依赖于操作，维护和开发的合作，从而节省了时间。

当然，这种情况有许多解决方案。例如，使用MySQL -代理也可以解决此问题，但是我们的MySQL -Proxy仍在构造中，并希望尽快解决此问题，因此我们使用DNS方法。

接下来，我们将专注于基于DNS-F对分享优化。 Huya尚未建立自己的建造，大多数人使用一些公共DN，大致包括以下内容。

这种组成方法将存在一个问题：假设服务突然崩溃，并且服务将立即正常，我们无法复制这种情况并找到崩溃的原因。

因为在许多情况下，它是由公共DNS请求超时甚至是解决方案故障引起的，因为无法保留现场，因此无法发现问题。

从我们的监视数据来看，DNS分辨率错误的比例约为1％，超时比率将更高。

这意味着，使用公共DNS时，该服务具有1％的超时或失败的机会。如果服务没有任何容错性，将会发生异常。

同时，一些公共DNS决议的延迟尚不确定。例如，在亚马逊上一些较差的节点上，它们的延迟将相对较高，平均30至40毫秒。

然后，我们基于DNS-F进行了一些优化，优化结果如下：

优化效果也反映在我们的风险控制服务中。平均延迟减少了10ms，服务超时比率降低了25％，从而降低了违反图片或文本的风险，但由于延迟或服务超时而不会审查。

服务注册实践

Huya的核心业务基于TARS（腾讯的微服务框架开源）。

TARS主要支持C ++，但对Java和PHP等开发语言的支持很差，这使得美国非C ++商务方对其进行称呼非常不舒服。

NACOS引入后，我们通过NACOS支持的DNS协议在服务发现过程中实现了完整语言的支持。

当然，NACOS不仅是注册表，还具有收敛多个数据中心并支持多个数据源的同步的能力。

例如，我们目前支持TAF（Huya中重要的微服务系统），NACOS本身以及K8S上的某些服务注册的同步。

同时，基于NACOS群集的双向同步函数（NACOS-SYNC），我们已经实现了两个国内可用性区域和多个外国可用性区域之间的数据值同步，最后实现了一个注册，并在多个位置可读。

NACOS-SYNC是一种事件机制，即，同步任务是由事件触发的，它可以灵活地启用和关闭要同步的任务，然后根据服务更改事件触发监视以确保实时性。最后，通过常规的全爆发同步事件，确保服务数据的最终一致性。

同时，NACOS-Sync还支持服务心跳维护，即多个数据中心的心跳，并且可以使用NACOS-Sync代理来实现远程同步。此外，它还支持心跳和同步任务的结合，以方便而灵活。

由于TAF上有成千上万的注册服务，因此同步的量特别大，因此我们在NACOS-Sync进行了一些转换，以实现通过任务 的数以万计服务的可用性保证。

转换步骤是首先根据服务定义任务为粒度，然后在多个碎片上分配任务负载，并最终通过单碎片和多个复制品确保任务可用性。

连接到CMDB以实现附近的访问

当该服务部署在多个计算机房间或多个区域时，跨区域的服务访问通常会被High延迟。城市计算机房间的典型网络延迟约为1毫秒，而整个城市的网络延迟约为30毫秒来，例如从上海到北京。

目前，一个自然的想法是服务消费者和服务提供商是否可以访问同一地区。

NACOS定义了一个SPI接口，其中包含与第三方CMDB一致的一些方法。

用户按照协议实现相应的SPI接口后，他将形成一个JAR软件包并将其放置在NACOS安装目录中。重新启动NACOS，使NACOS和CMDB的数据连接。

在实际实施过程中，我们连接到DNS-F中的TAF，在DNS-F上实现TAF的中央控制接口，并无缝连接到TAF的SDK。

DNS-F提供了缓存负载平衡和实例信息，而NACOS为负载平衡信息提供了查询接口。

服务配置实践

Huya的域名（）将连接到中国南部，中部和中国南部的多个IDC计算机室。每个计算机房间都会构建一个NGINX来进行负载平衡。负载平衡流量将通过专用行返回我们的后端服务器。

在此过程中，如果我们修改了中间配置，则需要将其发送到多个计算机房间中的数百台负载平衡机。

如果未及时发出配置，或者配置失败，则可能会失败。同时，负责平衡服务的机器对弹性功能有很高的要求。如果在业务峰值期间无法快速扩大容量，则很容易导致网络故障。

传统的配置发行方法是发布文件以通过服务器更新配置。更新配置需要很长时间才能生效。由于负责平衡群集的机器信息需要提前知道，因此缩放需要等到在访问流量之前同步元信息，并且长时间访问了容量的扩展流量。

引入NACOS后，我们采用了配置中心监视方法。通过客户端的活动监视配置更新，配置可以在几秒钟内生效。新的扩展服务会积极拉出完整的配置，交通访问时间缩短了3分钟 +。

NACOS转换和升级摘要

在引入NACO时，我们进行的转换和升级总结如下：

①在DNS-F上，我们增加了对外部域名预处理的支持。代理商的监视数据已连接到公司的内部监视，日志输出也连接到内部日志服务，然后连接到公司的CMDB，并实现了DNS-F群集。

我们构建DNS群集的原因是要避免由内存，硬盘或版本问题引起的DNS服务的无效。使用DNS-F群集，当本地代理存在问题时，我们可以通过群集代理和解决DNS请求。

②在NACOS-Sync上，我们与TAF注册服务和K8S注册服务联系，并解决了多DATA中心中环同步的问题。

③在NACOS CMDB上，我们扩展了NACOS CMDB，并连接到Huya自己的CMDB，并连接到内部负载平衡策略。