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

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

首要一定要了解清楚背景

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

(資料圖片僅供參考)

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

技術方案的選擇需要團隊內部的人員相匹配

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

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

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

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

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

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

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

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

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

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

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

盡量不要重復造輪子

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

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

不要過度設計

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

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

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

合適才是最重要的

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

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

推薦閱讀

推薦閱讀我的其他文章：

《高并發(fā)架構和系統(tǒng)設計經驗》

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

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

《高可用架構和系統(tǒng)設計經驗》