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

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

首要一定要了解清楚背景

首要一定要了解清楚背景，只有背景了解清楚了，大家才能在同一個起點(diǎn)上做相關(guān)的決策和討論，技術(shù)方案一定是某個背景下產(chǎn)生的，如果脫離實際業(yè)務(wù)背景，那么技術(shù)方案也無法選擇最優(yōu)的。

(資料圖片僅供參考)

這個背景包括的點(diǎn)會比較多，比如當(dāng)前業(yè)務(wù)狀況、未來發(fā)展情況、當(dāng)然人力情況、現(xiàn)有技術(shù)方案等等所有相關(guān)的。

技術(shù)方案的選擇需要團(tuán)隊內(nèi)部的人員相匹配

技術(shù)方案的實現(xiàn)是需要團(tuán)隊內(nèi)部的開發(fā)人員來具體實施的，因此一定要考慮團(tuán)隊內(nèi)的人員具體情況，并且所選擇的技術(shù)方案需要和團(tuán)隊內(nèi)部的人員相匹配。比如編程語言、團(tuán)隊規(guī)模、公司業(yè)務(wù)、公司體量。比如當(dāng)前這個方案技術(shù)人員是否接觸過、編程語言是否熟悉、技術(shù)人員是否能夠完全掌握這個方案等。

但是注意，這里不是說選擇完全熟悉的領(lǐng)域或者方案，但是一定是考慮的因素，因為，如果你團(tuán)隊技術(shù)人員完全不懂這個技術(shù)、語言也不熟悉，選擇這個方案后，壓根就扛不住啊。 但是如果你團(tuán)隊的人員足夠多，技術(shù)功底足夠扎實，那么選擇一個不熟悉的方案能夠抗住也是 ok 的。

參照業(yè)界標(biāo)桿選擇技術(shù)方案（開源方案）

業(yè)界標(biāo)桿選擇的技術(shù)方案，一定是經(jīng)過他們專業(yè)人士對比、選型之后決策得到的，并且經(jīng)過了他們的大量的線上實際驗證的。因此參考業(yè)界標(biāo)桿，至少不會出錯，但是這個僅僅只是一個參照，是否合適自己團(tuán)隊，還要結(jié)合本文的其他一個點(diǎn)來考慮。

這里的業(yè)界標(biāo)桿，盡量的是選擇國內(nèi)外都流行的而不僅僅是國內(nèi)流行的，技術(shù)這個東西一定是一個全球化的東西，不是一個局域化的事。所以，一定要選國際化的會更好。

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

功能點(diǎn)是否滿足業(yè)務(wù)需求，先看是否滿足業(yè)務(wù)訴求，而不是先看開源方案是否更加優(yōu)秀，一定是在滿足業(yè)務(wù)訴求的基礎(chǔ)上再去做抉擇。一線互聯(lián)網(wǎng)公司的落地產(chǎn)品如果是一線互聯(lián)網(wǎng)公司落地并且開源的，且在社區(qū)內(nèi)形成良好口碑的產(chǎn)品，那么這些產(chǎn)品已經(jīng)經(jīng)過了大流量的沖擊，坑已經(jīng)基本被填平，且被社區(qū)接受形成一個良好的社區(qū)生態(tài)。那么這樣的產(chǎn)品算是一個比較好的選擇，才能讓你放心的運(yùn)用在自己的生產(chǎn)環(huán)境中。

* 怎么確定呢？這個就靠 Google 來做一些搜索了，看看有沒有一些案例；或者有一些項目會明確說明業(yè)界有哪些公司已經(jīng)采用

復(fù)制開源社區(qū)活躍度GitHub 上的 stars、 commit、issue、pull request、release 的數(shù)量和頻率是一個重要指標(biāo)，同時需要參考其代碼和文檔更新頻率（尤其是近年），這些指標(biāo)直接反應(yīng)開源產(chǎn)品的社區(qū)活躍度或者說生命力。

