An idea for Higress, what about a new member -- Higress API Portal?

[lexburner]

Feature Request

Higress 代码组新增一个成员 Higress API Portal

Higress Now

• 提供安全、流量、微服务三合一的网关能力
• K8s Ingress/Gateway API 的标准实现

Inspire

最近看了得物发的一篇自研 API 网关实践的文章，原文链接：https://mp.weixin.qq.com/s/IXInfuWkKe5D1fmtpQQ1SA 文中描述了得物使用 springcloud gateway 去构建企业级 API 网关的过程，并且提及了他们理想中的API网关应当具备以下要素：

1. 支持海量接口注册，并能够在运行时支持动态添加修改路由信息，具备出色路由匹配性能
2. 编程范式尽可能简单，降低开发人员心智负担，同时最好是开发人员较为熟悉的语言
3. 性能足够好，至少要等同于目前 SCG 的性能，RT99 线和 ART 较低
4. 稳定性好，无内存泄漏，能够长时间持续稳定运行，发布升级期间要尽可能下游无感
5. 拓展能力强，支持超时定制，多网络协议支持，http，Dubbo 等，生态完善
6. 架构设计清晰，数据流与控制流分离，集成 UI 控制面

可以发现 Higress 大多数都是具备的，对于“支持海量接口注册”这一点值得拎出来单独讨论下。从技术上来看，Higress 借助于 etcd 也好，Nacos 也罢，一定是可以做到海量接口的管理的，但站在业务视角，却不一定，同一个 Higress 实例管理不同业务路由缺少分组的概念，不方便检索，且路由语义和研发侧的接口还是有一定距离的，当接口真正达到万级别，就不方便管理了。

Higress API Portal Proposal

类似于得物这样的企业级用户肯定还有不少，实际是多了精细化管理接口的诉求。目前 Higress 的产品设计不能很好地满足这一诉求，具体表现为 Higress 的路由模型和 API 精细化管理的需求之间的矛盾。Higress 的路由模型如果配置为泛路由 /order/* 的前缀匹配模式，则会将应用的所有接口暴露出去；如果配置为 /order/createOrder 的精确匹配模式，可以达到精细化管理的诉求，但接口级别常见的需求 API 出入参定义、参数映射、错误码管理，跟路由的模型无法很好的适配。

让我们再深挖这个需求的根源，其实是企业研发模式转变带来的。目前 Higress 的用户群体偏运维，借助于泛路由的方式，通过 path 的前缀匹配或者 host，将整个服务暴露出去，由于不太感知后端业务，这些工作由运维承担没有太大负担，但随着精细化接口管理的诉求出现，限流、参数映射等操作需要配置，路由数量也会从服务数膨胀到接口数，这个时候一定需要研发自己配置具体接口的暴露。

为了满足精细化管理 API 的诉求，又同时保留现有的产品模型，我提议为 Higress 组新添加一个成员，姑且称之为： Higress API Portal。产品交互示意如下：

Higress API Portal 可以理解为 Higress 的特化，专门为精细化管理接口而设计。在产品模型上，Higress 主要使用 Route 领域模型，相对应的，Higress API Portal 使用 API 领域模型，Route 可以通过前缀匹配或者精确匹配表达一个或者一类接口，而 API 则仅表达一个接口，该接口往往代表唯一的 HTTP 请求方法以及固定的请求入参响应格式；在控制面/数据面模型上，Higress API Portal 会复用 Higress 控制面的路由模型，正如前面说的 API 是 Route 的特化，并对其进行扩展，以支持 API 分组、参数映射、错误码管理等概念。

从用户画像来看，Higress API Portal 是偏研发侧的界面，Higress 是偏运维侧的界面，他们的数据是双向互通的，即研发同学在 Higress API Portal 创建的一个 API 以及对应的规则，运维同学是可以在 Higress 上看到的。

HIgress vs Higress API Portal

	HIgress	Higress API Portal
管理粒度	粗	细
核心模型	路由	API
适用人群	运维	研发
差异化功能	-	API 出入参定义、参数映射、错误码

Higress API Portal NOT

• Higress API Portal 不是 API 全生命周期管理的平台，目前我的设想中 API 定义和实例是锚定的，不涉及复杂的 API 生命周期管理、多环境、多版本等复杂设计。
• Higress API Portal 不是 API 对外开放的门户，最多可以理解为研发侧的门户。
• Higress API Portal 不是要取代 Higress 现有的形态，它提供了更高的抽象层次，让企业用户集成 Higress 时做更少的工作，前提的是用户需要的是一款精细化管理 API 的产品

Higress API Portal 目前虽然没有涉及 API 全生命周期和开放门户，但也是触及这两个模型的必经之路，目前重点讨论点，应该还是 Higress API Portal 本身。

Higress API Portal Addon Features/Efforts

更高程度地抽象之后，有一些开箱即用的 Feature 是我认为 Higress API Portal 应当具备的：

• API 分组
• API 出入参定义
• 参数映射
• 错误码管理

为之付出的工作量可能包括：

• Higress API Portal 交互设计
• Higress 各个组件适配新的 API 分组模型（策略、插件支持绑定至分组）
• API Spec 设计（基于 OpenAPI 2.0/3.0 扩展是一种可能、grpc&dubbo 多协议适配）
• 面向研发端侧：解析代码，自动生成 API Spec
• coding~

欢迎大家发表对 Higress API Portal 的看法

[CH3CHO]

The real lexburner?

[lexburner]

The real lexburner?

I am kirito(www.cnkirito.moe), not the Up in bilibili (゜-゜)つロ.

[Serverdowno]

The real lexburner?

I am kirito(www.cnkirito.moe), not the Up in bilibili (゜-゜)つロ.

Come on, I hope it gets better and better

[johnlanni]

对 Higress API Portal 感兴趣，想参与贡献的同学可以加这个群，这是后续社区的一个重点方向，技术栈是 Java/JS/Go 的都可以参与

[Xunzhuo]

Refer to #535