查看原文
科技

“网关日调用从1千到1亿”,项目背后我的十年开发心得

付志远 腾讯云开发者 2024-02-21


👉导读

负责的网关日调用量从1千到1亿,具备独立完成千万 DAU 产品的技术能力,我用了整整 10 年。这个过程,我走了很多弯路,也学到了很多东西。这些东西,我想和大家分享。你缺少的不是道理,而是理解道理的机缘,静水流深虚心沉淀,属于你的时刻终会到来!

👉目录

1 前言2 业务背景:技术选择直接影响着我们的工作效率和产品质量3 整体架构:如果存在一种捷径,那就是难路4 方案对比:不要在很差的基础上,拼命做优化5 核心难点:每一个细小问题的解决都是产品护城河的加深

  • 所有捷径都是弯路:任何技能都是积累输入到一定程度和量级后的“自然涌现”;
  • 细节即是护城河
  • 无反馈、不迭代,只有具备反馈机制,迭代才不是摆设,才能真正服务于用户;
  • 面向通用场景做到极致很难,但永远可以在具体场景下做到更极致
  • 不要在很差的基础上,拼命做优化。给火车做提速,不如直接做飞机。
  • 技术选择直接影响着我们的工作效率和产品质量,在前期偷懒,后期必然加倍奉还。

我们缺的不是道理,毕竟最有用的东西都写在常识里了,我们缺的是理解道理的机缘。

所以,我希望这篇文章能成为一些人的机缘,如果你有所收获,也不是我的功劳,而是你已经具备了悟透的条件,明白只是早晚的事。

   从前端到全栈的心路历程:


作为 10 年前端老兵,最近五年基本投身于全栈技术。记得刚开始接触全栈时,我面对的不仅仅是一种技术栈的转换,更是一种思维方式的变革。我曾参与开发一个月流水达千万的广告投放平台,那是我第一次从0到1实现了一个复杂系统的构建。这个经历不仅锻炼了我的技术能力,更让我学会了如何在面对看似不可能的任务时找到解决之道。 现在,我负责的项目是日活跃用户数以千万计的 ToC 应用 —— QQ 前端统一接入层。

这些经历让我深刻理解到,作为一个程序员不仅仅是在编写代码,更是在用技术解决实际问题,创造价值。


在我的全栈开发之旅中,还探索了管理端低代码、H5 低代码和大数据服务领域。这些经历不仅丰富了我的技术背景,也锻炼了我在处理复杂数据和系统的能力。而今天,我想重点分享个人技术实践的一个高峰:QQ 前端统一接入层,这个项目不仅对 QQ 业务有着重大价值,也是对我个人技术能力的一次重要验收。




01



前言
我希望今天的分享不仅仅是关于技术的堆砌,更是一次深入背后故事的探索。


我们将一起走进项目的业务背景,看看它是如何将业务和开发需求相结合的。从项目出发深入到架构设计,与不同技术方案的对比,在众多选择中找到最适合业务的那一条路。这个过程中遇到的核心技术难题,汇聚成了本篇文章最有价值的技术认知。




02



业务背景:技术选择直接影响着我们的工作效率和产品质量

让我们来谈谈 QQ NT 的进化历程。旧版 QQ 通信链路的客户端 SDK 并不支持跨平台,这意味着我们必须为每个平台分别开发一套 SDK。而 NT 的设计初衷,正是要打破这种局限,实现各平台 SDK 的整合和复用。这一转变不仅促进了技术的进步,也推动了我们的后台系统进行相应的改造。然而 Web 版的 NT 尚未实现,对于 QQ 频道这样一个快速迭代且功能繁多的产品来说,例如帖子、榜单和 ark 等功能多通过 H5 和 QQ 小程序实现,这种缺失就变得尤为明显。我们面临的挑战,是如何在不断增长的功能需求和现有技术限制之间的矛盾。


让我们来探究 Web 版 NT 缺失背后的影响。这一缺口不仅是技术上的空白,更是一系列问题的源头。 我们不得不建立超过 100+ Node 服务来与后台服务交互,每个服务都重复建设鉴权和 RPC 调用。根据最近一次统计,如果把各前端小组的数量加起来,这个数字超过了300。


想象一下,整个前端团队分散在 300 多个项目中,重复劳作和资源浪费是显而易见的。首先,维护成了一个巨大的负担,随着功能的增加,我们团队的大部分时间都耗费在了这些 Node 服务的运维上。其次,在高性能需求场景下,如频道榜单,我们发现性能和稳定性的不足直接影响了用户体验。最后,不完善的日志和监控系统在开发和调试阶段导致了效率低下。


这就是我们需要面对的现实:技术选择直接影响着我们的工作效率和产品质量。




03



整体架构:如果存在一种捷径,那就是难路

前端接入层的整体架构。 这不仅仅是一系列技术组件的组合,而是一个精心设计的系统,旨在为 QQ NT+ 提供一个既稳定又高效的服务端解决方案。


我们在设计时考虑了众多因素,从系统性能到扩展性,从安全性到易维护性。每一个决定都是对当前需求的响应,同时也预留了空间以适应业务可能的发展方向,比如海外版。



