传统的选型方式
一般而言,我们会按如下的方式进行选型验证:
- 功能上是否契合。也就是我的需求能通过该组件来完成
- 性能如何(会做一些压测)
- 稳定性如何
- 社区活跃度如何
- 是否能方便和其他的组件配合
如果能通过上面的几条,我么可能就会采用该套技术了。然而这往往会导致很多误用。比如很多人就把zookeeper当存储用了,因为倒也满足上面的一些需求。
基因论
这里的基因指的是,某个开源组件是因为什么而诞生到这个世界的。仍然以zookeeper为例,我们可以说zookeeper 是为分布式协调而诞生的,他的基因使得它适合做这一块的工作。但是zookeeper的很多特性又可以利用在很多领域:
- 配置变更通知
- 集中化的存储
于是有大量的应用围绕这两个功能点开发。这其实就是一种误用。比如Storm 拿 zookeeper存储偏移量,这样就会涉及到频繁的更新,这其实就是不合适的。或许这种场景HBase/Redis之类的存储会更合适些?
我们在选型的过程中过度的考虑了 功能是否匹配,而忽略了开源项目本身的基因,这必然会导致能够实现功能,但是却带来一些不可控的问题。
这里还有一个典型就是Docker,各种滥用导致各种问题,镜像存储问题,虚拟隔离的安全性问题等。如果知道Docker的基因其实是无侵入性的为应用加上资源限制,以及附带运行时环境,就不会各种折腾了。
所以在做选型的时候不妨问问: 我选用的开源组件是为了解决我这个问题而设计和诞生的么?我用的场景是不是吻合他的基因?
时间: 2024-09-20 21:08:24