十多年研發(fā)、架構(gòu)經(jīng)驗(yàn)老司機(jī)的技術(shù)選型哲學(xué)

不談具體技術(shù)，從更高層面看，技術(shù)選型應(yīng)該怎么做?

寫在前面

技術(shù)選型是一個(gè)很熱門的話題，最近我看到自己的微信朋友圈有好幾篇關(guān)于技術(shù)選型的文章，讀者對(duì)這類主題的熱情很高。在技術(shù)組織內(nèi)部，技術(shù)人員經(jīng)常會(huì)面臨技術(shù)選型問題，有時(shí)候，技術(shù)選型還常常牽扯好幾波干系人，相互之間還會(huì)產(chǎn)生爭(zhēng)議，有的甚至還可能發(fā)展到派系斗爭(zhēng)的地步。即便像我自己，已經(jīng)有十幾年研發(fā)和架構(gòu)經(jīng)驗(yàn)的老司機(jī)，不管是工作還是業(yè)余，有很大部分時(shí)間的思考都是深陷在 A 技術(shù)和 B 技術(shù)的利弊權(quán)衡之中，不能自拔。無論如何，技術(shù)選型說小了關(guān)乎項(xiàng)目和團(tuán)隊(duì)成敗，說大了關(guān)乎企業(yè)業(yè)務(wù)的發(fā)展，不可小覷。

本文所表達(dá)的技術(shù)選型理念應(yīng)該是與具體技術(shù)無關(guān)的，但是由于我個(gè)人的背景更偏向互聯(lián)網(wǎng)后端的研發(fā)和架構(gòu)，所以本文的視角更偏向后端技術(shù)的選型。

軟件的本質(zhì)

復(fù)雜性近年，云計(jì)算、微服務(wù)、容器和 DevOps 等新技術(shù)和理念層出不窮，技術(shù)人員對(duì)各種新技術(shù)的追捧熱情也空前高漲，各種新技術(shù)微信討論群也如雨后春筍般冒了出來。這是一個(gè)好現(xiàn)象，說明我們的開發(fā)人員多了，技術(shù)環(huán)境也日趨成熟，有點(diǎn)百花齊放的感覺。同時(shí)也讓我有一點(diǎn)擔(dān)憂，我擔(dān)憂的是純技術(shù)和工具論的抬頭，也就是太過專注技術(shù)，認(rèn)為技術(shù)可以搞定一切，反而忽略了軟件研發(fā)的本質(zhì)復(fù)雜性。回想當(dāng)年，自己也曾是這樣的技術(shù)狂熱分子，EJB 剛出來的時(shí)候，我為 EJB 搖旗吶喊，Spring 出來的時(shí)候，我也曾一度是該技術(shù)的死忠，簡(jiǎn)單認(rèn)為這些技術(shù)是銀彈可以幫助解決所有的復(fù)雜性問題。

1986 年，人月神話的作者 Brooks 就提出，軟件的本質(zhì)復(fù)雜性(Essential Complexity)存在于復(fù)雜的業(yè)務(wù)領(lǐng)域中(用技術(shù)的話講是業(yè)務(wù)領(lǐng)域建模復(fù)雜性)，技術(shù)僅是輔助工具，它解決的問題是幫助將業(yè)務(wù)領(lǐng)域問題映射轉(zhuǎn)換成軟件實(shí)現(xiàn)，只解決次要復(fù)雜性(Accidental Complexity)。

作者同時(shí)指出，由于軟件本質(zhì)的復(fù)雜性，真正的銀彈并不存在;也斷言在十年內(nèi)，沒有任何一項(xiàng)技術(shù)或者方法可使軟件工程的生產(chǎn)力提高一個(gè)數(shù)量級(jí)。30 年前作者提出的論斷，今天依然閃爍智慧的光芒。人月神話已經(jīng)出了 40 周年紀(jì)念版了，堪稱軟件工程的圣經(jīng)，建議所有從事軟工行業(yè)的朋友學(xué)習(xí)。除了業(yè)務(wù)和技術(shù)，我還想強(qiáng)調(diào)軟件的本質(zhì)復(fù)雜性同時(shí)隱含在企業(yè)的人、組織、流程和管理中，不容忽視。