整体架构的建设主要面临两大挑战:其一,解决当前存在的技术难题,这要求深入了解各种技术方案的优势与局限。其二,为未来可能的发展留出空间。这不仅是技术层面的挑战,更是一次对现有系统架构深度理解的考验,如果存在一种捷径,那就是难路,这一步万不可偷懒。




04



方案对比:不要在很差的基础上,拼命做优化

   4.1 司内及开源方案对比



业务网关的特殊性,不存在一套适用所有业务的开源方案,所以这里只横向比较最上一层。


我研究过不少业务网关建设的案例,发现了一个常见的误区:在很差的基础上,拼命做优化!前期针对核心模块的可量化分析必不可少。

我以 nginx 作为参照,结合业务场景,分性能、数据储存、私有部署等几个维度比较 apisix 在性能、灵活性及接入成本上取得最佳平衡。

   4.2 部门内方案对比



回顾一年半前,http2rpc 只是我们考虑的四个方案之一。但今天,它已成为 QQ 前端接入的事实标准。这一转变背后的故事颇为精彩。


首先,让我们来看看接入成本。http2rpc 在这方面做到了前后端的完全配置化和与 CI 的无缝集成。其次,它的架构设计既分层又模块化,使得即便是海外业务接入也变得更加高效,迭代成本大大降低。在性能方面,http2rpc 显著优于现有方案,提升了整体的服务响应和处理能力。更重要的是,它提供了全面的功能,包括监控、告警和全链路跟踪,确保了服务的成熟度和可靠性。


这些因素共同作用,使得 http2rpc 能够全面支撑起 QQ 的各种运行环境,成为我们技术演进的核心。




05



核心难点:每一个细小问题的解决都是产品护城河的加深

从协议转换成长为功能完备的业务网关,从服务于运营系统到走出频道业务,从日调几千到上亿,这个架构建设过程并非一蹴而就,其中的每一步都是对业务需求的深刻理解和对开发痛点的精准回应。


我把挑战归纳为两大类。


首先是普遍性挑战,这些是几乎所有业务网关建设项目都会遇到的。其次,是特有的业务挑战。以 QQ 为例,我们面临的是历史遗留问题,比如三种不同的通信协议共存的情况。这种独特的挑战要求我们不仅要有技术上的广度,还需要深度和创造性地思考。如何应对这些特殊挑战,同时保持系统的整体协调和高效运转,成了我们思考的重点。


   5.1 可观测性及告警:无反馈、不迭代,只有具备反馈机制,迭代才不是摆设



接入层的建设中,质量和效率的重要性不言而喻。因此,检验标准的制定尤为重要,其中最关键的两点是:
  • 首先,要能够在用户遇到问题之前先发现它们;
  • 其次,要尽可能缩短问题定位的时间。

举个例子,通过拨测和基于日志的告警,我成功地发现并修复了 tRPC 框架中一个极其隐蔽的问题 —— 空闲连接回收。这个改进不仅提高了我们接入层的可用性,还为其他使用 tRPC 的业务带来了好处。


但是,技术改进也会带来新的挑战。


我们引入的基于日志的告警系统虽然提高了告警的灵敏度,但也导致了告警轰炸的问题。面对这个挑战,我们意识到解决之道在于为告警系统引入反馈机制。这也形成了我做很多功能的方法论:无反馈、不迭代,只有具备反馈机制,迭代才不是摆设,才能真正服务于用户。


   5.2 性能:面向通用场景做到极致很难,但永远可以在具体场景下做到更极致



性能不仅是技术挑战,也直接关系到用户体验和业务成功。


对性能优化,我一直坚持一个原则:尽管针对通用场景的优化有其挑战性,但我们总能在特定场景中找到提速的空间。


这里分享一个关于性能优化的相关案例。对于地图类游戏,实时性的要求远高于数据完整性,且初始的数据下行量相对较大。我的优化策略是充分利用这些特点,实现基于时间偏移的分级推送,同时调整消息确认机制为最少一次确认。这项优化带来的成效超出预期:不仅显著减少了低端设备在运行游戏时的发热和卡顿问题,还提升了整体的游戏体验。


新版 QQ 体验地址 QQ PC 版官方网站(https://im.qq.com/pcqq)欢迎试用。



对技术原理的理解与掌握,是程序员从普通迈向优秀的阶梯。理解业务的复杂性,并能根据业务特点做出技术选型与架构设计,是分隔优秀与卓越的鸿沟。愿这篇文章的一些思考与总结能帮助腾讯云开发者社区的读者朋友,跨越鸿沟!



-End-
原创作者|付志远

 


有没有哪次项目经历,让你的技术水平或认知突飞猛进?对于开发人员的成长,你有哪些经验可以分享?欢迎评论留言。我们将选取1则优质的评论,送出腾讯Q哥公仔1个(见下图)。2月27日中午12点开奖。


📢📢欢迎加入腾讯云开发者社群,享前沿资讯、大咖干货,找兴趣搭子,交同城好友,更有鹅厂招聘机会、限量周边好礼等你来~


(长按图片立即扫码)






继续滑动看下一个

“网关日调用从1千到1亿”,项目背后我的十年开发心得

付志远 腾讯云开发者
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存