跳到主要内容

Knife4j新产品的想法

写在开头

Knife4j的发展已经有好几个年头了,最近想来,虽然这个小组件不太稳定,但有每天依然收到很多小伙伴的积极反馈,这让我又不由自主的对这个项目产生了羁绊。一直以来,总想把一些工作中的想法,以及和Knife4j周边生态相关的内容结合起来,做一些不一样的事情。

在Knife4j目前的生态中,我主要为Knife4j写了一些技术的组件,主要包括:

  • Knife4j-ui:前端组件部分,主要基于Swagger2/OpenAPI3规范的识别,通过不同的展现及交互,为开发者提供不同的体验
  • knife4j-aggregation:前期基于Servlet生态体系下的聚合组件,解决在Spring Cloud Gateway等异步编码较困难的人文档聚合问题,打通各个注册中心组件(Nacos\Eureka\Consul等)实现接口文档的聚合
  • knife4j-gateway:Spring Cloud Gateway网关下的聚合组件,4行配置搞定网关下的接口文档聚合
  • Knife4j-extension:基于Chrome浏览器的调试插件,只要是Swagger2/OpenAPI规范,就可以预览文档/调试文档,为了上架还开通了vista卡,付费给Google5美元,现在下架了(长时间没更新代码有漏洞被迫下架)😂。。。
  • knife4j-insight:独立运行的聚合中间件,将硬盘/Nacos等作为Swagger2/OpenAPI3规范的数据源,复用aggregation的生态,聚合各个注册中心,实现平台化,聚合所有接口规范,统一预览/调试。。更新了3个版本(我觉得自己思路挺好的)。。😂

新想法

最近这段时间,主要思考的是Knife4j这个项目应该如何发展下去,如果做新产品,与市面上已经存在的其他产品如何做差异化的竞争。

思来想去,我又有了新的方向和目标~!

折腾新产品的心态一直没停过。。

市面上的产品包括PostmanApifoxApipost等等,专注在自己的领域里面,覆盖面都挺广的,而Knife4j好像以Ui界面交互起家,受众要宅一些,想想这些产品的词云关键字:API文档调试协作测试API设计等等

每一个关键字里面所需要投入的精力,都是Knife4j无法企及的,而且我在很早之前分享Knife4j的定位时,我一直想把他作为一个工具输出,单纯的工具,因此,包括:协作涉及自动化等等标签,都不适合我

那么,应该做什么?做一点不一样的呢?

Knife4jInsight这个产品的思路我自认为还是得发展下去,只不过需要更加产品化一下,做成平台,给用户提供更方便的可操作化的界面,简化整个使用步骤。

基于这个想法,和脑子里蹦出了一些新的Idea,包括:开放平台接口展示LLM大模型

我有了一个产品的大致雏形,我画了一个草图,大概是这个样子:

图1.产品架构图

在上图中,Knife4jInsight是一个独立服务组件,依附在Apache APISIX网关组件下的服务。那么,产品定位是什么呢?

产品定位:统一的通用接口文档及开放平台服务系统

在功能上,主要是三大块的功能:

  • 开放文档的统一管理:借助于Knife4j的前端界面,接口文档完全遵循Swagger2/OpenAPI3规范,下游或者外游服务的接口文档,只需要是符合规范的,都可以统一在平台进行管理维护,并提供文档最基础的预览、调试、鉴权访问等功能
  • 开发密钥统一管理:开发者开放的API接口,很多时候,如果要对外的情况下,通常开发者们都需要实现接口的鉴权控制逻辑,而如果每个服务或不同的项目都实现一遍,那太耗费精力了,那么我觉得只要是聚合上来的接口文档,所对应的下游服务,都可以通过该平台进行统一的管理,分配鉴权及管理开放用户
  • 下游服务统一管理:一旦涉及到开放平台,那么网关的企业级别高性能要求不可避免,这不是Knife4j的强项,作者也没这个能力,作为开放平台网关层,这里考虑Apache APISIX来实现服务的分发,依靠Apache APISIX提供的Admin API接口,平台通过将下游服务的转发规则进行动态注册,这样接口文档和开放平台就从功能职责上进行了区分,互相存在依赖关系,但职责分工不同