架構(gòu)師只有深刻理解軟件的本質(zhì)復(fù)雜性，才能站在解決實(shí)際業(yè)務(wù)問題的角度，更好的做出技術(shù)選型，否則易陷入唯技術(shù)工具論的陷阱。

使用成熟的技術(shù)

大部分公司都是商業(yè)組織，不是科研機(jī)構(gòu)或者純軟件研發(fā)機(jī)構(gòu)。商業(yè)組織使用技術(shù)是為了解決當(dāng)下的業(yè)務(wù)問題，他們更應(yīng)該使用成熟穩(wěn)定的技術(shù)。

如下圖，技術(shù)的使用有明顯的生命周期，早期有創(chuàng)新者和早期使用者采用，我把這個(gè)階段稱為試水趟坑期，也就是說這個(gè)階段技術(shù)不是很成熟穩(wěn)定的，雖然嘗新者可能占據(jù)一定的技術(shù)領(lǐng)先優(yōu)勢(shì)，但是他們常常需要以踩坑填坑作為代價(jià);如果這項(xiàng)技術(shù)經(jīng)過早期驗(yàn)證則會(huì)跨越鴻溝進(jìn)入早期大眾階段，這個(gè)階段技術(shù)會(huì)逐漸走向成熟，處于上升期，坑逐漸被填平，技術(shù)被大眾所采納;之后技術(shù)緩慢經(jīng)過末期大眾階段，最終走向滯后期，一直到生命周期的結(jié)束退出歷史舞臺(tái)。

技術(shù)選型的一大智慧是不要盲目追求新技術(shù)，老老實(shí)實(shí)采用成熟穩(wěn)定的技術(shù)，讓那些喜歡追新的人去踩坑😊，等這項(xiàng)技術(shù)跨越鴻溝，進(jìn)入早期大眾階段，你再擇機(jī)投入，這樣最保險(xiǎn)和高效。當(dāng)然作為技術(shù)人員，對(duì)新技術(shù)保持敏銳，提前預(yù)研是完全 OK 的，但是投入生產(chǎn)的話還是成熟穩(wěn)定第一。

少即是多

一項(xiàng)新技術(shù)既有學(xué)習(xí)成本，又有維護(hù)(定制、監(jiān)控、管理和運(yùn)維)成本，新技術(shù)引入很容易，學(xué)好用好運(yùn)維好卻很難。一個(gè)不嚴(yán)格把控技術(shù)棧數(shù)量的公司，開發(fā)人員常常會(huì)各自為政，隨意引入新技術(shù)，造成技術(shù)棧散亂，學(xué)習(xí)和維護(hù)成本高，技術(shù)棧知識(shí)無法共享，技術(shù)體系無法建立等問題，嚴(yán)重的會(huì)極大影響研發(fā)效率和業(yè)務(wù)規(guī)?；芰?。

以我本人專注的后端基礎(chǔ)框架領(lǐng)域?yàn)槔夹g(shù)棧散亂還會(huì)直接影響系統(tǒng)穩(wěn)定性，因?yàn)榧夹g(shù)組件和工具太多，無法統(tǒng)一埋點(diǎn)和建立完善的監(jiān)控體系。當(dāng)業(yè)務(wù)量發(fā)展到一定規(guī)模，技術(shù)棧散亂還會(huì)給系統(tǒng)擴(kuò)容跨機(jī)房遷移等帶來巨大障礙。

在一些成熟的互聯(lián)網(wǎng)公司，比如國內(nèi)的阿里，國外的 Netflix 和 eBay 等公司，這些公司雖然財(cái)力和資源豐富，但是他們的核心技術(shù)棧(比如主流開發(fā)語言，框架和數(shù)據(jù)存儲(chǔ)等)的數(shù)量同樣是受到嚴(yán)格把控的。

新技術(shù)引入的基本原則就是少即是多，能不引入新技術(shù)盡量不要引入新技術(shù)，確實(shí)需要引入的話，也要有相應(yīng)的新技術(shù)引入管理流程(一般由公司的技術(shù)或者架構(gòu)委員會(huì)制定和把控)。

技術(shù)的先決條件

