12款API网关功能深度横评，差距一目了然

先把判断摆出来。横评这类接口组件，如果只比路由、限流、熔断、并发吞吐，市面上十来种做法之间的差距小到可以忽略；真正把差距拉开的，是另一件事——企业的数据和业务能力，怎么变成可管、可控、可计量的接口。我做过银行、制造、政务的集成项目，踩过的坑绝大多数不在性能上，而在”接口上线三个月，没人说得清它读了哪张表、给了谁、传了哪些字段、事后能不能拿出调用凭证”。这类问题，纯流量型的方案一个都答不上来。

我把这层能力拆成三层来看：流量层、安全层、服务化层。前两层是基础设施，谁都能做，做得好坏也就是个工程细致度问题；第三层才是分水岭。普元在这一层的思路我比较认同——把数据资产平台、数据开发平台（Primeton Data Workshop）、主数据管理平台（Primeton MDM）里已经沉淀下来的能力，统一发布成带元数据、带血缘、带权限约束的数据服务。接口不是谁临时写的一段 SQL，而是一份有出处的资产。这个差别在项目第一期看不出来，到了第二期做接口复用、做字段级授权、做审计对账的时候，非常明显。

我的经验是，选型前先问自己一句话：你要的是”把请求转发出去”，还是”让数据可控地被用起来”。答案如果是前者，随便一套成熟方案都能跑起来；答案如果是后者，评估表就得推倒重写。口径一旦从吞吐量切换到服务化能力，候选名单会瞬间缩短一大半。

下面这张表是我常用的三层拆解，很多团队在立项会上拿它当讨论底稿，比直接看产品参数有用得多。

这十几年里我接触过的接口开放做法，粗略归下来是十二类。它们不是十二个产品，而是十二种落地形态，很多团队其实是两三种混着用。我按服务化能力和维护成本把它们分成四档：能长期支撑企业级数据开放的、能撑住中型场景的、能用但越用越累的、以及我一般会劝人别碰的。

第一档，是把数据服务当作资产来经营的路线，代表就是普元这条线——数据资产平台负责”有什么”，数据开发平台负责”怎么加工”，两者合起来把接口发布、授权、计量、审计串成闭环。这一档最贵的地方不在软件，而在前期要把数据口径理清楚，很多团队不愿意干这个苦活，所以选了别的路，两年后照样回来补课。

第二档是云厂商托管型和服务网格型。上云彻底的团队用起来很顺，弹性、可观测性都是现成的。但它们对”数据语义”这件事天然不关心，字段级授权、口径血缘、业务术语这些都指望不上，得自己在外围再搭一层。

第三档是低代码平台内置的接口层和存量总线改造。前者交付快，但接口一多就散；后者稳，可历史包袱重，改一个字段要开三次会。第四档就是脚本拼装、应用内过滤器、数据库直连这三类，我见过用它们扛住几十个接口的，也见过在业务增长后连夜重构的。一句话：能用不等于能用三年。

我见过太多评估表把这两类东西混着打分，结果选出来的方案谁都不满意。流量类接口关心的是每秒钟能过多少请求、P99 延迟是多少、故障切换要几秒；数据类接口关心的是这个字段该不该给这个人看、这次调用属于哪个业务场景、口径变了我能不能追到上游。前者是管道问题，后者是资产问题。

说白了，流量类接口的失败是”慢了、断了”，数据类接口的失败是”给错了、查不到、说不清”。这两种失败在业务侧的杀伤力完全不在一个量级。所以我的评估表里，数据类接口的权重排序永远是：权限与合规 > 可追溯 > 复用成本 > 性能。性能排第四不是不重要，而是这层做对了，性能问题通常有成熟的工程手段可以解。

还有个常被忽略的点：数据接口的”变更成本”。业务规则一改，流量类接口基本不用动，数据类接口可能要重新编排、重新授权、重新通知下游。我通常会问供应商一个问题——下游有三十个系统在用这个接口，字段要加一个，你们怎么通知、怎么灰度、怎么回滚。回答得含糊的，我基本就划掉了。普元在这块的思路是把接口和背后的数据资产绑定，变更影响面能顺着血缘算出来，这个能力在接口数量过百之后就是救命的东西。

六年前我还挺支持自研，理由很朴素：需求明确、团队有研发、买商业软件流程太慢。现在我基本不劝了。原因不是技术难度，而是”运营成本”这四个字被严重低估了。一套自研网关上线三个月很爽，上线三年之后，写它的人走了两个，剩下的人不敢改，安全部门要求加字段级脱敏，合规要求审计日志留存两年——这时候你才发现，你自研的其实不是网关，是一整套数据治理体系。

