項目中怎樣做技術選型
引出四個維度
工作快十五年了，從十年前開始經常會有新項目，需要從頭開始做方案和設計。做技術選型很少成為我的難題。不是因為這方面我多有方法，而通常是很少有選擇。在做技術選型的場景下基本有以下四個維度：
維度一
從系統構成上有兩種：
第一種，有之前的老系統，需要重構
第二種，從零開始建的服務
維度二
從穩定性要求上有三種：
第一種，現在沒有什麼業務量，將來估計也不會有什麼增長，甚至很可能不成
第二種，現在沒有什麼業務量，將來對穩定性要求很高
第三種，現在對有穩定性要求很高
維度三
從環境上有三種：
第一種，公司有很多基礎設施
第二種，公司有一些基礎設施
第三種，公司基本沒有基礎設施
維度四
從要求上有兩種：
第一種，公司有標準化規範，需要用公司的統一組件
第二種，公司沒有要求
各個維度組合的選項考慮
從零開始項目現在沒有什麼業務量，將來估計也不會有什麼增長
從目標上，遇到這種項目，工作的重心就不在於把項目做好做壞，而在於人員培養。
如果公司對組件上沒有什麼要求，那我的建議是大家想學什麼，就用什麼。直接拿學習的試驗田來用，一舉兩得。
如果公司有標準化規範，需要用公司的統一組件。但是公司的組件一般也是開源進行二次開發的，也一樣可以想學什麼就用什麼，弄不明白的，還可以找維護組件的人請教。也可以用公司自研的，但是在業界有一定知名度的產品。研究的好可以作為面試的一個亮點。
瞎舉個例子哈：
一六年、一七年做P2P並且不合規的公司，眼看就不行了。有的團隊用的kafka，就是為了學習這個東西；有的團隊自己搭建redis集群也是為了學習。
從零開始項目現在沒有什麼業務量，現在或者將來對穩定性要求很高
從目標上，這個是產生業績的最佳項目，要精心規劃。
做這種項目需要做好調研，包含業界調研和公司調研。業界的同類產品是怎麼做的，有哪些缺點和優點。公司有沒有同類或者可以登高類比(登高類比是指先找相似度最高的，找不到在逐漸擴大範圍)的，那些項目遇到過哪些坑或者問題，是否和架構或者技術選項有關。
在做好調研基礎上，如果公司對組件上沒有什麼要求，那就需要根據項目本身的特點綜合比較。舉例如下圖：
不考慮項目本身特性，使用技術通用的考察項主要有：優勢、劣勢、技術成熟度、社區活躍度、資料豐富程度、是否有大牌公司在持續維護。
可參考我之前的文章《SpringBoot整合web容器》裡面有介紹我當初對tomcat還是jetty選擇的考慮點。
如果公司有標準化規範，需要用公司的統一組件。
這時候，如果公司的組件可選性很多，比如之前美團的監控告警組件就有cat、digger、tracing、大白等。這時候一方面考慮各個組件的側重點和自身是否切合，最重要的是要看其他團隊都用什麼。周圍團隊用的很少，咱們也不要用了。兄弟團隊有福同享有難同當，如果大家都用這個，組件穩定性有問題了，影響的不止一個團隊，也相互有個依靠。就自己用了還出事了，額，讓我想起一句歌詞：「多少秘密在其中 欲訴無人能懂」—–一簾幽夢。暴露年齡了。
如果公司的組件只有一個，也要看看兄弟團隊有沒有在用，還需要組件團隊給提供相應的SLA，對於還在推廣中的組件要謹慎。
重構老系統現在沒有什麼業務量，將來估計也不會有什麼增長
建議放棄重構！
重構老系統現在沒有什麼業務量，將來對穩定性要求很高
參考從零開始項目現在沒有什麼業務量，現在或者將來對穩定性要求很高的方法。
重構老系統，現在對穩定性要求很高
建議選型盡量和之前保持一致，以便於和之前的邏輯盡量一致。避免踩到特殊需求導致的特殊邏輯等坑。
實在不能一致，比如十二年前我們有個「新鮮事」中間件，類似於網頁版的發朋友圈吧。之前是用c++寫的，後來c++的同事都離職了，要求我們改成java。這時候要考慮的主要是技術的成熟度。這個成熟度包含業界技術本身的成熟度和團隊成員對技術的熟練度。
對於這種類型，還有幾句忠告：
不要特立獨行，要合群！
使用成熟的技術！
使用成熟技術的成熟功能！
最後對使用成熟技術的成熟功能做個解釋說明：比如redis很成熟了，redis有很多高級特性，比如訂閱轉發，穩定性要求高的不要用。用更加成熟的常用做訂閱轉發的比如MQ!
往期推薦