技術(shù)引入常常是有一些先決條件的，比方說最近比較熱的微服務(wù)架構(gòu)，按照馬丁福勒的說法，微服務(wù)有如下先決條件：

快速的環(huán)境提供能力(Provisioning)能力(通常指 IAAS 層能力)，

基本的監(jiān)控能力

快速的發(fā)布能力

初步的 DevOps 文化

馬丁特別指出“你必須長(zhǎng)足夠高才能考慮微服務(wù)”，在這些先決條件沒有滿足之前，直接推行微服務(wù)會(huì)面臨巨大落地挑戰(zhàn)。

同樣，容器技術(shù)的引入對(duì)應(yīng)用也是有要求的(參考附錄 18.1 ~ 12 Factor App)，而 DevOps 研發(fā)模式的引入不僅對(duì)基礎(chǔ)技術(shù)和架構(gòu)，研發(fā)人員技能，甚至組織架構(gòu)和企業(yè)文化都是有很高要求的，在沒有滿足先決條件前，這些新技術(shù)或研發(fā)模式都會(huì)面臨巨大的落地挑戰(zhàn)。

作為管理者或者架構(gòu)師，在引入一項(xiàng)新技術(shù)之前，要充分調(diào)研了解新技術(shù)的先決條件，不能盲目引入。對(duì)于確實(shí)需要引入但是目前還不滿足先決條件的，需要做好階段性規(guī)劃，先打好基礎(chǔ)，再適時(shí)引入新技術(shù)。

來自大公司的技術(shù)

大公司采用的技術(shù)，未必適合中小公司。大公司有足夠的資源、人力和時(shí)間，可以投入一些前沿和重量級(jí)的技術(shù)(在 BAT 級(jí)別公司，為重量級(jí)技術(shù)投入幾十甚至百人以上的研發(fā)團(tuán)隊(duì)是很正常的事)，但是中小公司資源有限，不能盲目跟風(fēng)，應(yīng)該選擇和自己發(fā)展階段相適應(yīng)的技術(shù)，否則不僅不能幫助業(yè)務(wù)發(fā)展，反而會(huì)給業(yè)務(wù)發(fā)展帶來阻礙。

技術(shù)的文化特性

技術(shù)常常帶有文化特性的，在國外流行的技術(shù)，在國內(nèi)未必流行。一個(gè)例子是如 Scala 這樣的函數(shù)式語言，Scala 在國外互聯(lián)網(wǎng)公司是有一定流行度的(Twitter、Linkedln 等)，國內(nèi)雖然有不少簇?fù)碚撸鞘冀K只是小眾，無法流行，究其原因，國外很多大學(xué)教授的第一門編程語言是采用函數(shù)式語言的(例如美國 Berkeley 大學(xué)的 CS61A 是基于 Scheme 函數(shù)式語言)，國內(nèi)大學(xué)幾乎清一色采用 C/C++/Java 等命令式語言作為第一門編程語言。也就是說函數(shù)式語言在國外是有文化基礎(chǔ)的，所以容易流行，國內(nèi)沒有這樣的文化基礎(chǔ)，所以難以流行。

我們?cè)谶x型的時(shí)候，盡量采用在國內(nèi)有文化基礎(chǔ)，已經(jīng)落地開花的技術(shù)，盲目追求國外新技術(shù)有可能文化不適應(yīng)反而難于落地。

同樣的，在 A 公司流行的技術(shù)，在 B 公司也未必流行。比方說 BAT 三家公司所采用和后面演化出來的技術(shù)棧就明顯不同，這同樣和三家公司不同的業(yè)務(wù)領(lǐng)域和文化基因有關(guān)系。我們?cè)谧黾夹g(shù)選型的時(shí)候，也要考慮公司的文化特性，如業(yè)務(wù)模式、已有技術(shù)生態(tài)和開發(fā)人員技能等現(xiàn)實(shí)情況。

開源還是第三方軟件提供商的技術(shù)

互聯(lián)網(wǎng)時(shí)代，傳統(tǒng)的企業(yè)軟件供應(yīng)商開始明顯地走下坡路，企業(yè)越來越多的采用開源技術(shù)來開發(fā)他們的業(yè)務(wù)系統(tǒng)，開源軟件具有如下優(yōu)勢(shì)：

