Knife4jInsight ，Knife4j 的商业化产品之路

Knife4jInsight ，Knife4j 的商业化产品之路
- 写在前面
- 产品定位
- 产品名称
- 技术架构
- 功能架构
- 产品定价
- 最后

Knife4jInsight ，Knife4j 的商业化产品之路

在之前发布的《Knife4j新产品的想法》一文中，我提到想给Knife4j的生态做一些扩展，区别于目前市面上不一样的功能或者工具产品。

主要还是聚焦在Knife4j这个开源项目上，然后将自己的一些想法进行输出,并将一些在单体工具组件中无法解决落地的需求场景，共同灌注在这个新的产品中。

今天,Knife4jInsight平台版-MVP(Minimum Viable Product)最小可行性版本v1.0.0终于来了

Knife4jInsight是简单、方便的OpenAPI接口规范文档聚合开放平台！

产品地址：http://knife4j.net

写在前面

在很多年前，我的工作中的老大哥卢员外(微信公众号:土猛的员外)，那时候我们经常讨论如何创造产品、一个公司的产品及商业模式要如何保持市场竞争力，多年过去了,令我印象最深刻的就是
三级火箭理论

**第一级火箭:**提供基本产品或服务，搭建高频头部流量
**第二级火箭:**沉淀用户的商业场景，吸引更多用户和收入；
**第三级火箭:**完成商业闭环，创造更多价值。

以360的产品三级火箭为例：

360的第一级火箭是免费杀毒工具。它利用这级火箭打破了持续10年的杀毒软件市场三国鼎立的局面，成为用户量最大的安全工具

360的第二级火箭是从免费杀毒工具变为安全网络平台，进而推出360安全浏览器和360安全网址导航

360的第三级火箭就是它最终承载的商业闭环，从安全浏览器和网址导航的广告收入，获得企业的经营利润

在迄今为止,我给Knife4j造了一些生态组件，主要如下：

✅ Knife4j：开源ui库,区别于官方swagger-ui组件，根据OpenAPI规范，重写ui交互，开发者在文档预览及调试时可以拥有不同的文档体验
✅ Knife4j-aggregation: 基于Servlet体系下的聚合组件,打通众多注册中心实现聚合
✅ knife4j-gateway：基于Spring Cloud
Gateway网关组件下的聚合组件，开发者在网关组件下聚合微服务OpenAPI接口只需要简单的4行配置即可完成聚合，为开发者提供文档聚合能力的同时，也有效降低了开发者的学习成本

将三级火箭理论应用到开源项目Knife4j上面，到今天为止，我觉得算是勉强完成了第一级别的火箭路程，我也希望能够将这个项目一直维护下去,按照这个产品理论去执行,算是一种人生经历。而Knife4jInsight平台版本的诞生，我觉得是时候去落地一些商业化的场景了

我不确定现在三级火箭理论是否已经过时，但创造更好的产品一直是每个技术人应该追求的目标

如果将开源项目Knife4j比做一次创业,那这正是一次践行实战之旅，做商业化的场景需求落地，从这个产品本身而言我觉得有几个好处：

产品本身是来源于社区,Knife4jInsight和开源Knife4j组件并不冲突，一个是单体组件,一个是平台,职责会有所不同
来自商业化产品的挑战,付费用户驱动者产品的迭代更新,提供更好的产品功能和服务
商业化产品的更新迭代以及开源项目同驱动项目的发展,在哪怕得到一小部分资金收入的保障,对于开源作者也是一种宝贵财富,避免项目停更烂尾
个人想法的践行与市场的融合,是挑战，令人兴奋

产品定位

该产品主要功能定位：

🌱 基于开源项目**Knife4j**而来，整合开源单体组件中无法解决的企业级需求场景
🔒 聚焦Swagger2、OpenAPI3、AsyncAPI等接口规范的文档展示和调试功能
🏝️ 提供OpenAPI规范接口文档的存档、历史版本、预览、调试、导出、鉴权等一系列功能操作
🏝️ 为开发者提供统一的OpenAPI接口文档开放、预览、调试服务，开箱即用
⛺ 未来，我们是：统一OpenAPI接口开放平台、统一OpenAPI接口文档管理平台

产品名称

给产品取名是一件令人头痛的事情，从目前的功能定位来看，可能将该产品命名为Knife4jCloud
可能更合适一些，cloud意为云数据中心，将Knife4j界面功能提供的数据整合到云上，进行统一处理。

但我还是更钟意Knife4jInsight，主要有几层含义：

语意上,Insight有洞察之意,对于聚焦在API接口领域而言，提供对OpenAPI接口的全方位洞察、了解
不仅仅只是将OpenAPI接口进行云上数据聚合,区别于Cloud，这为以后产品的新功能扩展迭代奠定基调
作为OpenAPI接口的平台,平台的职责需要把OpenAPI接口内容讲清楚,说明白

哪怕目前Knife4jInsight还没有达到产品名所定位的寓意高度,但也这驱使我们努力向前,为客户创造更有价值的功能。

技术架构

技术架构图如下：

技术架构平台的定位是开放平台和接口文档管理平台进行职责区分：

OpenAPI接口开放平台：对于开放平台的接口路由，统一通过Apache APIXIS实现服务的鉴权及下游服务的转发
OpenAPI接口文档平台：对于OpenAPI接口文档的预览、调试，则由平台进行统一处理，提供基于开源项目Knife4j的文档展示方案

在Knife4jInsight的前期，我们着重先把OpenAPI接口文档平台的功能做好，因为产品依靠开源项目Knife4j起家,这是该产品的本职工作.

功能架构

在功能架构中，我们加入了一些未来产品要加入的功能,虽然目前MVP版本并未实现,但会在迭代Knife4j开源版本的同时,保持对该版本的升级迭代

功能架构图如下：

在功能上，主要是三大块的功能：

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

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

产品定价

Knife4jInsight版本是商业化产品,但是我想既然面对的主要群体都是开发者,虽然是平台，但也更多的是工具,为开发者提供方便的工具

也思考了良久，最终产品价格定价在49.9元，主要是软件license的价格

主要体现在：

在目前Knife4jInsight在线版本中，可以在线体验，付费后不限Namespace、ApiRegister的数量
以Docker镜像提供交付,开发者可以将该版本独立部署在私有环境,保证企业数据安全
购买的License是永久期限使用,没有时间限制
License限定部署域名(最大支持5个域名/ip授权)
License限定平台更新周期,平台免费更新期限1年

即自购买该license后，Knife4jInsight在之后1年内的任何版本更新，都可以使用该license进行免费更新,超过期限后的新版本,则需要重新购买license

技术支持、技术咨询、开源社区issue、开发交流群

有任何技术问题可通过社区issue、交流群找到作者进行沟通反馈，或者通过邮箱:xiaoymin@foxmail.com与作者取得联系

Knife4jInsight提供了在线版本，域名：https://console.knife4j.net

开发者可以在线试用,及完成license的购买行为

最后

目前是Knife4jInsight的MVP版本，该产品还在发展中，我给该产品规划了roadmap，主要如下：

如果您有好的想法或者建议，可以通过在开源项目Knife4j
中提issues
或者discussions进行反馈

功能	进度	发布日期	发布版本
平台管理OpenAPI数据源接口文档自动i18n,支持中英双语	待开发	`-`	`-`
微服务OpenAPI规范数据源自动注册上报	待开发	`-`	`-`
整合开源swagger-ui组件，平台中可进行OpenAPI规范接口设计	待开发	`-`	`-`
打通开源注册中心(Nacos\Eureka\Consul等等),获取服务中的OpenAPI数据源	待开发	`-`	`-`