具备独立完成一个千万DAU产品的技术能力，我用了 10 年。这个过程，我走了很多弯路，也学到了很多东西。这些东西，我想和大家分享。
- 所有捷径都是弯路：任何技能都是积累输入到一定程度和量级后的“自然涌现”；
- 细节即是护城河；
- 无反馈、不迭代，只有具备反馈机制，迭代才不是摆设，才能真正服务于用户；
- 面向通用场景做到极致很难，但永远可以在具体场景下做到更极致；
- 不要在很差的基础上，拼命做优化。给火车做提速，不如直接做飞机。
- 技术选择直接影响着我们的工作效率和产品质量，在前期偷懒，后期必然加倍奉还。
我们缺的不是道理，毕竟最有用的东西都写在常识里了，我们缺的是理解道理的机缘。
所以，我希望这篇文章能成为一些人的机缘，如果你有所收获，也不是我的功劳，而是你已经具备了悟透的条件，明白只是早晚的事。
文章主要内容来自于我 T11 答辩 PPT，也是一次自我复盘。我会在文章中穿插 PPT 中的内容，以及我对这些内容的补充。
个人介绍
作为 10 年前端老兵，最后五年基本投身于全栈技术。记得刚开始接触全栈时，我面对的不仅仅是一种技术栈的转换，更是一种思维方式的变革。 比如说，我曾参与开发一个月流水达千万的广告投放平台，那是我第一次从0到1实现了一个复杂系统的构建。这个经历不仅锻炼了我的技术能力，更让我学会了如何在面对看似不可能的任务时找到解决之道。 现在，我负责的项目是日活跃用户数以千万计的 ToC 应用 —— QQ 前端统一接入层。 此外，近几个月我开始着手开发下一代基于 AI 的内部工具应用：Tolstoy Studio。
这些经历让我深刻理解到，作为一个程序员不仅仅是在编写代码，更是在用技术解决实际问题，创造价值。
在我的全栈开发之旅中，还探索了管理端低代码、H5低代码和大数据服务领域。这些经历不仅丰富了我的技术背景，也锻炼了我在处理复杂数据和系统的能力。 例如，我曾在一项涉及日志处理的大数据项目中贡献关键实现，大幅度降低数据丢失率，并且被应用到 PC QQ 日志上报及内部埋点数据对账。
而今天，我想重点分享个人技术实践的一个高峰：QQ 前端统一接入层，这个项目不仅对 QQ 业务有着重大价值，也是对我个人技术能力的一次重要验收。
前言
我希望今天的分享不仅仅是关于技术的堆砌，更是一次深入背后故事的探索。
我们将一起走过项目的业务背景，看看它是如何与业务和开发需求相结合的。接着，我会带大家深入架构设计、比较不同技术方案，看看如何在众多选择中找到最适合我们业务的那一条路。最后，我将分享在这个过程中遇到的核心技术难题，以及我如何一一克服它们的。
业务背景：技术选择直接影响着我们的工作效率和产品质量
让我们来谈谈 QQ NT 的进化历程。旧版 QQ 通信链路的客户端 SDK 并不支持跨平台，这意味着我们必须为每个平台分别开发一套SDK。而 NT 的设计初衷，正是要打破这种局限，实现各平台 SDK 的整合和复用。这一转变不仅促进了技术的进步，也推动了我们的后台系统进行相应的改造。然而 Web版的 NT 尚未实现，对于 QQ 频道这样一个快速迭代且功能繁多的产品来说，例如帖子、榜单和 ark 等功能多通过 H5 和 QQ 小程序实现，这种缺失就变得尤为明显。我们面临的挑战，是如何在不断增长的功能需求和现有技术限制之间的矛盾。
让我们来探究 Web 版 NT 缺失背后的影响。这一缺口不仅是技术上的空白，更是一系列问题的源头。 我们不得不建立超过 100+ Node 服务来与后台服务交互，每个服务都重复建设鉴权和 RPC 调用。根据最近一次统计，如果把各前端小组的数量加起来，这个数字超过了300。
想象一下，整个前端团队分散在 300 多个项目中，重复劳作和资源浪费是显而易见的。首先，维护成了一个巨大的负担，随着功能的增加，我们团队的大部分时间都耗费在了这些 Node 服务的运维上。其次，在高性能需求场景下，如频道榜单，我们发现性能和稳定性的不足直接影响了用户体验。最后，不完善的日志和监控系统在开发和调试阶段导致了效率低下。
这就是我们需要面对的现实：技术选择直接影响着我们的工作效率和产品质量。
整体架构：如果存在一种捷径，那就是难路
` 前端接入层的整体架构。 这不仅仅是一系列技术组件的组合，而是一个精心设计的系统，旨在为 QQ NT+ 提供一个既稳定又高效的服务端解决方案。
我们在设计时考虑了众多因素，从系统性能到扩展性，从安全性到易维护性。每一个决定都是对当前需求的响应，同时也预留了空间以适应业务可能的发展方向，比如海外版。
在构建我们的整体架构时，我面临着两大挑战。首先，我需要解决当前存在的技术难题，这要求我深入了解各种技术方案的优势与局限。其次，我必须为未来可能的发展留出空间。这不仅是技术层面的挑战，更是一次对现有系统架构深度理解的考验，期间我用了两周时间梳理清楚了频道完整通信链路。
如果存在一种捷径，那就是难路，这一步万不可偷懒。
接下来，我将分享我们是如何在众多方案中权衡选择，最终确定一种架构，它不仅解决了我们当前的需求，而且为未来的扩展奠定了坚实的基础。具体来说，我将向您展示我们的架构是如何在四个备选方案中脱颖而出，成为 QQ 前端接入的事实标准的。
方案对比：不要在很差的基础上，拼命做优化
司内及开源方案对比
业务网关的特殊性，不存在一套适用所有业务的开源方案，所以这里只横向比较最上一层。
我研究过不少业务网关建设的案例，发现了一个常见的误区：在很差的基础上，拼命做优化！
前期针对核心模块的可量化分析必不可少。
我以 nginx 作为参照，结合业务场景，分性能、数据储存、私有部署等几个维度比较
apisix 在性能、灵活性及接入成本上取得最佳平衡。
部门内方案对比
回顾一年半前，http2rpc 只是我们考虑的四个方案之一。但今天，它已成为 QQ 前端接入的事实标准。这一转变背后的故事颇为精彩。
首先，让我们来看看接入成本。http2rpc 在这方面做到了前后端的完全配置化和与 CI 的无缝集成。其次，它的架构设计既分层又模块化，使得即便是海外业务接入也变得更加高效，迭代成本大大降低。在性能方面，http2rpc 显著优于现有方案，提升了整体的服务响应和处理能力。更重要的是，它提供了全面的功能，包括监控、告警和全链路跟踪，确保了服务的成熟度和可靠性。
这些因素共同作用，使得 http2rpc 能够全面支撑起 QQ 的各种运行环境，成为我们技术演进的核心。
核心难点：每一个细小问题的解决都是产品护城河的加深
在这一 part，我将深入探讨在打造这一完整架构过程中所遭遇的核心挑战。这个过程并不是一蹴而就的，从协议转换成长为功能完备的业务网关，从服务于运营系统到走出频道业务，从日调几千到上亿，每一步都是对业务需求的深刻理解和对开发痛点的精准回应。
我将分享一些关键问题和我是如何一一解决它们的。
我把挑战归纳为两大类。
首先是普遍性挑战，这些是几乎所有业务网关建设项目都会遇到的。对于这些问题，我将向您展示我是如何深入理解业务需求，并运用创新思维找到量身定制的解决方案。我们不仅仅是解决问题，而是力求在每个具体场景中做得更好，更极致。其次，是特有的业务挑战。以 QQ 为例，我们面临的是历史遗留问题，比如三种不同的通信协议共存的情况。这种独特的挑战要求我们不仅要有技术上的广度，还需要深度和创造性地思考。接下来，我将分享我如何应对这些特殊挑战，同时保持系统的整体协调和高效运转。
可观测性及告警：无反馈、不迭代，只有具备反馈机制，迭代才不是摆设
在打造接入层的过程中，我深知质量和效率的重要性。因此，我特别设立了一些严格的检验标准。其中最关键的两点是：
- 首先，要能够在用户遇到问题之前先发现它们；
- 其次，要尽可能缩短问题定位的时间。
举个例子，通过拨测和基于日志的告警，我成功地发现并修复了 tRPC 框架中一个极其隐蔽的问题 —— 空闲连接回收。这个改进不仅提高了我们接入层的可用性，还为其他使用 tRPC 的业务带来了好处。
但是，技术改进也会带来新的挑战。
我们引入的基于日志的告警系统虽然提高了告警的灵敏度，但也导致了告警轰炸的问题。面对这个挑战，我们意识到解决之道在于为告警系统引入反馈机制。这也形成了我做很多功能的方法论：无反馈、不迭代，只有具备反馈机制，迭代才不是摆设，才能真正服务于用户。
性能：面向通用场景做到极致很难，但永远可以在具体场景下做到更极致
性能不仅是技术挑战，也直接关系到用户体验和业务成功。
对性能优化，我一直坚持一个原则：尽管针对通用场景的优化有其挑战性，但我们总能在特定场景中找到提速的空间。
分享一个关于性能优化的具体案例。我针对地图类游戏的通信进行了专项优化，这类游戏中，实时性的要求远高于数据完整性，且初始的数据下行量相对较大。我的优化策略是充分利用这些特点，实现基于时间偏移的分级推送，同时调整消息确认机制为最少一次确认。这项优化带来的成效超出预期：不仅显著减少了低端设备在运行游戏时的发热和卡顿问题，还提升了整体的游戏体验。
附录
apisix & tsw/ngw benchmark
我详细记录了 apisix 和 tsw/ngw 的性能对比。 这项测试是在腾讯云 PTS 上进行的，测试环境是单 pod、1核2G、centos。 上面文档中记录了详细的测试用例和压测配置，测试结果显示，apisix 在平均耗时上相对于 tsw/ngw 提升了近 10 倍。