成本，商業(yè)軟件一般有昂貴的 license 費(fèi)用;

避免供應(yīng)商綁定 (vendor lockin);

靈活的定制能力，現(xiàn)代企業(yè)需要靈活的軟件定制能力以應(yīng)對(duì)快速變化的用戶需求，商業(yè)閉源軟件常常缺乏這種能力;

社區(qū)和生態(tài)，投資具有良好社區(qū)和生態(tài)的開源技術(shù)是企業(yè)技術(shù)選型的最佳實(shí)踐。

即使是開源軟件，這里面有一個(gè)很重要的閉環(huán)問題。有些開源軟件是一線互聯(lián)網(wǎng)公司成功落地后再開源出來的，比如阿里的 dubbo，點(diǎn)評(píng)的 CAT，這些公司本身有場(chǎng)景，內(nèi)部大量使用，也就是說內(nèi)部已經(jīng)形成反饋閉環(huán)，開源出來和社區(qū)又形成了一個(gè)更大的反饋閉環(huán)。有一些第三方軟件供應(yīng)商提供的開源軟件，其實(shí)他們本身是沒有業(yè)務(wù)場(chǎng)景的(或者場(chǎng)景非常有限)，主要靠社區(qū)使用后才能形成反饋閉環(huán)，對(duì)于這類開源軟件的使用需要謹(jǐn)慎，如果選擇的話，可能需要一起幫忙踩坑形成社區(qū)反饋閉環(huán)。

使用能掌控的技術(shù)

技術(shù)和武器一樣，并不是說越先進(jìn)越好。就像航空母艦和 F117 這樣的尖端武器，確實(shí)非常厲害，但是掌握和部署運(yùn)維這些武器的成本非常之高，如果你的團(tuán)隊(duì)沒有足夠的能力運(yùn)維和掌控這樣的武器，那么這些武器擺在家里充其量只能是擺設(shè)，不能形成戰(zhàn)斗力，有時(shí)甚至還會(huì)拖累業(yè)務(wù)。

在大數(shù)據(jù)領(lǐng)域重量級(jí)武器尤其多(Hadoop, HBase, Spark, Storm…)，很多產(chǎn)品既消耗機(jī)器資源，部署和運(yùn)維也非常復(fù)雜，如果某種重量級(jí)武器被應(yīng)用在關(guān)鍵業(yè)務(wù)上，一旦出問題，團(tuán)隊(duì)能不能 hold 住是要重點(diǎn)考慮的，否則可能會(huì)死得很難看。架構(gòu)師需要根據(jù)業(yè)務(wù)階段規(guī)模，團(tuán)隊(duì)規(guī)模和技能水平，綜合評(píng)估后再考慮引入，如果團(tuán)隊(duì)能力還不足以掌控某種重量級(jí)技術(shù)，則可以先從輕量級(jí)技術(shù)開始。

劍要交給懂得揮舞

它的人同一種技術(shù)，不同的人使用，可能會(huì)得出完全相反的結(jié)論。比如 Cassandra 這種 NoSql 分布式數(shù)據(jù)庫，在 Netflix 有比較成功的應(yīng)用，Netflix 從 2010 開始將系統(tǒng)遷移到 AWS 云中，并開始將大部分業(yè)務(wù)數(shù)據(jù)從傳統(tǒng) Oracle 數(shù)據(jù)庫遷移到 Cassandra 上，Netflix 的前架構(gòu)總監(jiān) Adrian Cockcroft 把他們技術(shù)升級(jí)的一大成功功勞歸結(jié)為采用了 Cassandra 這種天然支持跨數(shù)據(jù)中心的分布式數(shù)據(jù)庫。但是，在 2012 年時(shí)候，Digg 在網(wǎng)站改版升級(jí)過程中也試圖將傳統(tǒng) Mysql 數(shù)據(jù)庫遷移到 Cassandra Nosql 數(shù)據(jù)庫，結(jié)果導(dǎo)致 Digg 網(wǎng)站問題頻發(fā)，最后技術(shù)副總裁 John Quinn 主動(dòng)卷鋪蓋走人。事后，有人將問題歸結(jié)為 Cassandra，這就是著名的 Digg 使用 Cassandra 遭遇滑鐵盧事件。有人在 Quora 上發(fā)帖提問“Is Cassandra to blame for Digg v4’s technical failures?”[附錄 18.2]，回帖中有知情人士出來澄清：把 Digg 網(wǎng)站升級(jí)失敗歸結(jié)為 Cassandra 完全是轉(zhuǎn)移注意力(red herring)，背后的真正原因是工程管理和架構(gòu)的問題(poor engineering management and architecture)，簡(jiǎn)單講就是人的問題。

