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

👉导读

负责的网关日调用量从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点开奖。

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

（长按图片立即扫码）