软件选型的那些事儿
作者：WU双
编辑： 任朝阳
2021-03-17 15:43
来源：ITPUB
在软件开发过程中，我们经常会遇到软件选型的问题。
因为业务需求不同，有的需要使用消息中间件，有的需要使用缓存，有的需要用新框架，那么面对如此多的技术，我们到底该如何选型呢？今天，就和大家聊一聊技术选型那些事儿，到底该如何选，怎么用。
我相信业务用的好好的，没有性能瓶颈，没有合规要求，也没有新需求要开发，我们也不会想着换个框架或组件。当业务有真正的诉求的时候，比如有数据同步，业务解藕，削峰填谷，分布式事务等需求时，我们就需要调研相应的解决方案了。这个时候往往会面对很多的软件，究竟该选哪个，用哪个？如果有团队成员比较熟悉的以前用过的软件，可能大概率就会选择它，毕竟用过有经验，遇到问题也知道怎么解决。但如果团队成员都没有用过，这个时候面对如此多的软件，而且在有限的时间里，我们到底该如何选择呢？或者说软件选型该考虑哪些呢？今天和大家分享一下个人的经验，希望能对大家有所帮助。
想用消息中间件，需要调研的对象可能有RabbitMQ，RocketMQ，Kafka等。有数据同步的需求，需要调研的对象可能有otter，Datax，canal等。想用rpc服务，调研的对象可能有Dubbo、gRPC、Thrift等。这里就不再一一展开了，其实想说的就是，首先我们要知道调研的对象，接下来就需要看看到底要调研哪些内容。
调研的内容
软件的系统架构很大程度上决定了软件的简单或复杂、可扩展性、高可用性等较难改变的属性。软件的官网中一般都会有相应的架构图，从中我们可以看到软件的基本组件，架构的简易程度等内容。比如下图为RocketMQ的架构图，从中可以看出RocketMQ的基础组件有NameServer Cluster、Broker Cluster，还能进一步看出NameServer Cluster的基本职责有Broker Discovery，以及Broker Cluster可以通过数据同步来实现高可用等内容。除了系统架构，我们可能还需要关注下软件的实现语言，如果以后需要进行定制化开发，团队成员是否有相应能力。
软件的社区情况，是我个人在软件选型的时候着重考虑的一个点。活跃的社区对于开源软件来讲很重要，因为活跃的社区说明软件的用户很多，用户多就有很多的实践经验可以参考交流，在你遇到问题的时候能有个交流的平台。总之，活跃的社区能够帮助你解决软件使用过程中的很多问题。那么从哪几个方面可以考量软件的社区情况呢？这里主要讲的是开源软件的社区情况考量。我个人一般会看软件的最近一次提交是什么时候，issue的数量及回复情况，更进一步可以看软件的邮件列表内容。详细的产品文档包括但不限于软件架构，用户手册，性能测试，常见问答等。如果你在调研相应软件的时候，发现找了很久也没找到架构图、用户使用手册等内容，那你就要好好考虑该不该用这款软件了。通读产品文档可能需要花上一些时间，但花这个时间是很值得的。通读产品文档可以让你对整个产品有个大概了解了，有哪些特性，有哪些功能，性能表现如何等，这些你都能做到心中有数。Spring的文档是我个人认为非常好的文档，不夸张的说，能把Spring文档通读一遍，80%的Spring问题对你来说都不算问题。另外文档最好读官方的，如果是国外的软件，尽量读英文的。
包括但不限于合规性，法律，生态工具等内容，比如如果使用的开源软件协议为GPL，按照协议规定，所有的二次开发都应该再次开源出来。
特性或功能验证
调研完产品后，我们对软件应该有了个大概了解了，此刻我们需要回到业务上来。产品的特性或功能能否满足业务的需求，这才是决定我们选型的最重要原因。一般的原则是，能够满足当前以及可预见的未来的需求的软件，是最合适的，因为这样的软件又能满足需求，又不至于太过复杂。此阶段一般会进入到体力活环节，需要各种测试，比如基本功能测试，高可用测试，性能测试等。在测试的过程中也尽可能的将测试脚本化、自动化，因为这个过程可能会重复多次，没人想一次次的手动来做。这里的测试一般需要给出结论，即当前软件是否能够满足业务的各种需求。该阶段一般会遇到很多的问题，而活跃的社区，详尽的文档可以帮助你解决这些问题，同时团队成员应该尽可能的在该阶段积累软件使用的过程资产。应用阶段
如果软件是基础软件比如数据库之类，一般会先进行试点应用，因为基础软件的影响面比较大，而选择试点应用，既可以规避大的风险，也能够通过实践积累起经验，方便后续的全面升级。如果软件只是当前业务使用，影响较小，那么要有自信直接上，不要怂～
帮助别人
经历了软件调研，功能特性验证，到项目的正式使用，可以说现在你也成为了软件社区中的一员，那么不要忘了分享你的使用经验，帮助其他软件使用者，毕竟一开始也是社区帮你解决了问题。
软件的调研阶段需要关注产品架构、社区、文档及合规性、生态工具等内容。调研完软件需要回到业务上来，进行功能特性的验证，看是否能满足业务需求，各类测试也尽量脚本化、自动化。
0