我曾經(jīng)在 2013 年左右在攜程框架部工作，當(dāng)時(shí)有一個(gè)很重要的框架產(chǎn)品叫分布式數(shù)據(jù)訪問層 DAL，很多團(tuán)隊(duì)都躍躍欲試要做，但是當(dāng)時(shí)的 CTO 一直沒有正式啟動(dòng)這個(gè)項(xiàng)目，理由是沒有合適的人。這個(gè)事情拖了有一年之久才找到合適的人，這個(gè)項(xiàng)目才啟動(dòng)并逐步落地，現(xiàn)在已經(jīng)是攜程框架的關(guān)鍵基礎(chǔ)設(shè)施，承載攜程大部分?jǐn)?shù)據(jù)庫訪問流量。

對(duì)于一些重量級(jí)的，處于業(yè)務(wù)關(guān)鍵鏈路上的產(chǎn)品，如果它重要但不緊急的話，一定要找到并交給能搞定它的人。把一個(gè)重要產(chǎn)品交給一個(gè)不合適的人，不僅不能解決問題，后續(xù)還常常會(huì)制造問題。設(shè)想一下業(yè)務(wù)的關(guān)鍵鏈路上的某個(gè)關(guān)鍵產(chǎn)品質(zhì)量不過關(guān)，問題頻發(fā)，但是業(yè)務(wù)已經(jīng)跑在上面無法簡(jiǎn)單替換，這是讓人很無奈的事情，很多架構(gòu)老司機(jī)對(duì)此場(chǎng)景應(yīng)該深有體會(huì)吧。

浪費(fèi)是創(chuàng)新的副產(chǎn)品

即使在同一個(gè)公司中，在主流技術(shù)棧的基礎(chǔ)上，不同團(tuán)隊(duì)適當(dāng)引入一些不同的技術(shù)棧，比如一個(gè)公司主流的技術(shù)棧是 Java，有些前端團(tuán)隊(duì)會(huì)嘗試用 Nodejs 開發(fā)應(yīng)用，有些大數(shù)據(jù)團(tuán)隊(duì)會(huì)采用 Python 開發(fā)應(yīng)用(Python 里頭有很多數(shù)據(jù)分析庫)。這些做法和第二點(diǎn)提出的少即是多并不矛盾，根據(jù)業(yè)務(wù)場(chǎng)景的需要，適當(dāng)引入一些互補(bǔ)的技術(shù)棧，適度冗余可以促進(jìn)團(tuán)隊(duì)創(chuàng)新。

再舉個(gè)例子，阿里在發(fā)展的過程中，曾經(jīng)發(fā)展出兩套技術(shù)體系，一套是淘寶體系，一套是 B2B 體系。有一段時(shí)間內(nèi)，兩套體系并行發(fā)展，團(tuán)隊(duì)之間既競(jìng)爭(zhēng)也相互借鑒，形成一個(gè)良性競(jìng)爭(zhēng)的技術(shù)生態(tài)。據(jù)說 Dubbo 最早就是 B2B 搞出來的，淘寶后面又搞了一套 HSF(未開源)，Dubbo 和 HSF 之間相互借鑒所以功能比較類似，阿里在 2014 年上市前對(duì)技術(shù)棧進(jìn)行了整合，集團(tuán)統(tǒng)一使用 HSF，Dubbo 則繼續(xù)活躍在開源社區(qū)，成為中國開源軟件的一個(gè)傳奇，它的成功一方面源自阿里技術(shù)的沉淀，另一方面也是 B2B 和淘寶相關(guān)團(tuán)隊(duì)思路碰撞融合的結(jié)果。

