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

博主介绍：✌全网粉丝4W+，全栈开发工程师，从事多年软件开发，在大厂呆过。持有软件中级、六级等证书。可提供微服务项目搭建与毕业项目实战、定制、远程，博主也曾写过优秀论文，查重率极低，在这方面有丰富的经验✌

博主作品：《Java项目案例》主要基于SpringBoot+MyBatis/MyBatis-plus+MySQL+Vue等前后端分离项目，可以在左边的分类专栏找到更多项目。《Uniapp项目案例》有几个有uniapp教程，企业实战开发。《微服务实战》专栏是本人的实战经验总结，《Spring家族及微服务系列》专注Spring、SpringMVC、SpringBoot、SpringCloud系列、Nacos等源码解读、热门面试题、架构设计等。除此之外还有不少文章等你来细细品味，更多惊喜等着你哦

🍅开源项目免费哦：点击这里克隆或者下载 ，已经发布Vue3版   🍅

🍅文末获取联系🍅精彩专栏推荐订阅👇🏻👇🏻 不然下次找不到哟

Java项目案例《100套》

uniapp小程序《100套》

目录

一、为什么选择Nacos

二、DNS-F的技术价值

三、DNS-F的应用场景

四、DNS-F在数据库场景的落地

💖微服务实战

---

一、为什么选择Nacos

虎牙关注 Nacos 是从 v0.2 开始的，也参与了社区的建设，可以说是最早期的企业用户。

在虎牙的微服务场景中，原先存在多个注册中心，每个注册中心服务于不同的微服务部分，导致缺少一个能够整合这些注册中心，并将它们逐一打通的大型注册中心来管理整个微服务生态系统。因此，考虑使用Nacos作为服务注册中心，以下是考虑使用Nacos的原因：
1. 相比其他方案，Nacos可以与多个开源产品集成，例如k8s，spring cloud和dubbo, 并使用dns-f作为agent，因此不需要额外的配置或本地安装agents或SDK。
2. Tseer Agent, Consul等方案需要本地安装agents或SDK，且他们仅仅提供限定的接口，因此，它们不太适合支持不同的开源产品。
3. K8s使用coreDNS来查询IP地址,但为集群配置单个DNS，因此无法管理整个微服务生态系统，而Nacos则可以用来管理整个微服务生态系统。
4. Spring Cloud的大部分功能需要深度集成SDK中才能实现，这使得它难以支持其他语言。
5. L5是腾讯内部的服务发现方案，同样需要本地安装L5 agent，向L5 DNS获取到服务数据，因此也不能适应不同的开源产品。 综上，我们认为使用Nacos作为服务注册中心是一个非常好的选择，因为它可以通过dns-f作为agent，并且支持多种开源产品的集成，同时也为提供了一个管理整个微服务生态系统的中心。

心。

Nacos支持DNS-F功能，可以集成多个开源产品（如K8S、Spring Cloud和Dubbo）以实现服务的注册。在选择服务配置中心方案时，希望能够打通配置中心和注册中心，以省去在微服务治理方面的投入。因此，还比较了几个服务配置中心的开源方案

在当前技术发展的背景下，许多开发者都在关注和探索不同的配置中心（Configuration Center），如Nacos、Spring Cloud Config Server、ZooKeeper和Etcd等。这些工具通过提供一个中心化存储器和API接口，使得配置修改、版本管理和配置推送等功能变得更加高效。 虽然这些配置中心都有着其独特的优势，但是它们同时也存在一些不同的缺点。
下面将这些配置中心进行优缺点对比：
- Nacos： Nacos提供一个直接在控制台上进行配置修改的功能，并且修改的配置能够自动推送到监听的客户端。同时，它还支持多种API接口（RESTful API，Java Native接口，Spring Cloud接口等），并且能够自动记录各个修改的版本信息，便于追踪和管理。总的来说，Nacos具有易用性高、扩展性强、功能丰富等特点。
- Spring Cloud Config Server： Spring Cloud Config Server需要使用Git仓库进行配置修改，并且客户端只能在启动的时候加载。虽然它也支持多种API接口和其他语言客户端，但是在版本管理方面相对比较弱。总的来说，Spring Cloud Config Server适用于Web应用程序，特别是基于Spring的应用程序。
- ZooKeeper： ZooKeeper是一个支持Java原生接口的配置中心，同时提供配置自动推送的功能。但是，它没有自动记录版本信息和配置推送历史等功能，需要通过调用ZK API进行相应的修改。总的来说，ZooKeeper适用于分布式系统的管理和控制。
- Etcd： Etcd通过提供RESTful API进行配置修改，并且修改的配置能够自动推送到监听的客户端。但是，它也没有自动记录版本信息和配置推送历史等功能，且也需要通过调用来Etcd API进行相应的修改。总的来说，Etcd适用于基于容器的云原生应用程序和大规模分布式系统。 基于以上对比和综合分析，建议选择Nacos作为配置中心。因为它不仅易于使用和扩展，而且具有较强的版本管理和配置推送追踪能力，适合各种类型的应用程序
针对微服务体系现状以及业务场景，在诸多可选服务注册和服务发现的方案中，综合对比了Spring Cloud Config Server、Zookeeper 和 ETCD，最终选择了Nacos。在使用过程中，发现Nacos的优势远比调研过程中发现的更多。下面，将以DNS-F、Nacos-Sync、CMDB 和负载均衡为例，分享虎牙的实践

