您现在的位置是:首页 >学无止境 >虎牙直播在微服务改造的实践总结网站首页学无止境

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

卡布奇诺-海晨 2024-06-17 10:48:58
简介虎牙直播在微服务改造的实践总结

博主介绍:✌全网粉丝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微服务开篇

风语者!平时喜欢研究各种技术,目前在从事后端开发工作,热爱生活、热爱工作。