技術方案（開源方案）選型的考量和方法論

我的觀點：每個公司的情況不一樣，開發人員的能力和語言也不一樣，因此方案選型需要根據自身情況而定，沒有最好，只有最合適！但是，可以有相關的方法論去幫助我們更好的選擇合適的方案！

首要一定要了解清楚背景

首要一定要了解清楚背景，只有背景瞭解清楚了，大家才能在同一個起點上做相關的決策和討論，技術方案一定是某個背景下產生的，如果脫離實際業務背景，那麼技術方案也無法選擇最優的。

這個背景包括的點會比較多，比如當前業務狀況、未來發展情況、當然人力情況、現有技術方案等等所有相關的。

技術方案的實現是需要團隊內部的開發人員來具體實施的，因此一定要考慮團隊內的人員具體情況，並且所選擇的技術方案需要和團隊內部的人員相匹配。比如程式語言、團隊規模、公司業務、公司體量。比如當前這個方案技術人員是否接觸過、程式語言是否熟悉、技術人員是否能夠完全掌握這個方案等。

但是注意，這裡不是說選擇完全熟悉的領域或者方案，但是一定是考慮的因素，因為，如果你團隊技術人員完全不懂這個技術、語言也不熟悉，選擇這個方案後，壓根就扛不住啊。但是如果你團隊的人員足夠多，技術功底足夠紮實，那麼選擇一個不熟悉的方案能夠抗住也是 ok 的。

業界標杆選擇的技術方案，一定是經過他們專業人士對比、選型之後決策得到的，並且經過了他們的大量的線上實際驗證的。因此參考業界標杆，至少不會出錯，但是這個僅僅只是一個參照，是否合適自己團隊，還要結合本文的其他一個點來考慮。

這裡的業界標杆，儘量的是選擇國內外都流行的而不僅僅是國內流行的，技術這個東西一定是一個全球化的東西，不是一個局域化的事。所以，一定要選國際化的會更好。

在這個基礎之下，我們選擇的時候，不是直接使用，而是要看方案是否具備如下能力：

• 如果是一線網際網路公司落地並且開源的，且在社群內形成良好口碑的產品，那麼這些產品已經經過了大流量的衝擊，坑已經基本被填平，且被社群接受形成一個良好的社群生態。那麼這樣的產品算是一個比較好的選擇，才能讓你放心的運用在自己的生產環境中。
• 怎麼確定呢？這個就靠 Google 來做一些搜尋了，看看有沒有一些案例；或者有一些專案會明確說明業界有哪些公司已經採用

• GitHub 上的 stars、 commit、issue、pull request、release 的數量和頻率是一個重要指標，同時需要參考其程式碼和文件更新頻率（尤其是近年），這些指標直接反應開源產品的社群活躍度或者說生命力。
• 另外，對於不同業務體量和團隊規模的公司，技術選型標準往往是不同的，創業公司的技術選型和 BAT 級別公司的技術選型標準可能完全不同。

儘可能的使用紅利大的主流技術，而不要自己重複造輪子，更不要魔改。如果市面上已經有比較合適的方案後，我們儘可能的採用主流的開源方案；如果某些場景和功能，當前市面上的方案不滿足，我們應該是給他們提 PR ，或者自己擴充套件支援，但是還是採用市面上已有的，這樣等他們升級後，我們依然還是可以跟著升級。

開源方案一般情況下可以滿足我們大部分的需求，部分需求不滿足的時候，需要慎重考慮這個需求點是否真的有必要？是否屬於不可替代需求？

大家都希望自己的系統低耦合，通用性強，可以完成任意的後續功能的組合，但這也要有個度。

如果你自己認為自己的技術架構能力很強，知道程式碼在編寫中低耦合高擴充套件，你可以在設計的時候，在滿足現有需求的基礎上，以不額外增加開發成本為前提，來做一些擴充套件預留的考慮。但是，如果你技術架構能力不強，滿足現有需求即可，儘量做到低耦合，程式碼要儘可能間接，並寫好程式碼註釋。

另外一點就是不要只談架構方案設計，其實程式碼層面的設計也是非常重要的，包括分層/模組/介面等一定要考慮好，其實很多時候，與其做一套通用架構，不如讓自己的程式碼更容易被修改，特別是對於技術架構能力不是特別高的開發者。

最後，要說明下，合適的才是最重要的，技術方案和架構演進不是一蹴而就的，最重要的適合當前的業務場景需要

舉個例子，當前業務對併發的要求並不高，你就沒有必要非得現在選擇一個能夠抗住百萬、千萬的方案，因為這個方案不適合當前架構，初期構造太複雜，反而會讓你失去焦點，並且讓整體架構（技術方案）逐漸腐爛。