技術(shù)的宗教信仰很多技術(shù)人員對(duì)他們投入時(shí)間最多最熟悉的技術(shù)棧比較熱衷，有些甚至能上升到宗教信仰的程度，不同派系還會(huì)有相互鄙視的情況出現(xiàn)(據(jù)說 PHP 是最被鄙視的語言)，有的還會(huì)發(fā)展到派系爭(zhēng)斗的地步。之前我在一家互聯(lián)網(wǎng)公司，在容器 PaaS 平臺(tái)選型上出現(xiàn)了兩個(gè)派系，分別被戲稱為 K 黨和 M 黨，K 黨主張引入谷歌推的 Kubernetes，M 黨主張基于 Mesos 做定制，兩撥人都非常堅(jiān)持互不相讓，爭(zhēng)得不可開交。

其實(shí)我個(gè)人對(duì)技術(shù)的宗教信仰是非常排斥的，它是一種技術(shù)視野狹隘的表現(xiàn)，技術(shù)本身沒有絕對(duì)的好壞之分，只有適用場(chǎng)景和利弊之分。但是，技術(shù)的宗教信仰是一種客觀存在，有經(jīng)驗(yàn)的架構(gòu)師在做技術(shù)選型時(shí)需要考慮這一層面的因素。

通過背書做技術(shù)選型

和一線資深的架構(gòu)師或者技術(shù)專家交流，獲取技術(shù)選型的專家建議，是一種比較靠譜的技術(shù)選型策略。專家是一種背書，他們踩坑無數(shù)才成為專家，對(duì)很多技術(shù)有一手的實(shí)戰(zhàn)經(jīng)驗(yàn)，是真正 know how 的人，所以他們給出的建議一般都比較接地氣。

大公司是一個(gè)很好的背書，比方說 Google，當(dāng)初它推出 Kubernetes 的時(shí)候，其實(shí)我一開始看過架構(gòu)設(shè)計(jì)之后是對(duì)這個(gè)產(chǎn)品嗤之以鼻的。但是 Google 的強(qiáng)大背書和號(hào)召力擺在那里，用戶深信 Google 用腳投票，一開始架構(gòu)設(shè)計(jì)不好不是根本性問題，只要有足夠的用戶形成社區(qū)閉環(huán)，這個(gè)產(chǎn)品就會(huì)不斷長(zhǎng)好長(zhǎng)大。目前 K8S 已經(jīng)基本壟斷了容器 PaaS 平臺(tái)市場(chǎng)，它的成功很大程度歸結(jié)為 Google 公司的背書影響力。所以，綁著技術(shù)型大公司這個(gè)背書做技術(shù)選型，大概率不至于大錯(cuò)(當(dāng)然不是絕對(duì))。

Github 上的星的數(shù)量也是一個(gè)重要的技術(shù)選型參考，同時(shí)還有項(xiàng)目代碼和文檔更新頻度(尤其是近期)，這些指標(biāo)直接反應(yīng)開源項(xiàng)目的社區(qū)活躍度和生命力。

實(shí)踐出真知

實(shí)際評(píng)估一項(xiàng)技術(shù)時(shí)，最靠譜的做法還是詳細(xì)研究其文檔，做一些樣例和測(cè)試，對(duì)性能有要求的則必須實(shí)際做充分壓力測(cè)試獲得真實(shí)性能數(shù)據(jù)。對(duì)于開源的產(chǎn)品，如果處在業(yè)務(wù)的關(guān)鍵鏈路上，則建議把代碼拉下來通讀梳理一把，深入理解其內(nèi)部設(shè)計(jì)和架構(gòu)，有的還需要根據(jù)企業(yè)業(yè)務(wù)場(chǎng)景適當(dāng)做一些定制。

通過初步評(píng)估，仍需要尋找一定數(shù)量非關(guān)鍵試點(diǎn)項(xiàng)目(pilot project)做試水躺坑，經(jīng)過初步生產(chǎn)驗(yàn)證，才可以考慮逐步擴(kuò)大生產(chǎn)普及的規(guī)模。

