写在开头
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这个项目应该如何发展下去，如果做新产品，与市面上已经存在的其他产品如何做差异化的竞争。
思来想去，我又有了新的方向和目标～！
折腾新产品的心态一直没停过。。
市面上的产品包括Postman、Apifox、Apipost等等，专注在自己的领域里面，覆盖面都挺广的，而Knife4j好像以Ui界面交互起家，受众要宅一些，想想这些产品的词云关键字：API文档、调试、协作、测试、API设计等等
每一个关键字里面所需要投入的精力，都是Knife4j无法企及的，而且我在很早之前分享Knife4j的定位时，我一直想把他作为一个工具输出，单纯的工具，因此，包括：协作、涉及、自动化等等标签，都不适合我
那么，应该做什么？做一点不一样的呢？
Knife4jInsight这个产品的思路我自认为还是得发展下去,只不过需要更加产品化一下，做成平台，给用户提供更方便的可操作化的界面，简化整个使用步骤。
基于这个想法，和脑子里蹦出了一些新的Idea，包括：开放平台、接口展示、LLM大模型。
我有了一个产品的大致雏形，我画了一个草图，大概是这个样子：
在上图中，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的前端界面进行预览和调试
点击namespaceId查看文档效果如下：
服务实例(ApiRegister):是一个OpenAPI规范的最小单元,可以通过接口自动注册上来，也可以通过平台进行主动编辑添加
包括接口的规范类型，数据来源类型，注册类型等等信息。
明细信息展示如下：
同样，当个APIRegister也是可以独立访问的，平台提供的单实例的访问方法：
开发密钥统一管理
开发者开放的API接口，很多时候，如果要对外的情况下，通常开发者们都需要实现接口的鉴权控制逻辑，而如果每个服务或不同的项目都实现一遍，那太耗费精力了，那么我觉得只要是聚合上来的接口文档，所对应的下游服务，都可以通过该平台进行统一的管理，分配鉴权及管理开放用户
下游服务统一管理
一旦涉及到开放平台，那么网关的企业级别高性能要求不可避免，这不是Knife4j的强项，作者也没这个能力，作为开放平台网关层，这里考虑Apache APISIX来实现服务的分发，依靠Apache APISIX提供的Admin API接口，平台通过将下游服务的转发规则进行动态注册，这样接口文档和开放平台就从功能职责上进行了区分，互相存在依赖关系，但职责分工不同
LLM大模型结合
目前，AIGC火热发展的当下，大模型落地更多产品的场景，我觉得是不可避免的，而对于在Knife4jInsight平台中，我目前也想到了一些LLM大模型可以落地的场景，主要包括：
-
接口的i18n转化：本身Knife4j提供的界面目前是支持中英文的，但是开发者如果要提供英文的接口文档描述，通常在项目开发阶段，或者定义OpenAPI接口规范时，技术层面就需要提供支持，而如果通过平台中大模型的翻译工具，基于Prompt工程，将OpenAPI数据源直接生成对应的目标语言，那么开发者就无需在技术启动接口考虑i18n的事情，Knife4jInsight平台中自动集成即可快速实现。
-
代码模版：将Prompt工程+OpenAPI规范结合，植入到Knife4j到每一个功能点中，包括代码示例生成、curl等等不同的场景，调试LLM大模型的Prompt工程，将幂等性的接口输出到应用测，给予开发者更多的便利。
结尾
以上就是我的一些新想法，如果您对该产品感兴趣，欢迎和我联系(xiaoymin@foxmail.com)～～～