“每日网关调用量从1000次增加到1亿次”，项目背后我十年的开发经验网关配置

介绍

我用了十年的时间，把网关日调用量从一千次提升到一亿次，具备了独立完成一款千万级DAU产品的技术能力。这个过程走了很多弯路，也学到了很多东西。我想把这些东西分享给你们。你们缺的不是真理，而是了解真理的机会。静水流深，心胸开阔，你的时代终将到来！

目录

1 简介

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

3. 单体架构：如果有捷径，那一定是艰难的道路

4. 解决方案比较：不要在糟糕的基础上尝试优化

5 核心难度：解决每一个小问题都会加深产品护城河

我们缺少的不是。。，毕竟最有用的东西都是写在常识里的，我们缺少的是了解。。的机会。

所以我希望本文能成为一些人的一个契机，如果你有所收获，那不是我的功劳，而是你已经具备了开悟的条件，明白只是时间问题。

从前端到全栈的历程：

作为一名十年前端老手，近五年来一直致力于全栈技术。记得刚开始做全栈的时候，面临的不仅仅是技术栈的转换，还有思维方式的转变。我曾经参与过一个月流水千万的广告平台的开发，那是我第一次从0到1搭建一个复杂的系统。这段经历不仅锻炼了我的技术能力，也教会了我如何在面对看似不可能完成的任务时，去寻找解决方案。现在，我负责的项目是一个日活千万级的ToC应用——前端统一接入层。

这些经历让我深刻的认识到，做一名程序员不只是要写代码，更要用技术解决实际问题，创造价值。

在我的全栈开发历程中，我也探索过管理层低代码、H5低代码、大数据服务等领域。这些经历不仅丰富了我的技术背景，也训练了我处理复杂数据和系统的能力。今天想重点分享一下我个人技术实践的一个高峰：前端统一接入层。这个项目不仅对业务有很大的价值，也是对我个人技术能力的一次重要考验。

01

前言

希望今天的分享不仅仅是技术的积累，更是对背后故事的深入挖掘。

我们会深入到项目的业务背景，看它是如何结合业务和开发需求的。从项目出发，深入到架构设计，比较不同的技术方案，在众多的选项中寻找到最适合业务的路径。而这个过程中遇到的核心技术问题，也成为了本文最有价值的技术认知。

02

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

我们先说一下NT的演进，老的通讯链路的客户端SDK不支持跨平台，这就意味着我们要为每个平台开发一套SDK。NT的设计初衷就是为了打破这个限制，实现各平台SDK的集成复用。这个改造不仅推动了技术的进步，也推动了我们后台系统的相应改造。但是NT的网页版至今还没能实现。对于像频道这样一个迭代迅速，拥有帖子、列表、方舟等众多功能，且大部分都是通过H5和小程序实现的产品来说，这个缺失就显得尤为明显。我们面临的挑战是如何调和日益增长的功能需求和现有技术的局限性之间的矛盾。

我们来探究一下 Web NT 缺失背后的影响。这个缺口不仅仅是技术上的缺口，也是一系列问题的根源。我们要搭建 100+ 多个 Node 服务来和后端服务交互，每个服务都要重复认证和 RPC 调用。根据最新的统计，如果把前端团队加起来，数量超过了 300 人。

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

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

03

单体架构：如果有捷径，那一定是艰难的道路

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

我们在设计时考虑了很多因素，从系统性能到可扩展性，从安全性到可维护性，每一个决定都是对当前需求的响应，同时也为可能的业务发展方向留有余地，比如海外版本。

整体架构的搭建面临两大挑战：一是解决当前的技术难题需要深刻理解各种技术方案的优势和局限性；二是为未来可能的发展留有余地。这不仅是技术挑战，也是对现有系统架构深刻理解的考验。如果有捷径，那一定是走苦路，所以这一步千万不能偷懒。

04

解决方案比较：不要在糟糕的基础上尝试优化

4.1 内部解决方案与开源解决方案的比较

由于业务网关的特殊性，目前还没有一个适用于所有业务的开源解决方案，因此这里只对最上层进行横向比较。

我研究过很多业务网关建设案例，发现一个普遍的误区：在很差的基础上拼命优化！前期核心模块的可量化分析必不可少。

我以nginx作为参考，并结合业务场景，从性能、数据存储、私有部署等维度对apisix进行对比，以达到性能、灵活性、访问成本的最佳平衡点。

4.2 部门内解决方案比较