平台的网关鉴权,通过实现Apache APIXIS的鉴权插件,植入到网关组件中,此时所有开放平台的网关入口流量,都会通过该插件与Knife4jInsight中的开发密钥进行联动,实现接口的鉴权。

开放文档的统一管理

先来看开放文档的统一管理,考虑到我们要与开源Knife4j项目共同发展,因此产品的功能上,也是以开源Knife4j为主,接口文档完全遵循Swagger2/OpenAPI3规范,在这个场景下,实现文档的统一管理和聚合

主要包括两个功能:

  • Namespace:命名空间(namespace)是平台中抽象的概念,一个namespace下可以允许存在多个OpenAPI规范实例,用户可以讲该功能理解为企业、项目、部门、产品等等
  • ApiRegister:服务实例(ApiRegister)是一个OpenAPI规范的最小单元,将OpenAPI接口规范数据源通过自动注册或手动填报的方式,保存在平台中后即可进行接口文档的在线预览功能,这样的好处是我们即可以对接口文档进行归档保存,又可以和下游服务联动,打通调试。
  • 文档用户中心: 每一个namespace下的文档都是有鉴权属性的,用户可以选择对齐是否开放,这样的好处是保持接口的🔐安全,避免所有人都能访问

先来看下一界面原型。

命名空间(namespace):namespace列表可以查看所有的项目列表,并且namespac是可以直接访问的,如果当前namespace下面有接口实例,那么就可以通过Knife4j的前端界面进行预览和调试

图2.命名空间

点击namespaceId查看文档效果如下:

图3.命名空间文档展示

服务实例(ApiRegister):是一个OpenAPI规范的最小单元,可以通过接口自动注册上来,也可以通过平台进行主动编辑添加

包括接口的规范类型,数据来源类型,注册类型等等信息。

图4.接口实例

明细信息展示如下:

图5.接口实例文档展示

同样,当个APIRegister也是可以独立访问的,平台提供的单实例的访问方法:

开发密钥统一管理

开发者开放的API接口,很多时候,如果要对外的情况下,通常开发者们都需要实现接口的鉴权控制逻辑,而如果每个服务或不同的项目都实现一遍,那太耗费精力了,那么我觉得只要是聚合上来的接口文档,所对应的下游服务,都可以通过该平台进行统一的管理,分配鉴权及管理开放用户

下游服务统一管理

一旦涉及到开放平台,那么网关的企业级别高性能要求不可避免,这不是Knife4j的强项,作者也没这个能力,作为开放平台网关层,这里考虑Apache APISIX来实现服务的分发,依靠Apache APISIX提供的Admin API接口,平台通过将下游服务的转发规则进行动态注册,这样接口文档和开放平台就从功能职责上进行了区分,互相存在依赖关系,但职责分工不同

LLM大模型结合

目前,AIGC火热发展的当下,大模型落地更多产品的场景,我觉得是不可避免的,而对于在Knife4jInsight平台中,我目前也想到了一些LLM大模型可以落地的场景,主要包括:

  • 接口的i18n转化:本身Knife4j提供的界面目前是支持中英文的,但是开发者如果要提供英文的接口文档描述,通常在项目开发阶段,或者定义OpenAPI接口规范时,技术层面就需要提供支持,而如果通过平台中大模型的翻译工具,基于Prompt工程,将OpenAPI数据源直接生成对应的目标语言,那么开发者就无需在技术启动接口考虑i18n的事情,Knife4jInsight平台中自动集成即可快速实现。

    图6.LLM大模型

  • 代码模版:将Prompt工程+OpenAPI规范结合,植入到Knife4j到每一个功能点中,包括代码示例生成、curl等等不同的场景,调试LLM大模型的Prompt工程,将幂等性的接口输出到应用测,给予开发者更多的便利。

    图7.LLM大模型

结尾

以上就是我的一些新想法,如果您对该产品感兴趣,欢迎和我联系(xiaoymin@foxmail.com)~~~