如何進行技術選型
技術選型的一個基本原則是： 求穩，適當求新。
其實，很難說什麼技術是“穩”的，那都是相對的。衡量一項技術的“穩”可以從以下幾個指標判斷。
1、社群活躍度高
現在IT技術的社群無非是三大陣地：官網，GitHub，以及前兩者衍生的產品/服務。
在進行技術選型的時候，當然是挑活躍度高的技術。
活躍度高，自然知名度就高了，也能很快為大家所熟知和學習。所以，活躍度高，也可以認為其推廣度也是不錯的。
比如官網建設的完整程度，以及更新的頻次。
而GitHub上面的Star那是更為直接的指標了，為了求穩，還得留個心眼：看看issues。因為可以從使用者提出的issues裡面能看出一項的缺陷多不多，是不是我們能夠接受的程度。
當然，還有的技術是再造生態系統了，已經脫離了技術的純粹性意義了，比如Python，Docker，Elastic。順便說一下，Elastic已經提交IPO了！
不過，還有一種技術也會有極高的活躍度：有極大爭議的技術。
這種情況只能持有更為謹慎的態度了，除非到了非用不可的地步了。
2、技術有前瞻性
這個指標不太好量化，所以不是很好把握，更多的是靠技術管理者的經驗了。技術前瞻性指標是可以作為社群活躍度指標的延續，換言之，如果一項技術具有較高的前瞻性，那麼其社群活躍度是會持續走高的，可能在一個爆發節點會達到巔峰，就像在國內的Python之於AI。
但是，我始終堅信“存在即合理”，我們很難說PASCAL是缺乏前瞻性而不夠普及的，VB地位持續下滑是缺乏前瞻性的表現？其實每項技術都是輝煌過，只不過隨著現代社會技術生產力的提高，出現了諸多更好的選擇罷了。意即過了巔峰之後，迎來的必然是低谷。
其實，我們可以簡單的認為，應用場景的多樣化，就是一項技術有高前瞻性的表現。
其次，不要簡單的認為當下的熱門技術就是有前瞻性的，尤其是近來湧現的各式新奇的技術。
Java能存在20年，還是有其道理的，至少前瞻性不遜色於其他技術。
3、團隊成員的擁護
這是關鍵點了，如果得不到團隊的認可，再怎麼牛X的技術，也無法落地執行，畢竟不是技術管理者一個人在幹活，得到大家的支援才最重要。
不過，這裡還是需要有一個制衡的：
不要因為團隊使用的技術老舊，就不敢啟用新技術；也不能急於啟用新技術，來一次大刀闊斧的技術改革，結果就是“步子邁大了，扯蛋了”。
所以，我認為技術管理者身上必須有一個特質：技術佈道。
很好理解，如果在一個因循守舊的管理者之下工作，很難有大的提高，甚至沒有任何進步。
在日新月異的IT技術圈子裡混的人，不可能沒有這一點基本的上進心。
充分激發團隊的技術熱情，感染團隊裡的每個成員，是技術管理者必備的人格魅力。
不過，本著實事求是的原則，一項技術適不適合團隊，只有用了才知道。但是技術管理者大可不必親力親為，尤其是CTO，總監級別的管理者，只需要指定技術目標，保持一定的技術熱情即可，最後再積極配合進行技術佈道。
4、從實際業務出發
技術圈裡流行一句話：不以業務為基礎的架構都是耍流氓。
這句話同樣適用於技術選型，必須從實際業務出發。
當然，因為某些技術的應用場景足夠豐富，所以，一般公司的技術選型的結果基本都是大同小異，也都能很好的滿足業務需求。
因為業務隨時都有可能產生變化的，這條準則並不是提供業務改變，技術也跟著變，而是在滿足現有業務的基礎上要有所“保留”。
舉個例子：
一個網站目前的QPS是1000，這對一箇中小型網站來說算是一個不錯的成績了。當時處於業務發展的考慮，在可預見的未來，QPS可能會到達10萬，那麼就按照這個標準進行技術選型，架構搭建。
如果這個時候用千萬級別的QPS來要求自己，那是不是在為難自己呢？這是在挑戰“雙十一”，這個想法很危險。
縱使將來真的達到了這個量級，那麼我相信整個技術也不是一蹴而就的，在這個過程中，不知道進行了多少次重構了。
5、給自己一些挑戰
這是“求新”方面的考慮，大有一種穩中求進的意味，我認為技術管理者應當要具備這樣的魄力。
舉個例子：
當Dubbo幾乎佔據了大大小小的各家網際網路公司的技術棧的時候，突然宣佈停更了，想來真是一件不負責任的做法。
就在停更期間，微服務大行其道了，正好我司要啟動一個新的產品研發專案，這個時候敢用Dubbo嗎？老實說，真不敢，雖然之前也沒認認真真用過它。
這個時候只能用Spring Cloud了，事實證明，Spring全家桶還更好用，各種元件的對接也比較友好，這就要歸功於Spring的技術生態做得比較出色。
當然，接觸一項新技術必定會踩坑無數，正所謂“逢山開路，遇水搭橋”，當前面四個條件都滿足的情況下，就不要怕困難了，路子走對了，只不過走得有些坎坷而已。