️This article has been over 1 years since the last update.

当前作为项目SE，长期进行技术选型和设计工作，特此分享开源或第三方软件的选择流程。

核心原则是连续性优先，低复杂性优先，再考虑性能与功能。

License协议

慎重选择，咨询法务。重点

• 开源：“source available”不等于免费使用

• BSL：危险协议，其中的“commercially competitive version”难以定义，比如HashiCorp，MariaDB。这种基本上会被法务给拒绝掉。

常见第三方或开源软件的封装设计

下面的导图为个人整理

业务维度如下，最终实现自己的平台可以随时替换开源软件的版本/实现。

上述设计并没有唯一标准，而是建议参考学习开源且部分收费的项目（比如metabase，sentry，sonarqube）等系统设计。而且如果你希望项目速度快速度过EAP，尽可能采用缝合怪的形式进行包装。

比较容易的方案是基于Sidecar的思路去实现前置代理，将开源软件的安全/可用性/协议问题通过Socket进行封装，屏蔽业务系统对开源组件的直接侵入。

组网与技术维度

持续性

简单优先

优先选择代码量低，依赖少的组件，而不是功能大而全的产品。

比如在进行私有APM工具选型时，我们发现Sentry是业界Top的APM软件。然而即使它非常优秀，技术架构完美，有上百个专业的全职雇员和成熟社区，但是它实在太复杂了（29个微服务，接近上百个表），导致引入生产环境后，没人敢兜底，最终选型被否决。

社区BCM

尽可能选择有赞助的社区或者公司，要求它能贯穿整个软件的生命周期

版本元数据与漏洞

• 建议订阅各种RSS与dependency-bot对齐最新版本，比如fossa等工具
• 尽可能选择LTS版本，除非你需要的特性正在开发中

避免供应商锁定

一般采用Wrapper/sidecar进行隔离（从RPC到Common库隔离都可以，尤其注意业务前端侧的API接口不要直接用开源实现，而要封装一层。当你的软件后期想对外卖，而相关协议比较严格（比如BSL，X-Pack）的开源软件希望去掉时就比较痛苦了。同时还有安全加固的作用，限制可以传递的参数。