二、DNS-F的技术价值

Nacos提供的DNS-F功能带来的技术价值有以下四个方面。
首先，DNS-F功能填补了内部微服务缺乏全局动态调度能力的空白。相比之下，多个微服务体系之间缺乏独立和协同操作能力，需要借助Nacos来融合注册中心以使微服务体系之间实现全局动态调度。
其次，DNS-F解决了服务端内部面临的挑战，包括延时、解析不准和故障牵引慢的问题。在具体应用时，一些微服务框架并不支持同机房或者CMDB路由。在一个服务被注册到多个IDC中心后，即使在同一机房内，也可能调用不同机房的节点，导致无端延迟和解析不准。即使在DNS解析优化之后，也不可能解决全部 延时和解析不准问题，因为DNS只是IP策略的近地解析，并不能根据服务的物理状态和物理信息进行路由，同时缺乏统一的注册中心，当核心服务出现异常问题时，难以准确判断如何进行故障牵引，从而导致故障牵引慢。连接Nacos的全局注册中心和配置中心可以解决这些问题。（目前，虎牙还在微服务体系的改造过程中，未完全实现统一的注册中心）
第三，DNS-F功能提供了专线流量牵引能力，解决了核心机房流量互通的问题。专线特有的物理建设特性和专线容量的冗余只有50%的情况下，某个服务可能出现突发流量大于平时两百倍的情况，超出专线的建设能力，从而可能导致全网故障。但是，通过Nacos的全局注册中心和调度能力，可以将流量牵引到其他地方，例如迁移到公网或者牵引到一个不存在的地址来平衡流量。某个服务出现问题，也不会影响全局服务。
第四，DNS-F功能支持服务端的多种调度需求，包括同机房路由、同机器路由，以及同机架路由。同时，基于Nacos的DNS-F功能，还实现了外部域名解析的加速和服务故障牵引的秒级生效。

三、DNS-F的应用场景

该图描绘了 Nacos DNS-F 的实际运作。它通过拦截 OS 层的 DNS 请求来处理域名。当 DNS 请求的域名属于内部服务时，Nacos DNS-F会从 Nacos Server 获取结果。如果域名并非内部服务，Nacos DNS-F 将会将其转发给其他 LocalDNS 完成解析。

四、DNS-F在数据库场景的落地

以数据库高可用的应用场景为例，数据库切换效率较低，依赖业务方手动修改配置，时效不确定，通常需要10分钟以上。尽管数据库已经实现了主备功能，但当主服务出现问题而需切换IP时，仍需要时间与运维和开发协作。 为了解决这个问题，我们引入DNS技术。DNS可快速使用备用主机的IP地址进行切换，屏蔽故障，同时自动实现故障检测和故障切换，无需运维和开发协作，节省宝贵时间。此外，也可使用MySQL-Proxy等其他场景适用的解法，但MySQL-Proxy还在建设中，使用DNS技术是目前最为合适的解决方案。 最后，分享基于DNS-F对LocalDNS的优化。目前还没有建设自己的LocalDNS，而是使用公共的DNS，大致有以下组成部分。

在应用程序中，使用公共 DNS 能够带来某些好处。然而，这种组成方式存在一个问题：如果服务突然崩溃然后又马上恢复，我们将无法重现崩溃原因。这是因为在许多情况下，请求超时或解析失败是由公共 DNS 引起的。由于无法保留现场信息，导致难以发现问题。 根据我们的监测数据，使用公共 DNS时，DNS 解析错误率约为1‰，而超时比例则更高。这意味着如果服务没有做好容错处理，服务会出现异常。值得注意的是，许多公共 DNS 解析节点的延迟是不稳定的，导致解析延迟相差较大。比如在亚马逊上部分不良节点，解析延迟平均超过三四十毫秒。

为了优化使用公共 DNS 所带来的问题，我们针对本地DNS基于DNS-F进行了一系列优化。
优化效果如下：
● 平均解析时间从之前超过两百毫秒降低至两毫秒以下；
● 缓存命中率从92%提升至99%以上；
● 解析失败率之前为1‰，现在基本上没有了。
这些优化效果还体现在我们的风控服务上。平均延迟与异常比例分别降低了10毫秒和25%，有效降低了因延迟或服务超时导致用户上传的图片或文字违规事件。

💖微服务实战

✨【微服务】SpringCloud的OpenFeign与Ribbon配置

✨集Oauth2+Jwt实现单点登录

✨Spring Cloud Alibaba微服务第29章之Rancher

✨Spring Cloud Alibaba微服务第27章之Jenkins

✨Spring Cloud Alibaba微服务第24章之Docker部署

✨Spring Cloud Alibaba微服务第23章之Oauth2授权码模式

✨Spring Cloud Alibaba微服务第22章之Oauth2

✨Spring Cloud Alibaba微服务第21章之分布式事务

✨Spring Cloud Alibaba微服务第18章之消息服务

✨Spring Cloud Alibaba微服务第16章之服务容错

✨Spring Cloud Alibaba微服务第14章之分库分表

✨Spring Cloud Alibaba微服务第11章之MyBatis-plus

✨Spring Cloud Alibaba微服务第8章之OpenFeign

✨Spring Cloud Alibaba微服务第7章之负载均衡Ribbon

✨SpringCloud Alibaba微服务第6章之Gateway

✨SpringCloud Alibaba微服务第4章之Nacos

✨SpringCloud Alibaba微服务开篇