Open lexburner opened 1 year ago
The real lexburner?
The real lexburner?
I am kirito(www.cnkirito.moe), not the Up in bilibili (゜-゜)つロ.
The real lexburner?
I am kirito(www.cnkirito.moe), not the Up in bilibili (゜-゜)つロ.
Come on, I hope it gets better and better
对 Higress API Portal 感兴趣,想参与贡献的同学可以加这个群,这是后续社区的一个重点方向,技术栈是 Java/JS/Go 的都可以参与
Feature Request
Higress 代码组新增一个成员 Higress API Portal
Higress Now
Inspire
最近看了得物发的一篇自研 API 网关实践的文章,原文链接:https://mp.weixin.qq.com/s/IXInfuWkKe5D1fmtpQQ1SA 文中描述了得物使用 springcloud gateway 去构建企业级 API 网关的过程,并且提及了他们理想中的API网关应当具备以下要素:
可以发现 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 API Portal NOT
Higress API Portal 目前虽然没有涉及 API 全生命周期和开放门户,但也是触及这两个模型的必经之路,目前重点讨论点,应该还是 Higress API Portal 本身。
Higress API Portal Addon Features/Efforts
更高程度地抽象之后,有一些开箱即用的 Feature 是我认为 Higress API Portal 应当具备的:
为之付出的工作量可能包括:
欢迎大家发表对 Higress API Portal 的看法