查看原文
其他

Knife4jInsight平台版-MVP版本v1.0.0发布

八一菜刀 Knife4j 2023-09-20

在之前发布的《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**而来,整合开源单体组件中无法解决的企业级需求场景
  • 🔒 聚焦Swagger2OpenAPI3AsyncAPI等接口规范的文档展示调试功能
  • 🏝️ 提供OpenAPI规范接口文档的存档、历史版本、预览、调试、导出、鉴权等一系列功能操作
  • 🏝️ 为开发者提供统一的OpenAPI接口文档开放、预览、调试服务,开箱即用
  • ⛺ 未来,我们是:统一OpenAPI接口开放平台统一OpenAPI接口文档管理平台

产品名称

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

但我还是更钟意Knife4jInsight,主要有几层含义:

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

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

技术架构

技术架构图如下:

img

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

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

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

功能架构

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

功能架构图如下:

img

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

  • 开放文档的统一管理:借助于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数据源待开发--

产品首页:http://knife4j.net

产品试用:https://console.knife4j.net

期待Knife4j和Knife4jInsight齐头并进,创造更好的产品服务!!!


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存