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

博主介绍:✌全网粉丝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,并且支持多种开源产品的集成,同时也为提供了一个管理整个微服务生态系统的中心。

心。

虎牙直播在微服务改造的实践总结_第1张图片

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

虎牙直播在微服务改造的实践总结_第2张图片

在当前技术发展的背景下,许多开发者都在关注和探索不同的配置中心(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的技术价值

虎牙直播在微服务改造的实践总结_第3张图片

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的应用场景

虎牙直播在微服务改造的实践总结_第4张图片

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

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

虎牙直播在微服务改造的实践总结_第5张图片

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

虎牙直播在微服务改造的实践总结_第6张图片

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

虎牙直播在微服务改造的实践总结_第7张图片

为了优化使用公共 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微服务开篇

你可能感兴趣的:(SpringCloud,微服务,java,spring,boot)