開源選型中的基因論

隨著開源元件的日益增多，整個開源社群就像乙個超級大的沃爾瑪，琳琅滿目的開源元件讓人挑花了眼。這裡，我們就談談如何進行選型的問題。

一般而言，我們會按如下的方式進行選型驗證：

功能上是否契合。也就是我的需求能通過該元件來完成

效能如何(會做一些壓測)

穩定性如何

社群活躍度如何

是否能方便和其他的元件配合

如果能通過上面的幾條，我麼可能就會採用該套技術了。然而這往往會導致很多誤用。比如很多人就把zookeeper當儲存用了，因為倒也滿足上面的一些需求。

這裡的基因指的是，某個開源元件是因為什麼而誕生到這個世界的。仍然以zookeeper為例，我們可以說zookeeper 是為分布式協調而誕生的，他的基因使得它適合做這一塊的工作。但是zookeeper的很多特性又可以利用在很多領域：

配置變更通知

集中化的儲存

於是有大量的應用圍繞這兩個功能點開發。這其實就是一種誤用。比如storm 拿 zookeeper儲存偏移量，這樣就會涉及到頻繁的更新，這其實就是不合適的。或許這種場景hbase/redis之類的儲存會更合適些？

我們在選型的過程中過度的考慮了功能是否匹配，而忽略了開源專案本身的基因，這必然會導致能夠實現功能，但是卻帶來一些不可控的問題。

這裡還有乙個典型就是docker,各種濫用導致各種問題，映象儲存問題，虛擬隔離的安全性問題等。如果知道docker的基因其實是無侵入性的為應用加上資源限制，以及附帶執行時環境，就不會各種折騰了。

所以在做選型的時候不妨問問：我選用的開源元件是為了解決我這個問題而設計和誕生的麼？我用的場景是不是吻合他的基因？