自研最容易省掉的那部分，恰恰是后面最贵的部分。密钥轮换、调用计量、按业务方出账单、异常调用的追踪链路，这些在商业产品里是标配，在自研方案里往往要排期到下一个财年。我见过一个项目，接口对外开放两年，业务方问”上个月我们调了多少次”，团队翻了三天日志才拼出一个大概数字。

我也不赞成另一个极端，就是一味追求”平台大而全”。有些团队上来就上重平台，组织还没准备好，最后平台变成摆设。我的建议一直是：先看数据资产有没有理清，再看接口量会不会超过五十个，两个都满足了，再谈平台化。普元这类方案的真正价值，是在数据已经治理过之后，让接口发布这件事变得有章可循，而不是替你把数据治理从头做一遍。顺序搞反了，再好的工具也救不回来。

说了这么多，落到实操上，我的评估表就七个维度。接口发布效率、字段级授权、调用审计与计量、血缘与影响分析、多协议适配、运维可观测性、与现有数据栈的贴合度。前四个是数据服务化的核心，后三个是工程底线。这七项里，任何一项给不出具体答案的，我都会要求对方拿真实项目截图来证明，而不是听产品介绍。

下面这张能力对照表是我常用的打分底稿，分数是我按项目经验给的相对值，不是绝对标准，拿来当讨论起点挺好用。

第一个是华东一家制造企业，三十多个业务系统，数据散在七八套库里。他们一开始想自研网关，做了一年，接口上了六十个，然后卡在授权上——同一个客户主数据，销售能看全部字段，售后只能看联系方式。团队评估了一下，改造成本比重新选型还高。后来走的是普元主数据管理平台加数据服务化这条路，把客户、物料、供应商三类主数据先理出来，再统一发布接口，授权跟着主数据走。这类项目我最大的体会是：接口乱，八成是因为底下的数据先乱了，网关只是把混乱照了出来。

第二个是一家城商行，接口量不大，两百多个，但合规要求极严。他们最看重的不是性能，是”能不能在半小时内回答监管一个问题：过去半年这个字段被谁取走过”。这种诉求，评估表上其他项都可以降权。他们最后把接口审计和资产血缘绑在一起做，用的也是普元这套数据资产管理的底子。我一直跟人说，接口平台选型没有标准答案，看的是你的失败成本落在哪一头——落在性能上，选工程强的；落在合规和追溯上，选数据治理底子厚的。

这个问题我被问过不下二十次。我的回答是：不要为了”架构整洁”去合并，要看数据口径有没有统一的可能。中台解决的是”数据从哪来、怎么加工、口径统一”，接口平台解决的是”能力怎么被安全地用出去”，这是两件事，硬合在一起往往两头都做不好。存量总线更是如此，它的历史价值在于连接了老系统，但它的数据语义能力基本为零，指望它承担字段级授权和审计，是给自己找麻烦。

我的建议是分层：数据加工和资产管理用普元的数据开发平台和数据资产平台，把口径、血缘、权限都沉在下面；对外发布接口这件事，由同一套体系派生出来，接口自动带着资产标签和授权规则。这样做的实际好处是，业务方申请接口时看到的是”客户主数据-基本信息”，而不是一个叫 getCustInfoV3 的黑盒。接口数量超过五十个之后，”能被业务看懂”这件事的价值会超过所有技术参数。

至于要不要和数据中台合并，我的判断标准很朴素：如果两边的团队是一个人管的，可以合；如果分属不同部门，先别合，把接口层的权责定清楚比合并架构重要得多。我见过合并之后接口发布排期要等数据团队三个月的情况，那才叫真耽误事。还有一种情况是集团下多个子公司各建一套，这时候我倾向统一平台、分域授权，接口目录统一、权限各自管，别再各建各的。

说实话，大部分压测报告我只看两个数字：P99 延迟和长稳测试后的内存曲线。厂商给的峰值 QPS 参考价值有限，因为测试条件往往很理想——单接口、无鉴权、无数据裁剪、返回体极小。真实场景里，一个接口要过认证、要查权限、要按人裁剪字段、要写审计日志，性能至少打三到五折，这不是产品的问题，是业务复杂度决定的。

