哔哩哔哩直播架构 8 年演进:从 0 到千万在线的微服务系统

[复制链接]
查看50 | 回复0 | 2024-11-7 06:03:33 | 显示全部楼层 |阅读模式
在当前迅猛发展的科技行业,企业技术的创新和能力增强成为了一个核心议题。众多企业在技术进步的道路上持续寻求创新,不断试验新的技术架构和服务模式。这些举措旨在应对业务日益复杂化的挑战以及不断扩张的市场需求。

日益壮大的微服务框架

在技术进步中,服务框架的开发扮演着关键角色。Swoole被企业用作基础,打造了专有的微服务框架。该框架集成了服务进程管理、平稳重启、对象关系映射(ORM)、缓存、日志记录等多项功能。以[具体时间]为例,该框架的诞生是开发团队数月辛勤工作的成果。业务开发者只需参照模板编写controller和service代码即可开始工作,此举显著提升了开发速度。该框架的引入,颠覆了[企业名称]过往繁琐的开发流程,过去构建一个应用可能需数周来搭建基础,而现在可能只需几天即可完成。

这种微服务框架是否能够应对未来愈发复杂的业务场景,已成为众多行业人士关注的焦点问题。

统一网关开发的必要性

鉴于企业面临限流与降级功能不足的问题,独立研发了一款名为live-api的网关服务。此服务规定所有外部请求必须经其转发至对应业务系统。开发团队指出,在先前业务运行期间,缺乏此类统一网关,一旦遭遇流量激增,系统便易崩溃。在[特定时间段],遭遇了大规模流量冲击,由于缺乏统一限流措施,导致多业务中断达数小时。自[具体上线时间]以来,实施live-api网关服务后,此类状况已得到显著改善,业务稳定性得到有效保障。

针对此类网关在处理超大规模流量时的零故障性能,其可行性是否得以保证,实为一个值得深入研究的课题。

数据库拆分及带来的变化

企业携手DBA成功实施了直播数据库的在线拆分项目。此前,所有业务表均集中在单一数据库中,存储层的混合使用存在较高的风险。自[具体时间起]至[具体时间止]的期间,技术团队经过详尽的研究与测试,将业务表分散至独立的数据库。此举相当于对既有的“老路”进行了全面升级与改造。拆分完成后,存储层混用的风险得以消除,系统整体性能得到显著提升。以往,由于存储层的复杂性,查询一条关键数据可能需耗时2至3秒,而拆分后,这一时间缩短至0.5至1秒。

这种数据库拆分方法是否适合其他相关业务?

PHP服务扩容的压力与解决方案

在PHP服务进行扩容过程中,数据库与缓存连接数承受较大压力。昔日技术架构尚不成熟之际,因缺乏成熟的数据库代理,各PHPWorker直接与数据库连接,导致连接数无序增长。以某业务高峰期为例,连接数一度超出正常水平的五倍以上。这一状况显著制约了PHP服务的扩容潜力。为应对此问题,技术团队持续寻求创新技术解决方案。

如何在保障现有业务正常运行的情况下,寻求一种更高效的策略来缓解PHP服务的扩容压力?

业务网关设计及其特性

直播首页及房间页场景下,业务逻辑相当繁复,客户端往往需要调用多达十个以上的接口,其中部分接口存在时序依赖。企业在业务网关设计上推行了创新,成功实现了热点数据主动缓存以及下游服务异常自动降级等功能。以某次直播活动为例,直播间流量在活动期间突然激增,得益于自动降级特性,尽管个别接口出现波动,但整体业务并未受到影响而中断。

这种业务网关的设计模型能够推广到其他企业吗?

Golang服务的优势和成果

在服务试点过程中,我们发现Golang服务的接口耗时和稳定性显著优于PHP服务。尤其在网关需要整合十余个下游数据时,Golang利用协程并发技术,使得接口平均耗时仅为PHP服务的一半以下。这一性能优势已在[实际测试时间]的性能对比测试中得到证实。此外,在Golang服务构建过程中,我们还简化了热门房间检测逻辑,并开发出了热门房间SDK。该SDK便于业务服务进行相关判断。

Golang服务是否能够彻底取代PHP服务,成为主流技术?我们诚挚邀请广大读者参与讨论,点赞、分享,并在评论区发表您的见解。
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则