* 另外，對于不同業(yè)務(wù)體量和團(tuán)隊規(guī)模的公司，技術(shù)選型標(biāo)準(zhǔn)往往是不同的，創(chuàng)業(yè)公司的技術(shù)選型和 BAT 級別公司的技術(shù)選型標(biāo)準(zhǔn)可能完全不同。

復(fù)制方案是否具備了生產(chǎn)級的能力我們選擇的技術(shù)方案是要解決實際業(yè)務(wù)問題和上生產(chǎn)抗流量的，選擇不慎可能造成生產(chǎn)級事故，所以生產(chǎn)級，可運(yùn)維，可治理，成熟穩(wěn)定的技術(shù)才是我們的首選；怎么判定是否生成級可用？看 release 版本是否有發(fā)布正式環(huán)境，是否有 1.0 版本。怎么判定成熟穩(wěn)重？ 看是否有一些實際業(yè)務(wù)在使用。運(yùn)維能力也是必須要考慮的，否則一旦出問題，運(yùn)維、研發(fā)、測試都只能干瞪眼.代碼整體質(zhì)量是非常重要的，包括代碼的功能特性、可擴(kuò)展性、性能、可靠性和可用性規(guī)范的代碼風(fēng)格合理的代碼組織結(jié)構(gòu)覆蓋度高的單元測試用例有一定的性能測試數(shù)據(jù)代碼可以較好的進(jìn)行擴(kuò)展代碼的 bug 要少

盡量不要重復(fù)造輪子

盡可能的使用紅利大的主流技術(shù)，而不要自己重復(fù)造輪子，更不要魔改。如果市面上已經(jīng)有比較合適的方案后，我們盡可能的采用主流的開源方案；如果某些場景和功能，當(dāng)前市面上的方案不滿足，我們應(yīng)該是給他們提 PR ，或者自己擴(kuò)展支持，但是還是采用市面上已有的，這樣等他們升級后，我們依然還是可以跟著升級。

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

不要過度設(shè)計

大家都希望自己的系統(tǒng)低耦合，通用性強(qiáng)，可以完成任意的后續(xù)功能的組合，但這也要有個度。

如果你自己認(rèn)為自己的技術(shù)架構(gòu)能力很強(qiáng)，知道代碼在編寫中低耦合高擴(kuò)展，你可以在設(shè)計的時候，在滿足現(xiàn)有需求的基礎(chǔ)上，以不額外增加開發(fā)成本為前提，來做一些擴(kuò)展預(yù)留的考慮。但是，如果你技術(shù)架構(gòu)能力不強(qiáng)，滿足現(xiàn)有需求即可，盡量做到低耦合，代碼要盡可能間接，并寫好代碼注釋。

另外一點(diǎn)就是不要只談架構(gòu)方案設(shè)計，其實代碼層面的設(shè)計也是非常重要的，包括分層/模塊/接口 等一定要考慮好，其實很多時候，與其做一套通用架構(gòu)，不如讓自己的代碼更容易被修改，特別是對于技術(shù)架構(gòu)能力不是特別高的開發(fā)者。

合適才是最重要的

最后，要說明下，合適的才是最重要的，技術(shù)方案和架構(gòu)演進(jìn)不是一蹴而就的，最重要的適合當(dāng)前的業(yè)務(wù)場景需要

舉個例子，當(dāng)前業(yè)務(wù)對并發(fā)的要求并不高，你就沒有必要非得現(xiàn)在選擇一個能夠抗住百萬、千萬的方案，因為這個方案不適合當(dāng)前架構(gòu)，初期構(gòu)造太復(fù)雜，反而會讓你失去焦點(diǎn)，并且讓整體架構(gòu)（技術(shù)方案）逐漸腐爛。

推薦閱讀

推薦閱讀我的其他文章：

《高并發(fā)架構(gòu)和系統(tǒng)設(shè)計經(jīng)驗》

《TCP 長連接層的設(shè)計和 在 IM 項目中實戰(zhàn)應(yīng)用》

《萬字解讀云原生時代，如何從 0 到 1 構(gòu)建 K8s 容器平臺的 LB（Nginx）負(fù)載均衡體系》

《高可用架構(gòu)和系統(tǒng)設(shè)計經(jīng)驗》