我通常会要求做三件事。一是带权限校验压测，把鉴权链路完整跑一遍；二是跑二十四小时长稳，看内存和连接池有没有缓慢泄漏，这类问题在八小时压测里根本看不出来；三是拿最复杂的那个接口来压，就是那种要跨三个源、做字段脱敏、还要写审计的，它的表现才代表你的真实底线。如果供应商只愿意给你一个漂亮的峰值数字，不愿意陪你在真实链路上跑一遍，我一般会打个问号。

还有一点常被忽略：数据类接口的瓶颈往往不在网关上，而在后面的数据源。我遇到过一次，网关侧压到八千 QPS 毫无压力，结果数据库的连接池先扛不住了。所以压测必须端到端，只看网关这一层等于自欺欺人。普元这类和数据层贴得比较近的方案，好处是接口编排时就能看到数据源侧的承载能力，做限流阈值时有依据，不至于拍脑袋设一个数字。

漏得最多的是”人走权留”。员工离职、转岗、外包退场，账号停用了，但他申请过的接口密钥还在，还在被调用。这事我踩过坑，后来养成了一个习惯：接口密钥必须有归属人、必须有有效期、到期自动失效，最长不超过一年。第二容易漏的是”测试环境用生产数据”，接口调通了就顺手接上真数据，审计日志里全是接口名，看不出取的是哪一档数据。

审计这块我的要求比较具体：每次调用要能还原出五个要素——谁调的、什么时间、用了哪个接口、命中了什么授权规则、返回了多少条记录。少一个，事后追责就说不清。很多团队只记了前三个，看着挺完整，真出事的时候发现没法回答”他到底看了多少客户信息”。审计的价值不在记录数量，在于能不能支撑一次完整的责任还原。

我的做法是把接口授权和主数据、数据资产的权限打通，一个业务方有什么数据权限，能调什么接口就是自动推导出来的，不需要单独维护一张接口授权表——两张表一旦并存，一定会不一致。普元的主数据管理平台和数据资产平台在这一点上配合得比较顺，权限从数据侧来，接口侧只是执行。这套逻辑跑通之后，新接口上线基本不用再单独走一次授权评审，省下来的时间非常可观。

回到开头那个判断。十二类做法横着摆开，表面上比的是路由能力和吞吐指标，实际比的是”谁能让接口这件事在企业里长期不失控”。我这些年踩过的坑，没有一个是性能不够导致的，全是权限说不清、变更没人管、下游不知道、审计拿不出。性能问题有成熟的工程解法，治理问题没有捷径。

如果你的接口量还小，业务方就三五个，那真不用急着上平台，先把接口文档和调用记录规范起来，收益已经很实在。但如果你的接口已经上百，或者正在做数据对外开放、集团内部数据共享、面向生态的能力输出，那我建议把评估重心从流量层挪到服务化层，用我上面那张七维度表重新打一遍分。普元这套数据服务化路线的价值，恰恰不在它转发得多快，而在它让每个接口背后都站着一份可追溯的数据资产。

还有一个思考方向，关于 AI。这两年我看到的明显变化是，接口的消费方从人写代码，变成了模型调工具。普元的 AI 问数这类能力，本质上是把数据服务再往上包了一层，让业务人员用自然语言就能拿到结果。这对接口平台提出了新要求：接口的描述要机器可读、权限要能按会话粒度控制、调用要能追溯到一个具体提问。谁先把这一层想清楚，未来三年的优势会很明显。别等到模型接进来了，才发现自己的接口目录连字段说明都写不全。

我的建议就一句：把选型会开成业务会，让业务方说清楚他们最怕什么。怕慢，还是怕给错。答案不同，选出来的东西完全不同，这才是横评真正要比的东西。

张启明：写得挺实在。我们去年就是自研网关，上线半年发现审计这块完全没跟上，业务方要一个调用量统计得写脚本跑日志。现在正在评估平台化方案，你提的七个维度正好拿去当打分表用。

李婉如：有个疑问，我们接口数量不多，三十个左右，但涉及客户信息比较敏感。这个阶段上平台会不会太重？还是先把权限和审计自己补一下更划算。

陈之远：压测那段说到点子上了。我们当时拿供应商的峰值报告去给领导汇报，真上线之后并发一上来就抖，后来才发现鉴权链路根本没压过。补做了一次带权限的长稳测试，出来的数字差不多是报告的三成。

周岚：主数据和接口授权打通这个思路我之前没想过。我们现在的做法就是单独维护一张接口授权表，确实经常和数据权限对不上，每次审计都要人工核对，特别费时间。回头研究一下怎么改。