一句话省流版：API spec 管理方式 + Consumer 类业务网关能力
说来惭愧，作为一个从事网关十来年的老炮，对于 API gateway 的认知却很迷糊，一直不得其要领
初次结缘
关于 API gateway 最初的印象，还是 2015 年的 OpenResty Con，来自 Adobe 张帅的一个分享。他们实现了一个统一的 API 管理平台，把来自内部多个团队的对客 API，给统一管理起来了
当时的大致印象是，哦，一个基于 OpenResty 的网关，用 Lua 来实现认证鉴权之类。但是，对于他提及的 API gateway 却并没有什么认知，只是停留在 OpenResty 数据面的实现机制
妥妥的局限在一个 OpenResty 数据面开发人员的思维，汗…
算是认识
对于 API gateway 作为一个产品的认知，始于 2019 年，那会在春哥公司，搞 OpenResty Edge，有个客户点名想要 Azure APIM 那样的 API 网关
于是，适用体验了一番 Azure APIM，当时两个体会：
- 基础能力也没啥特别的，也就是网关标准的那些能力，OpenResty Edge 都能支持
- 主要区别是转发策略的管理方式不同，基于现有的底层能力，包一层皮也是可以实现的
现在看来，其实还是没看懂，局限在接入网关的思路，并且还是开发人员底色。完全没有意识到，管理方式不同，对用户意味着什么
很可惜，后来考虑到 ROI，这个客户没有继续下去，我对 API gateway 的认知也就停留在这里了
用户视角
直到去年，因为项目上线，我们一个服务需要对客提供接口，需要经过统一的 API 网关
于是，作为用户，使用了内部 API 网关之后，给了我很强的冲击，第一次完整的从用户视角，从产品的角度来思考 API gateway
这才有了今天这篇文章，也就是，以我入坑接入网关太深的视角，谈谈 API gateway 到底有什么差异
从我的视角（误区）来看，主要是两个差异
1. 管理方式
表面上看，产品提供给用户的管理方式不同，实际上对应的是，用户群体的不同
- 接入网关，更多的还是系统运维的视角，更加全局一些
- API gateway，侧重的是应用开发者的视角
作为应用开发者，最直观的概念还得是 API（路由这种概念，本质上来自网关自身的实现）
在应用开发者的工作流里，一直是围绕着 API 进行的，设计评审，质量验收，安全验收，都是基于 API 进行的
并且，对于 API 的描述，业界也有了一些通用的标准，比如 OpenAPI Specification
那么开发完成之后的发布环节，最自然的也还是继续使用 API 这个概念，通过 API spec，就把 API 发布出去了，这个体验才自然
另外，对于域名，证书什么的，网关最好直接托管了，用户可以不需要操心。对用户来说，有的用，符合公司统一管控规则就行，具体是什么，其实并不太关心
体验了完整的应用开发流程，当了一回用户之后，管理方式的不同，对用户意味着什么，给我的冲击是最大的
本质上来说，软件架构发展，分工细化的演进结果。服务之间通讯是基于 API 的，不同角色之间沟通也是基于 API 的，网关没道理不是基于 API 的
2. 业务网关
上面是基于产品对客，最直观的管理方式，接下来是网关产品能力的了
接入网关侧重于流量接入，更多承载的是公司级的统一管控策略，看重是性能，稳定性
API gateway 侧重于业务网关，为业务服务的角色，承载的业务级别的通用能力
Consumer
举一个常见的例子，API 发布之后，就会有人来调用，对调用方就需要进行认证鉴权
以接入网关的思路，提供一个认证鉴权的插件能力，已经算到头了
API gateway 则是更近一步，抽象了 Consumer 的概念来进行管理
本质上来说，一个 Consumer 就是一个认证鉴权后的身份 ID，初步看起来也没啥差异。但是，我们还可以基于 Consumer 来进行不同的配置，比如根据 Consumer 的等级，配置不同的限流值
对于业务系统来说，已经算是通用的逻辑了，就可以放到 API gateway 上来承载，但是，对于全站级别的接入网关而言，或许就算不上那么通用了
业务插件能力
除了 Consumer 这种绝大部分 API gateway 都会抽象出来的产品能力，还有很多垂类的业务场景的产品能力
比如，眼下很火的 AI 大模型，对客提供的也是 API，那么，API gateway 也是可以承载一些通用的插件能力的
例如：
- 统一的 API 协议，屏蔽各家大模型提供商的接口差异
- 统一的 token 二次管理，调用方一个 token 调遍所有大模型
- 以及，各种调用 metrics
- 甚至，token 的计量
这种对于接入网关来说，这种属于业务逻辑了，太偏业务了，但是对于 API gateway 这种业务网关来说，那就很合适了
极端点说，有两个业务方需要的通用能力，就可以放到 API 网关来承载…
MoE 硬广时间
由此可见，对于 API gateway 来说，插件扩展能力，会是一个刚需，易用且强大的扩展能力，将是 API gateway 的核心卖点之一
嗯，就这么丝滑，到了 MoE 硬广时间了
MoE 将 Golang 嵌入了 Envoy，我们可以通过 Golang 来实现网关插件，这是研发性能和性能的双赢组合
还不了解的，可以看看去年的几篇旧闻，感兴趣的欢迎技术交流~
今年，我们除了继续完善优化，还会继续往上走，提供一个更高阶的产品出来，让我们拭目以待 😄
最后
其实 API gateway 也很好理解，就是一个以 API 为核心的业务网关，就像它的名字那么简单
上面掰扯这么多的差异分析，基本来自我多年作为网关 developer 的偏见…
看不见、看不起、看不懂、不知道现在补上，来不来得及，哈哈~