Knife4jInsight的产品开发历程
前言
大家好，在昨天Knife4jInsight平台版-MVP版本v1.0.0发布之后，在Knife4j的交流群分享说，希望Knife4j后面的版本，不管是开源版本还是商业版本，希望以：开源项目生态+付费产品闭源+Build On Public的模式一直走下去！！！
今天这篇则是践行Build On Public策略，分享在开发Knife4jInsight过程中的一些感悟及想法！
在很早之前分享的Knife4j v5.0 产品规划分享里面，我提到希望重写Knife4j的前端实现，并且能够将工具事项一直发展先去，把Knife4j始终定为一个工具组件，提供一些让开发者在日常文档开发过程中方便使用的功能为先。
而在大概2个月前，我在交流群时常会碰到很多人在问Knife4jInsight开源版本的问题，在之前Knife4jInsight开源版本中，我主要实现了讲各个注册中心进行集成，所有的数据源存储在本地磁盘或者Nacos配置中心作为数据源来存储。我个人认为在思路上是没有什么问题的，但是在产品的使用上，程序员思维太验证了，没有提供一个可操作的界面供用户操作使用，提了一些概念，对用户使用来说，现在回想起来简直是灾难。基于这个想法，加上后面对希望Knife4j改版的热情，就产生了将开源版本Knife4jInsight转换为付费版本的想法。
主要考虑一下几点：
降低之前开源版本Knife4jInsight的使用难度，提供可操作的可视化界面，简化流程和概念 将开源版本中一些无法实现的企业需求都灌注在这个平台版本中进行实现,毕竟这是一个独立运行的平台，可以很好的整合各种业务需求，而Knife4j开源版本是单体组件,碰到很多有意思的需求时,往往会存在瓶颈 商业产品和开源版本共同驱动的模式,开源产品能很好的吸收用户的反馈声音以增强改进软件迭代发展,而商业产品能保证Knife4j这个开源作品使作者获取一些微薄的收入,投入更多的时间去维护项目的开发，我觉得是一种正相关的开发模式，毕竟我们见过太多靠爱发电的开源项目最终都停更了，Knife4j目前也基本是靠爱发电的项目
确定了想法之后，说干就干，最终在Xmind大致罗列了下这个产品最终的具体事项，主要4个方面，如下：
系统用户：平台既然以OpenAPI规范数据源管理为主，而OpenAPI规范是企业的数字资产,那么用户功能必然必不可少,接口文档是企业的隐私,需要用户权限来限定谁可以访问,谁不可以访问 平台特性：主要是确定平台的特点及功能风格 主要功能：确定确定MVP版本的基础功能 进度计划：开发迭代这个产品需要确定的计划事项
系统用户
平台以OpenAPI规范数据源管理为主，而OpenAPI规范是企业的数字资产,那么用户功能必然必不可少,接口文档是企业的隐私,需要用户权限来限定谁可以访问,谁不可以访问。
在用户层面，以用户和角色进行展开：
用户：平台使用者，可以注册(基于Email)使用的用户,登录后可以维护OpenAPI规范数据源 角色：平台主要分两个角色(平台用户、管理员) 平台用户：角色是平台的最小可用角色，仅可以使用平台 管理者：则可以对用户进行统一管理，在标准版中，会分配1个默认管理者账号，管理者对用户进行创建、禁用、重置密码等操作
平台特性
平台特性主要是确定平台等风格，如下图：
界面排版：习惯了所有菜单风格的我，这次决定使用一下上下风格的模式 文档访问：对于文档的访问，可以开放鉴权功能，对于需求鉴权的文档，用户访问时则需要校验登录，否则不予访问 数据隔离：每个用户的数据都是相互之间隔离的，只能看到自己的数据
主要功能
主要功能则是在开发MVP版本期间确定的功能以及想到的后期一些扩张功能，如下图：
NameSpache(命名空间)：命名空间是平台中抽象的概念,一个namespace下可以允许存在多个OpenAPI规范实例，用户可以讲该功能理解为企业、项目、部门、产品等等 **ApiRegister(OpenAPI规范数据源):**服务实例是一个OpenAPI规范的最小单元,讲OpenAPI接口规范数据源通过自动注册或手动填报的方式,保存在平台中后即可进行接口文档的在线预览功能 **用户中心：**平台用户可以参与OpenAPI文档的建设及授权,用户数据之间完全隔离 授权中心：Knife4jInsight在线版本的功能，对用户购买后的license授权及查看等操作 登录/注册：在线版本保持了基于邮箱账号的注册/找回密码等功能，而在私有化标准版本中，用户的注册等操作没有，需要管理员账号进行开户操作
至于二期功能，则是在开发过程中想到的一些功能点，在xmind中记录，后来我把这些功能又单独在项目的官网文档上进行了维护，主要是产品的RoadMap
官网功能RoadMap地址：http://knife4j.net/roadmap/
后期的功能：
平台管理OpenAPI数据源接口文档自动i18n,支持中英双语
对于注册上来的OpenAPI数据源,平台基于开放的翻译API接口对OpenAPI结构进行解析，解析完成后自动翻译文档注释说明，这样我觉得企业开发者在做i18n文档国际化时，在代码层面只需要按常规的固定流程开发即可,而无需从代码框架层面实现i18n，整合i18n功能到平台中可以不止做一种语言，后面扩展更多的语言支持也是及其方便的
微服务OpenAPI规范数据源自动注册上报
目前MVP版本还是手动上报填写，但平台已经预留了接口自动上报的函数接口，基于用户的开发密钥，将自动上报功能整合到Knife4j开源的各项starter组件中，开箱即用，即可在项目启动后自动上报OpenAPI规范数据至Insight平台中，这样即可避免各种404、鉴权等集成Knife4j组件的问题，开发者只需要将Insight平台中的文档提供出去即可进行接口对接
整合开源swagger-ui组件，平台中可进行OpenAPI规范接口设计
开源Swagger-editor组件提供了在线设计接口及所见即所得的能力，整合后可以先设计规范接口，后实现代码，后期还可以考虑整合OpenAPI规范生态的代码生成功能,在线提供各种导出、代码生成等功能
打通开源注册中心(Nacos\Eureka\Consul等等),获取服务中的OpenAPI数据源
微服务开发是目前当下主流的开发技术栈，而打通各个注册中心则可以在平台端主动去pull拉取各个子服务的OpenAPI数据源，对于手工填写OpenAPI规范管理提供了便利，和微服务OpenAPI规范数据源自动注册上报功能相比，一个是主动pull拉取，而另外一个则是被动推送到Insight平台，是两种策略
进度计划
确定好了功能，那么就是计划排期了
计划排期
开发一个产品要做的事情针对太多了，首先是确定MVP版本的开发周期
因为作者也是在职，所以不可能全职参与这项工作,只能是利用下班后或周六周日的时间来进行开发，MVP版本也是保证产品的最小可用版本，所以计划的是花1-2个月的时间来完成
以下是GitHub的提交记录，大概从7月份开始有想法之后，开源和产品的迭代基本上是每天一有空闲则进行代码的提交
上线准备
当项目功能开发完成后，需要做一些上线准备的事情，这里面主要包括：
云服务器：既然有在线试用版本，那么云服务器是跑不了的,在开发技术选型阶段，所有的功能都是以单体架构进行技术选型，后面我会把平台的技术选型分享出来，主要是避免大量中间件的使用，节省资源成本。在云服务器成本上主要是两个： ECS：购买了阿里云的ECS服务器，张家口的节点，2c4GB配置，带宽4M RDS：购买的是腾讯云的MySQL，配置1c1gb，20gb存储，三年648 官网域名：既然是商业化产品,官网域名跑步了，干脆就以开源项目Knife4j进行命名，最后发现 .com和.cn的域名都已经被人注册了😂，最后发现knife4j.net的域名还在，那就自己注册了吧，85RMB/年，net的域名比com和cn略贵一些，购买域名之后，就是域名备案了，前后大概花了半个月左右吧，备案真的周期太长了官网文档：有产品、有域名，最后就是写文档了，考虑到我也非专业前端人员，写css不是我的强项，我只会写markdown，那就市面上选一个markdown的文档生成产品吧，主要参考有很多，我之前都用过，包括 docusaurus、vuePress、VitePress,最终被VitePress的界面风格吸引，加上是新的，所以就选择用vitepress来写官网文档了，文档编写前后大概花了一周的时间
运营推广
开发好了，也上线了，就考虑推广的事情了，另外也要考虑产品的定价
**产品定价：**对于产品的定价，既然是工具组件为主,我所期望的是还是更平民一些，更高的价格则代表着更高的要求和产品价值,Knife4jInsight是一个初次尝试的商业化产品，我觉得获得市场认同感很重要，毕竟商业版我更多的想法也是想驱动开源Knife4j版本的迭代更新，是开源版本Knife4j的补充，企业需求的能量池，更多的算是一种开源变现的手段吧，就定价在49.9/年
产品license：license是软件启动时所需要的,在思考license职责过程中，我也思考了很多，比如使用期限、边界、产品交付物等等方面，最终思考如下：
购买的License是永久期限使用,没有时间限制
License限定部署域名(最大支持5个域名/ip授权),避免license传播泛滥
License限定平台更新周期,平台免费更新期限1年
即自购买该license后，Knife4jInsight在之后1年内的任何版本更新，都可以使用该license进行免费更新,超过期限后的新版本,则需要重新购买license
运营推广：之后产品上线后就是运营推广了，我觉得这是一个长期的事情，在保持对产品的持续迭代输出之余，通过公众号或者官网文档、技术交流群等，都可以进行推文，写文章也算是一种锻炼，而践行Build On Public历程我觉得对于我自己来说也是一种不同的开发体验，即使是在开源项目中。
公众号的推广包括对平台的介绍、功能介绍，这个在后期的开发迭代阶段会一一分享 开发历程、自己的思考及产品的价值 技术的选型，每个功能的想法及价值思考 等等很多方面的内容都可以一一写出来
最后
Knife4j并不完美,期待Knife4j及Knife4jInsight与用户一起共同成长见证～～～
官网地址：http://knife4j.net/