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