不談具體技術，從更高層面看，技術選型應該怎么做?
寫在前面
技術選型是一個很熱門的話題，最近我看到自己的微信朋友圈有好幾篇關于技術選型的文章，讀者對這類主題的熱情很高。在技術組織內(nèi)部，技術人員經(jīng)常會面臨技術選型問題，有時候，技術選型還常常牽扯好幾波干系人，相互之間還會產(chǎn)生爭議，有的甚至還可能發(fā)展到派系斗爭的地步。即便像我自己，已經(jīng)有十幾年研發(fā)和架構經(jīng)驗的老司機，不管是工作還是業(yè)余，有很大部分時間的思考都是深陷在 A 技術和 B 技術的利弊權衡之中，不能自拔。無論如何，技術選型說小了關乎項目和團隊成敗，說大了關乎企業(yè)業(yè)務的發(fā)展，不可小覷。
本文所表達的技術選型理念應該是與具體技術無關的，但是由于我個人的背景更偏向互聯(lián)網(wǎng)后端的研發(fā)和架構，所以本文的視角更偏向后端技術的選型。
軟件的本質(zhì)
復雜性近年，云計算、微服務、容器和 DevOps 等新技術和理念層出不窮，技術人員對各種新技術的追捧熱情也空前高漲，各種新技術微信討論群也如雨后春筍般冒了出來。這是一個好現(xiàn)象，說明我們的開發(fā)人員多了，技術環(huán)境也日趨成熟，有點百花齊放的感覺。同時也讓我有一點擔憂，我擔憂的是純技術和工具論的抬頭，也就是太過專注技術，認為技術可以搞定一切，反而忽略了軟件研發(fā)的本質(zhì)復雜性?；叵氘斈辏约阂苍沁@樣的技術狂熱分子，EJB 剛出來的時候，我為 EJB 搖旗吶喊，Spring 出來的時候，我也曾一度是該技術的死忠，簡單認為這些技術是銀彈可以幫助解決所有的復雜性問題。
1986 年，人月神話的作者 Brooks 就提出，軟件的本質(zhì)復雜性(Essential Complexity)存在于復雜的業(yè)務領域中(用技術的話講是業(yè)務領域建模復雜性)，技術僅是輔助工具，它解決的問題是幫助將業(yè)務領域問題映射轉(zhuǎn)換成軟件實現(xiàn)，只解決次要復雜性(Accidental Complexity)。
作者同時指出，由于軟件本質(zhì)的復雜性，真正的銀彈并不存在;也斷言在十年內(nèi)，沒有任何一項技術或者方法可使軟件工程的生產(chǎn)力提高一個數(shù)量級。30 年前作者提出的論斷，今天依然閃爍智慧的光芒。人月神話已經(jīng)出了 40 周年紀念版了，堪稱軟件工程的圣經(jīng)，建議所有從事軟工行業(yè)的朋友學習。除了業(yè)務和技術，我還想強調(diào)軟件的本質(zhì)復雜性同時隱含在企業(yè)的人、組織、流程和管理中，不容忽視。
架構師只有深刻理解軟件的本質(zhì)復雜性，才能站在解決實際業(yè)務問題的角度，更好的做出技術選型，否則易陷入唯技術工具論的陷阱。
使用成熟的技術
大部分公司都是商業(yè)組織，不是科研機構或者純軟件研發(fā)機構。商業(yè)組織使用技術是為了解決當下的業(yè)務問題，他們更應該使用成熟穩(wěn)定的技術。
如下圖，技術的使用有明顯的生命周期，早期有創(chuàng)新者和早期使用者采用，我把這個階段稱為試水趟坑期，也就是說這個階段技術不是很成熟穩(wěn)定的，雖然嘗新者可能占據(jù)一定的技術領先優(yōu)勢，但是他們常常需要以踩坑填坑作為代價;如果這項技術經(jīng)過早期驗證則會跨越鴻溝進入早期大眾階段，這個階段技術會逐漸走向成熟，處于上升期，坑逐漸被填平，技術被大眾所采納;之后技術緩慢經(jīng)過末期大眾階段，最終走向滯后期，一直到生命周期的結束退出歷史舞臺。
技術選型的一大智慧是不要盲目追求新技術，老老實實采用成熟穩(wěn)定的技術，讓那些喜歡追新的人去踩坑😊，等這項技術跨越鴻溝，進入早期大眾階段，你再擇機投入，這樣最保險和高效。當然作為技術人員，對新技術保持敏銳，提前預研是完全 OK 的，但是投入生產(chǎn)的話還是成熟穩(wěn)定第一。
少即是多
一項新技術既有學習成本，又有維護(定制、監(jiān)控、管理和運維)成本，新技術引入很容易，學好用好運維好卻很難。一個不嚴格把控技術棧數(shù)量的公司，開發(fā)人員常常會各自為政，隨意引入新技術，造成技術棧散亂，學習和維護成本高，技術棧知識無法共享，技術體系無法建立等問題，嚴重的會極大影響研發(fā)效率和業(yè)務規(guī)?；芰Α?/p>
以我本人專注的后端基礎框架領域為例，技術棧散亂還會直接影響系統(tǒng)穩(wěn)定性，因為技術組件和工具太多，無法統(tǒng)一埋點和建立完善的監(jiān)控體系。當業(yè)務量發(fā)展到一定規(guī)模，技術棧散亂還會給系統(tǒng)擴容跨機房遷移等帶來巨大障礙。
在一些成熟的互聯(lián)網(wǎng)公司，比如國內(nèi)的阿里，國外的 Netflix 和 eBay 等公司，這些公司雖然財力和資源豐富，但是他們的核心技術棧(比如主流開發(fā)語言，框架和數(shù)據(jù)存儲等)的數(shù)量同樣是受到嚴格把控的。
新技術引入的基本原則就是少即是多，能不引入新技術盡量不要引入新技術，確實需要引入的話，也要有相應的新技術引入管理流程(一般由公司的技術或者架構委員會制定和把控)。
技術的先決條件
技術引入常常是有一些先決條件的，比方說最近比較熱的微服務架構，按照馬丁福勒的說法，微服務有如下先決條件：
快速的環(huán)境提供能力(Provisioning)能力(通常指 IAAS 層能力)，
基本的監(jiān)控能力
快速的發(fā)布能力
初步的 DevOps 文化
馬丁特別指出“你必須長足夠高才能考慮微服務”，在這些先決條件沒有滿足之前，直接推行微服務會面臨巨大落地挑戰(zhàn)。
同樣，容器技術的引入對應用也是有要求的(參考附錄 18.1 ~ 12 Factor App)，而 DevOps 研發(fā)模式的引入不僅對基礎技術和架構，研發(fā)人員技能，甚至組織架構和企業(yè)文化都是有很高要求的，在沒有滿足先決條件前，這些新技術或研發(fā)模式都會面臨巨大的落地挑戰(zhàn)。
作為管理者或者架構師，在引入一項新技術之前，要充分調(diào)研了解新技術的先決條件，不能盲目引入。對于確實需要引入但是目前還不滿足先決條件的，需要做好階段性規(guī)劃，先打好基礎，再適時引入新技術。
來自大公司的技術
大公司采用的技術，未必適合中小公司。大公司有足夠的資源、人力和時間，可以投入一些前沿和重量級的技術(在 BAT 級別公司，為重量級技術投入幾十甚至百人以上的研發(fā)團隊是很正常的事)，但是中小公司資源有限，不能盲目跟風，應該選擇和自己發(fā)展階段相適應的技術，否則不僅不能幫助業(yè)務發(fā)展，反而會給業(yè)務發(fā)展帶來阻礙。
技術的文化特性
技術常常帶有文化特性的，在國外流行的技術，在國內(nèi)未必流行。一個例子是如 Scala 這樣的函數(shù)式語言，Scala 在國外互聯(lián)網(wǎng)公司是有一定流行度的(Twitter、Linkedln 等)，國內(nèi)雖然有不少簇擁者，但是始終只是小眾，無法流行，究其原因，國外很多大學教授的第一門編程語言是采用函數(shù)式語言的(例如美國 Berkeley 大學的 CS61A 是基于 Scheme 函數(shù)式語言)，國內(nèi)大學幾乎清一色采用 C/C++/Java 等命令式語言作為第一門編程語言。也就是說函數(shù)式語言在國外是有文化基礎的，所以容易流行，國內(nèi)沒有這樣的文化基礎，所以難以流行。
我們在選型的時候，盡量采用在國內(nèi)有文化基礎，已經(jīng)落地開花的技術，盲目追求國外新技術有可能文化不適應反而難于落地。
同樣的，在 A 公司流行的技術，在 B 公司也未必流行。比方說 BAT 三家公司所采用和后面演化出來的技術棧就明顯不同，這同樣和三家公司不同的業(yè)務領域和文化基因有關系。我們在做技術選型的時候，也要考慮公司的文化特性，如業(yè)務模式、已有技術生態(tài)和開發(fā)人員技能等現(xiàn)實情況。
開源還是第三方軟件提供商的技術
互聯(lián)網(wǎng)時代，傳統(tǒng)的企業(yè)軟件供應商開始明顯地走下坡路，企業(yè)越來越多的采用開源技術來開發(fā)他們的業(yè)務系統(tǒng)，開源軟件具有如下優(yōu)勢：
成本，商業(yè)軟件一般有昂貴的 license 費用;
避免供應商綁定 (vendor lockin);
靈活的定制能力，現(xiàn)代企業(yè)需要靈活的軟件定制能力以應對快速變化的用戶需求，商業(yè)閉源軟件常常缺乏這種能力;
社區(qū)和生態(tài)，投資具有良好社區(qū)和生態(tài)的開源技術是企業(yè)技術選型的最佳實踐。
即使是開源軟件，這里面有一個很重要的閉環(huán)問題。有些開源軟件是一線互聯(lián)網(wǎng)公司成功落地后再開源出來的，比如阿里的 dubbo，點評的 CAT，這些公司本身有場景，內(nèi)部大量使用，也就是說內(nèi)部已經(jīng)形成反饋閉環(huán)，開源出來和社區(qū)又形成了一個更大的反饋閉環(huán)。有一些第三方軟件供應商提供的開源軟件，其實他們本身是沒有業(yè)務場景的(或者場景非常有限)，主要靠社區(qū)使用后才能形成反饋閉環(huán)，對于這類開源軟件的使用需要謹慎，如果選擇的話，可能需要一起幫忙踩坑形成社區(qū)反饋閉環(huán)。
使用能掌控的技術
技術和武器一樣，并不是說越先進越好。就像航空母艦和 F117 這樣的尖端武器，確實非常厲害，但是掌握和部署運維這些武器的成本非常之高，如果你的團隊沒有足夠的能力運維和掌控這樣的武器，那么這些武器擺在家里充其量只能是擺設，不能形成戰(zhàn)斗力，有時甚至還會拖累業(yè)務。
在大數(shù)據(jù)領域重量級武器尤其多(Hadoop, HBase, Spark, Storm…)，很多產(chǎn)品既消耗機器資源，部署和運維也非常復雜，如果某種重量級武器被應用在關鍵業(yè)務上，一旦出問題，團隊能不能 hold 住是要重點考慮的，否則可能會死得很難看。架構師需要根據(jù)業(yè)務階段規(guī)模，團隊規(guī)模和技能水平，綜合評估后再考慮引入，如果團隊能力還不足以掌控某種重量級技術，則可以先從輕量級技術開始。
劍要交給懂得揮舞
它的人同一種技術，不同的人使用，可能會得出完全相反的結論。比如 Cassandra 這種 NoSql 分布式數(shù)據(jù)庫，在 Netflix 有比較成功的應用，Netflix 從 2010 開始將系統(tǒng)遷移到 AWS 云中，并開始將大部分業(yè)務數(shù)據(jù)從傳統(tǒng) Oracle 數(shù)據(jù)庫遷移到 Cassandra 上，Netflix 的前架構總監(jiān) Adrian Cockcroft 把他們技術升級的一大成功功勞歸結為采用了 Cassandra 這種天然支持跨數(shù)據(jù)中心的分布式數(shù)據(jù)庫。但是，在 2012 年時候，Digg 在網(wǎng)站改版升級過程中也試圖將傳統(tǒng) Mysql 數(shù)據(jù)庫遷移到 Cassandra Nosql 數(shù)據(jù)庫，結果導致 Digg 網(wǎng)站問題頻發(fā)，最后技術副總裁 John Quinn 主動卷鋪蓋走人。事后，有人將問題歸結為 Cassandra，這就是著名的 Digg 使用 Cassandra 遭遇滑鐵盧事件。有人在 Quora 上發(fā)帖提問“Is Cassandra to blame for Digg v4’s technical failures?”[附錄 18.2]，回帖中有知情人士出來澄清：把 Digg 網(wǎng)站升級失敗歸結為 Cassandra 完全是轉(zhuǎn)移注意力(red herring)，背后的真正原因是工程管理和架構的問題(poor engineering management and architecture)，簡單講就是人的問題。
我曾經(jīng)在 2013 年左右在攜程框架部工作，當時有一個很重要的框架產(chǎn)品叫分布式數(shù)據(jù)訪問層 DAL，很多團隊都躍躍欲試要做，但是當時的 CTO 一直沒有正式啟動這個項目，理由是沒有合適的人。這個事情拖了有一年之久才找到合適的人，這個項目才啟動并逐步落地，現(xiàn)在已經(jīng)是攜程框架的關鍵基礎設施，承載攜程大部分數(shù)據(jù)庫訪問流量。
對于一些重量級的，處于業(yè)務關鍵鏈路上的產(chǎn)品，如果它重要但不緊急的話，一定要找到并交給能搞定它的人。把一個重要產(chǎn)品交給一個不合適的人，不僅不能解決問題，后續(xù)還常常會制造問題。設想一下業(yè)務的關鍵鏈路上的某個關鍵產(chǎn)品質(zhì)量不過關，問題頻發(fā)，但是業(yè)務已經(jīng)跑在上面無法簡單替換，這是讓人很無奈的事情，很多架構老司機對此場景應該深有體會吧。
浪費是創(chuàng)新的副產(chǎn)品
即使在同一個公司中，在主流技術棧的基礎上，不同團隊適當引入一些不同的技術棧，比如一個公司主流的技術棧是 Java，有些前端團隊會嘗試用 Nodejs 開發(fā)應用，有些大數(shù)據(jù)團隊會采用 Python 開發(fā)應用(Python 里頭有很多數(shù)據(jù)分析庫)。這些做法和第二點提出的少即是多并不矛盾，根據(jù)業(yè)務場景的需要，適當引入一些互補的技術棧，適度冗余可以促進團隊創(chuàng)新。
再舉個例子，阿里在發(fā)展的過程中，曾經(jīng)發(fā)展出兩套技術體系，一套是淘寶體系，一套是 B2B 體系。有一段時間內(nèi)，兩套體系并行發(fā)展，團隊之間既競爭也相互借鑒，形成一個良性競爭的技術生態(tài)。據(jù)說 Dubbo 最早就是 B2B 搞出來的，淘寶后面又搞了一套 HSF(未開源)，Dubbo 和 HSF 之間相互借鑒所以功能比較類似，阿里在 2014 年上市前對技術棧進行了整合，集團統(tǒng)一使用 HSF，Dubbo 則繼續(xù)活躍在開源社區(qū)，成為中國開源軟件的一個傳奇，它的成功一方面源自阿里技術的沉淀，另一方面也是 B2B 和淘寶相關團隊思路碰撞融合的結果。
技術的宗教信仰很多技術人員對他們投入時間最多最熟悉的技術棧比較熱衷，有些甚至能上升到宗教信仰的程度，不同派系還會有相互鄙視的情況出現(xiàn)(據(jù)說 PHP 是最被鄙視的語言)，有的還會發(fā)展到派系爭斗的地步。之前我在一家互聯(lián)網(wǎng)公司，在容器 PaaS 平臺選型上出現(xiàn)了兩個派系，分別被戲稱為 K 黨和 M 黨，K 黨主張引入谷歌推的 Kubernetes，M 黨主張基于 Mesos 做定制，兩撥人都非常堅持互不相讓，爭得不可開交。
其實我個人對技術的宗教信仰是非常排斥的，它是一種技術視野狹隘的表現(xiàn)，技術本身沒有絕對的好壞之分，只有適用場景和利弊之分。但是，技術的宗教信仰是一種客觀存在，有經(jīng)驗的架構師在做技術選型時需要考慮這一層面的因素。
通過背書做技術選型
和一線資深的架構師或者技術專家交流，獲取技術選型的專家建議，是一種比較靠譜的技術選型策略。專家是一種背書，他們踩坑無數(shù)才成為專家，對很多技術有一手的實戰(zhàn)經(jīng)驗，是真正 know how 的人，所以他們給出的建議一般都比較接地氣。
大公司是一個很好的背書，比方說 Google，當初它推出 Kubernetes 的時候，其實我一開始看過架構設計之后是對這個產(chǎn)品嗤之以鼻的。但是 Google 的強大背書和號召力擺在那里，用戶深信 Google 用腳投票，一開始架構設計不好不是根本性問題，只要有足夠的用戶形成社區(qū)閉環(huán)，這個產(chǎn)品就會不斷長好長大。目前 K8S 已經(jīng)基本壟斷了容器 PaaS 平臺市場，它的成功很大程度歸結為 Google 公司的背書影響力。所以，綁著技術型大公司這個背書做技術選型，大概率不至于大錯(當然不是絕對)。
Github 上的星的數(shù)量也是一個重要的技術選型參考，同時還有項目代碼和文檔更新頻度(尤其是近期)，這些指標直接反應開源項目的社區(qū)活躍度和生命力。
實踐出真知
實際評估一項技術時，最靠譜的做法還是詳細研究其文檔，做一些樣例和測試，對性能有要求的則必須實際做充分壓力測試獲得真實性能數(shù)據(jù)。對于開源的產(chǎn)品，如果處在業(yè)務的關鍵鏈路上，則建議把代碼拉下來通讀梳理一把，深入理解其內(nèi)部設計和架構，有的還需要根據(jù)企業(yè)業(yè)務場景適當做一些定制。
通過初步評估，仍需要尋找一定數(shù)量非關鍵試點項目(pilot project)做試水躺坑，經(jīng)過初步生產(chǎn)驗證，才可以考慮逐步擴大生產(chǎn)普及的規(guī)模。
實踐出真知，對于那些長期在一線實戰(zhàn)和積累的架構師，他們最終將獲得良好的技術選型的 sense 和對新技術的敏銳性。
技術的落地
簡單回顧下我國遼寧號航母的歷史：1999 年中國購買了瓦良格號，于 2002 年 3 月拖回大連港，2005 年 4 月開始由中國海軍繼續(xù)建造改進，2012 年 9 月正式更名遼寧號，交付中國人民解放軍海軍，2013 年 11 月，遼寧艦從青島遠赴中國南海展開為期 47 天的海上綜合演練，標志著遼寧號航母開始具備海上編隊戰(zhàn)斗群能力。我國前前后后花費超過 10 年才讓遼寧號航母初步形成戰(zhàn)力能力。
技術和武器一樣，你引入一個技術是一碼事，真正落地形成戰(zhàn)斗力或者說產(chǎn)生業(yè)務價值完全是另外一碼事。技術一般有落地周期：引入，定制改造，小規(guī)模試點，再到逐步擴大生產(chǎn)規(guī)模，這個周期可長可短，對于一些基礎性和重量級的技術，或者涉及大規(guī)模遺留系統(tǒng)升級改造的技術，一般周期比較漫長(可能時間跨度長達 1 年甚至幾年)，對于這類技術的引入和落地，架構師需要高屋建瓴，通盤考慮，制定落地計劃，分階段推進技術的落地。
定制、自研還是購買
這個問題比較復雜，很難一概而論，和企業(yè)的業(yè)務和團隊規(guī)模，架構甚至文化等諸多因素有關系。我個人遵循的兩個簡單原則分別是：
如果不是你最擅長，也提供不了差異化的競爭優(yōu)勢的技術則直接用開源或者購買。小心 Not Invented Here 癥狀，避免重復造輪子，始終牢記達成業(yè)務目標才是重點。
當企業(yè)的業(yè)務和團隊規(guī)模達到一定階段，對于處在業(yè)務關鍵鏈路上的核心技術，必須要有一定的定制甚至自研能力。創(chuàng)業(yè)公司盡量用開源或者購買云服務，驗證業(yè)務模式是第一優(yōu)先;當你的業(yè)務模式獲得驗證，業(yè)務和團隊達到一定規(guī)模，則需逐步考慮對核心業(yè)務鏈路上的技術進行定制甚至自研;如果你成長到接近 BAT 那個量級，那么大部分核心技術必然是定制甚至自研的，否則無法支撐那個規(guī)模。
寫在最后
本文僅限個人經(jīng)驗視角，技術選型理念僅供參考借鑒。每個企業(yè)的具體上下文(業(yè)務場景，團隊組織，技術架構等)各不相同，每個架構師的背景經(jīng)驗也各不相同，大家要結合實際自己做出選型，沒有最好的技術，只有相對較合適的技術。另外，好的技術選型是相互借鑒甚至 PK 出來的，歡迎大家討論，給出自己的技術選型思考。
下載文檔