實(shí)踐出真知，對(duì)于那些長(zhǎng)期在一線實(shí)戰(zhàn)和積累的架構(gòu)師，他們最終將獲得良好的技術(shù)選型的 sense 和對(duì)新技術(shù)的敏銳性。

技術(shù)的落地

簡(jiǎn)單回顧下我國遼寧號(hào)航母的歷史：1999 年中國購買了瓦良格號(hào)，于 2002 年 3 月拖回大連港，2005 年 4 月開始由中國海軍繼續(xù)建造改進(jìn)，2012 年 9 月正式更名遼寧號(hào)，交付中國人民解放軍海軍，2013 年 11 月，遼寧艦從青島遠(yuǎn)赴中國南海展開為期 47 天的海上綜合演練，標(biāo)志著遼寧號(hào)航母開始具備海上編隊(duì)?wèi)?zhàn)斗群能力。我國前前后后花費(fèi)超過 10 年才讓遼寧號(hào)航母初步形成戰(zhàn)力能力。

技術(shù)和武器一樣，你引入一個(gè)技術(shù)是一碼事，真正落地形成戰(zhàn)斗力或者說產(chǎn)生業(yè)務(wù)價(jià)值完全是另外一碼事。技術(shù)一般有落地周期：引入，定制改造，小規(guī)模試點(diǎn)，再到逐步擴(kuò)大生產(chǎn)規(guī)模，這個(gè)周期可長(zhǎng)可短，對(duì)于一些基礎(chǔ)性和重量級(jí)的技術(shù)，或者涉及大規(guī)模遺留系統(tǒng)升級(jí)改造的技術(shù)，一般周期比較漫長(zhǎng)(可能時(shí)間跨度長(zhǎng)達(dá) 1 年甚至幾年)，對(duì)于這類技術(shù)的引入和落地，架構(gòu)師需要高屋建瓴，通盤考慮，制定落地計(jì)劃，分階段推進(jìn)技術(shù)的落地。

定制、自研還是購買

這個(gè)問題比較復(fù)雜，很難一概而論，和企業(yè)的業(yè)務(wù)和團(tuán)隊(duì)規(guī)模，架構(gòu)甚至文化等諸多因素有關(guān)系。我個(gè)人遵循的兩個(gè)簡(jiǎn)單原則分別是：

如果不是你最擅長(zhǎng)，也提供不了差異化的競(jìng)爭(zhēng)優(yōu)勢(shì)的技術(shù)則直接用開源或者購買。小心 Not Invented Here 癥狀，避免重復(fù)造輪子，始終牢記達(dá)成業(yè)務(wù)目標(biāo)才是重點(diǎn)。

當(dāng)企業(yè)的業(yè)務(wù)和團(tuán)隊(duì)規(guī)模達(dá)到一定階段，對(duì)于處在業(yè)務(wù)關(guān)鍵鏈路上的核心技術(shù)，必須要有一定的定制甚至自研能力。創(chuàng)業(yè)公司盡量用開源或者購買云服務(wù)，驗(yàn)證業(yè)務(wù)模式是第一優(yōu)先;當(dāng)你的業(yè)務(wù)模式獲得驗(yàn)證，業(yè)務(wù)和團(tuán)隊(duì)達(dá)到一定規(guī)模，則需逐步考慮對(duì)核心業(yè)務(wù)鏈路上的技術(shù)進(jìn)行定制甚至自研;如果你成長(zhǎng)到接近 BAT 那個(gè)量級(jí)，那么大部分核心技術(shù)必然是定制甚至自研的，否則無法支撐那個(gè)規(guī)模。

寫在最后

本文僅限個(gè)人經(jīng)驗(yàn)視角，技術(shù)選型理念僅供參考借鑒。每個(gè)企業(yè)的具體上下文(業(yè)務(wù)場(chǎng)景，團(tuán)隊(duì)組織，技術(shù)架構(gòu)等)各不相同，每個(gè)架構(gòu)師的背景經(jīng)驗(yàn)也各不相同，大家要結(jié)合實(shí)際自己做出選型，沒有最好的技術(shù)，只有相對(duì)較合適的技術(shù)。另外，好的技術(shù)選型是相互借鑒甚至 PK 出來的，歡迎大家討論，給出自己的技術(shù)選型思考。