摘要：技術(shù)選型背后的思考筆者在工作經(jīng)歷中曾多次遇到關(guān)于技術(shù)選型的問題，而每一次的技術(shù)選型都無一例外的糾結(jié)反復(fù)。機(jī)器資源評(píng)估技術(shù)選型上線后，必然會(huì)引入機(jī)器資源的開銷。維護(hù)團(tuán)隊(duì)一個(gè)技術(shù)選型要長(zhǎng)期穩(wěn)定完全的在生產(chǎn)上服務(wù)，離不開背后的維護(hù)團(tuán)隊(duì)。

筆者在工作經(jīng)歷中曾多次遇到關(guān)于技術(shù)選型的問題，而每一次的技術(shù)選型都無一例外的糾結(jié)、反復(fù)。經(jīng)常出現(xiàn)的現(xiàn)象是，在項(xiàng)目推進(jìn)的過程中多次反復(fù)修改技術(shù)選型，客觀上造成了效率的降低，而當(dāng)最終選定某一個(gè)選型時(shí)，又覺得這個(gè)結(jié)果似乎是顯而易見的。為了避免反復(fù)糾結(jié)造成效率降低，筆者覺得有必要總結(jié)下選型中常見的思考方式，方便以后參考。
每一次技術(shù)選型都是在特定的需求場(chǎng)景下，結(jié)合各種各樣的主觀、客觀因素，最初一個(gè)最優(yōu)的選擇。很多人覺得技術(shù)選型時(shí)只要選定的技術(shù)產(chǎn)品滿足業(yè)務(wù)需求就可以了，但筆者經(jīng)過多次觀察發(fā)現(xiàn)，滿足場(chǎng)景需求只是一個(gè)前提條件，真正令人糾結(jié)的點(diǎn)往往在需求本身之外。
下面按照三個(gè)部分梳理了選型中要思考的幾個(gè)方向：技術(shù)特性、技術(shù)管理和取舍之道。

了解各個(gè)技術(shù)選型的技術(shù)特性是一次選型的開始，也是必須做好的一部分工作。筆者經(jīng)驗(yàn)性的發(fā)現(xiàn)，往往選型過程中的反復(fù)、糾結(jié)，都是由于一開始并沒有真正體系化的將每一個(gè)選型理解透徹。還是延續(xù)上面的說法：了解一個(gè)技術(shù)是否能夠滿足場(chǎng)景需求只是一個(gè)前提條件，除此以外還要了解的還有很多。下面筆者將結(jié)合個(gè)人經(jīng)驗(yàn)，一一說明。

1.1 滿足場(chǎng)景需求

這個(gè)點(diǎn)其實(shí)是老生常談了，做技術(shù)選型當(dāng)然要首先考慮各個(gè)選型是否能夠滿足場(chǎng)景需求。但是這里面有幾個(gè)容易被大家忽略的點(diǎn)，值得一提：

了解能否滿足需求，更要了解是如何滿足需求的
對(duì)于一些相對(duì)簡(jiǎn)單的需求，可能會(huì)有很多技術(shù)選型都可以滿足。但是實(shí)現(xiàn)方式細(xì)節(jié)上的差異，會(huì)導(dǎo)致后期場(chǎng)景迭代過程中引入天翻地覆的變化。據(jù)一個(gè)比較蠢的例子，某團(tuán)隊(duì)需要一個(gè)消息隊(duì)列，那么到底用kafka還是RocketMQ呢？消息隊(duì)列是一個(gè)非常簡(jiǎn)單的需求，但是不同使用場(chǎng)景的迭代過程中的對(duì)消息隊(duì)列的追加需求會(huì)越來越多。能否持久化、是否支持EXACTLY-ONCE模式、能否按時(shí)間戳復(fù)現(xiàn)消息、讀多還是寫多、是否支持事務(wù)等等，這些都會(huì)影響選型上的傾向性。

很多時(shí)候，所有技術(shù)選型都能滿足“最低需求”，但是沒有一個(gè)技術(shù)選型能“完美的滿足需求”
需求不明確的初期，往往會(huì)發(fā)現(xiàn)：世界這么小，卻能找到這么多滿足的要求的技術(shù)。但需求逐漸細(xì)化后，又會(huì)發(fā)現(xiàn)：天下這么大，竟沒有一個(gè)技術(shù)選型能完美滿足所有需求。遇到這種問題，其實(shí)思路就兩種：一種是“忍”，體現(xiàn)在湊合用或者繞開不完美的部分上；一種是“干”，那就是想辦法進(jìn)行開發(fā)。

1.2 完善的技術(shù)體系

當(dāng)一個(gè)技術(shù)選型基本滿足了場(chǎng)景需求后，作為一個(gè)技術(shù)人員，還要思考很多場(chǎng)景之外的問題。比如：

如何監(jiān)控、運(yùn)維
一個(gè)優(yōu)秀的技術(shù)選型會(huì)在設(shè)計(jì)階段就將運(yùn)維和監(jiān)控等考慮在內(nèi)，方便技術(shù)使用者可以清晰的了解到系統(tǒng)的運(yùn)行狀態(tài)，方便問題的排查。這些配套的工具是否完善對(duì)于一個(gè)技術(shù)人員來說是至關(guān)重要的。個(gè)人覺得Flink之所以如此風(fēng)靡，除了它的技術(shù)層面的成就外，也離不開它原生完備的監(jiān)控運(yùn)維可視化工具。

周邊技術(shù)體系
一個(gè)大型的技術(shù)選型往往綁定了很多其他的小的技術(shù)選型，比如Flink綁定了RocksDB，很多google的開源技術(shù)都綁定了protobuf等。除了關(guān)注技術(shù)選型主體外，還要注意分析下主體以外綁定的其他選型是否能夠很好的融入已有的技術(shù)體系。

1.3 機(jī)器資源評(píng)估

技術(shù)選型上線后，必然會(huì)引入機(jī)器資源的開銷。不同的選型在性能上的表現(xiàn)可能千差萬別。如：rt、cpu、內(nèi)存占用、網(wǎng)絡(luò)IO、磁盤IO、存儲(chǔ)開銷。這里重點(diǎn)要提到的是，上述指標(biāo)不能單一的看某一項(xiàng)指標(biāo)，而是要整體評(píng)估所有指標(biāo)。
舉例說明：
假設(shè)要對(duì)兩個(gè)數(shù)據(jù)存儲(chǔ)技術(shù)進(jìn)行選型。線上一臺(tái)機(jī)器有4T磁盤、500G內(nèi)存、96核CPU、2GB/s網(wǎng)絡(luò)帶寬。技術(shù)選型A 磁盤占用1T，內(nèi)存占用200G，滿負(fù)載運(yùn)行時(shí)CPU 40%，網(wǎng)絡(luò)IO 1GB/s。技術(shù)選型B 磁盤占用0.5T，內(nèi)存占用100G，滿負(fù)載運(yùn)行時(shí)CPU 20%，網(wǎng)絡(luò)IO 2GB/s。
單從存儲(chǔ)開銷、內(nèi)存占用、CPU上來看，B選型完勝。但是由于選型網(wǎng)絡(luò)IO做的不好，導(dǎo)致IO成為瓶頸。如果考慮到docker混布的話，一臺(tái)機(jī)器可以布署兩個(gè)A實(shí)例，但是卻只能布署一個(gè)B實(shí)例。由于網(wǎng)絡(luò)IO的瓶頸效應(yīng)，導(dǎo)致選型B的節(jié)省的存儲(chǔ)開銷無法體現(xiàn)在節(jié)省機(jī)器資源上。

1.4 技術(shù)產(chǎn)品的穩(wěn)定性

要不要做第一個(gè)吃螃蟹的人？這是一個(gè)問題。
一千個(gè)讀者眼中有一千個(gè)哈姆雷特，但是一千個(gè)開發(fā)工程師在上面這個(gè)問題上卻只能給出兩種答案：要或不要。新興技術(shù)總是吸引人眼球，并勾引著技術(shù)人員的好奇心，讓后者有一種先睹而后快的沖動(dòng)；但是內(nèi)心理性的小人又在反復(fù)揣摩，為了滿足一時(shí)的好奇心搞出個(gè)故障被扣工資甚至跑路，把孩子的奶粉錢都搞沒了到底值不值得。一個(gè)技術(shù)選型是否有長(zhǎng)時(shí)間穩(wěn)定運(yùn)行的先例，這一點(diǎn)對(duì)于選型者至關(guān)重要，但是如果所有人都因這么想而不愿意嘗試新技術(shù)，那又何來的長(zhǎng)時(shí)間穩(wěn)定運(yùn)行的先例呢？
個(gè)人冒昧分析，抉擇的關(guān)鍵在于業(yè)務(wù)場(chǎng)景是新興業(yè)務(wù)或是長(zhǎng)期穩(wěn)定業(yè)務(wù)、選型失敗的后果是否嚴(yán)重、新技術(shù)提供的增量?jī)r(jià)值是否能打動(dòng)使用者等因素，這里因業(yè)務(wù)而已，不做結(jié)論性說明。

在工作中完成一次技術(shù)選型，絕不能簡(jiǎn)單的僅僅從純技術(shù)角度出發(fā)思考。一次看似偶然的選型會(huì)給后續(xù)工作帶來方向性的影響，這里的影響指的不光是技術(shù)層面，更多的是管理層面。這就如同在公司一次公開的項(xiàng)目招標(biāo)中，考慮絕不僅僅是解決方案本身的優(yōu)劣，更重要的考量方案的成本是否符合預(yù)期，方案提供方的實(shí)力、誠(chéng)信度，甚至還要從商業(yè)模式上去思考未來的合作方式是什么，等等。而這一切，都能在一次技術(shù)選型的過程中，得以體現(xiàn)。
下面就從幾個(gè)主要闡述下選型中遇到的常見問題。

2.1 時(shí)間成本與人力成本

再?zèng)Q定技術(shù)選型時(shí)，除了機(jī)器資源等成本以外，一定不要忘記了，作為一個(gè)團(tuán)隊(duì)投入的還有時(shí)間成本和人力成本。在一些爭(zhēng)分奪秒的項(xiàng)目中，哪種選型能夠達(dá)到快速遷移的目的，幾乎就可以確定哪種選型會(huì)勝出。如果不得不使用一個(gè)復(fù)雜的技術(shù)，而時(shí)間有十分緊迫，那么唯一的方式就是通過加大人力投入來實(shí)現(xiàn)。
是什么決定投入成本的規(guī)模呢？是收益。不僅僅是完成一個(gè)項(xiàng)目的短期收益，更要衡量用該技術(shù)手段帶來的長(zhǎng)遠(yuǎn)收益。因此會(huì)有一個(gè)有趣的現(xiàn)象，有時(shí)通過技術(shù)選型就能看出一個(gè)業(yè)務(wù)線的盈利能力。

2.2 維護(hù)團(tuán)隊(duì)

一個(gè)技術(shù)選型要長(zhǎng)期、穩(wěn)定、完全的在生產(chǎn)上服務(wù)，離不開背后的維護(hù)團(tuán)隊(duì)。一個(gè)維護(hù)團(tuán)隊(duì)小則可以對(duì)使用過程中遇到的疑難問題進(jìn)行解答，大則可以臨危受命解決技術(shù)選型引入的線上故障。因此，在進(jìn)行技術(shù)選型時(shí)，要考慮如下幾點(diǎn)：

是否有維護(hù)團(tuán)隊(duì)，團(tuán)隊(duì)是否穩(wěn)定
在對(duì)比同是來源于公司內(nèi)部的技術(shù)選型時(shí)，要調(diào)研技術(shù)選型背后的支持團(tuán)隊(duì)是否仍然穩(wěn)定存在。一個(gè)穩(wěn)定的支持團(tuán)隊(duì)至少說明了這個(gè)技術(shù)選型對(duì)公司十分重要，因此它出現(xiàn)的任何問題都會(huì)得到高度重視。

維護(hù)團(tuán)隊(duì)的技術(shù)能力與合作意愿
由于不同公司各種組織架構(gòu)劃分模式，導(dǎo)致并不是所有的維護(hù)團(tuán)隊(duì)都是具有強(qiáng)烈的合作意愿的。一般情況下，成熟穩(wěn)定技術(shù)的維護(hù)團(tuán)隊(duì)在解決穩(wěn)定性問題和技術(shù)答疑上積極性較高，而在支持新feature和使用教學(xué)上熱情有限；新推廣技術(shù)的維護(hù)團(tuán)隊(duì)在支持各種新feature的工作上有很強(qiáng)的合作意愿。

維護(hù)團(tuán)隊(duì)與自身團(tuán)隊(duì)關(guān)系是否密切
維護(hù)團(tuán)隊(duì)和自身團(tuán)隊(duì)的利益綁定關(guān)系是否牢靠，leader之間是否同出一門，這等等因素都會(huì)影響日后尋求幫助時(shí)的便利性。此間細(xì)節(jié)，往往會(huì)在不經(jīng)意間影響業(yè)務(wù)的穩(wěn)定性和迭代效率。

2.3 新feature的開發(fā)模式

在業(yè)務(wù)迭代過程中經(jīng)常會(huì)出現(xiàn)對(duì)技術(shù)上新的feature需求，此時(shí)若需要在選型上進(jìn)行開發(fā)，則需要尋找到一種技術(shù)開發(fā)團(tuán)隊(duì)的有效合作方式，常見合作方式有如下：

提需求
這種模式就是簡(jiǎn)單的提需求，由維護(hù)團(tuán)隊(duì)來開發(fā)，極大降低人力成本，但是可控性不強(qiáng)，如果和未還團(tuán)隊(duì)之間沒有較強(qiáng)的利益綁定關(guān)系，很容易出現(xiàn)時(shí)間拖延的情況。同時(shí)，這種模式帶來的另外一個(gè)問題就是，自身團(tuán)隊(duì)的成員對(duì)技術(shù)了解十分有限，難以獲得成長(zhǎng)。

共建
這種方式多見于新推廣技術(shù)。業(yè)務(wù)團(tuán)隊(duì)提供具體的業(yè)務(wù)場(chǎng)景，技術(shù)團(tuán)隊(duì)進(jìn)行技術(shù)抽象與打磨。在合作的同時(shí)，業(yè)務(wù)團(tuán)隊(duì)的成員也有機(jī)會(huì)參與到技術(shù)開發(fā)中，提升技術(shù)儲(chǔ)備。這種方式是共贏的，但是對(duì)時(shí)機(jī)和人事環(huán)境的要求相對(duì)苛刻。

自主研發(fā)
可控性最強(qiáng)，團(tuán)隊(duì)技術(shù)儲(chǔ)備增長(zhǎng)最快。但需考慮是否存在重復(fù)建設(shè)，是否存在增量?jī)r(jià)值，能否孵化出有亮點(diǎn)的結(jié)果產(chǎn)出。

在筆者實(shí)際工作經(jīng)歷中曾遇到過如下一次選型。
選型一：基本滿足業(yè)務(wù)需求，技術(shù)成熟，很多業(yè)務(wù)線都在用，但是技術(shù)內(nèi)部對(duì)外是一個(gè)黑盒，而且是一個(gè)與本團(tuán)隊(duì)關(guān)系疏遠(yuǎn)的團(tuán)隊(duì)在維護(hù)
選型二：需要一定的開發(fā)才能滿足業(yè)務(wù)需求，技術(shù)相對(duì)成熟，維護(hù)團(tuán)隊(duì)與本團(tuán)隊(duì)是兄弟團(tuán)隊(duì)
選型三：完全滿足業(yè)務(wù)需求，是一個(gè)新型技術(shù)，團(tuán)隊(duì)有能力自主研發(fā)，但周邊設(shè)施并不是十分完善，與選型一存在大量的重復(fù)建設(shè)
在選型過程中經(jīng)歷了各種糾結(jié)，最終由于不能重復(fù)建設(shè)而放棄了選型三，由于兄弟團(tuán)隊(duì)無法支持定制開發(fā)而放棄了選型二，歸根結(jié)底還是選擇了選型一。

選型的核心在于取舍，取舍也是體現(xiàn)一個(gè)技術(shù)人員技術(shù)視野和綜合判斷力的關(guān)鍵決定。筆者結(jié)合自身的一些思考，提出了以下經(jīng)驗(yàn)性結(jié)論。

3.1 技術(shù)特性的取舍

如1.1節(jié)中提到的，很多時(shí)候會(huì)出現(xiàn)沒有任何一個(gè)技術(shù)選型“完美滿足”業(yè)務(wù)需求。此時(shí)除了進(jìn)行定制開發(fā)一種思路外，還可以選擇繞開問題，曲線超車。這里的“繞開”并不是逃避，而是集中把精力放在解決關(guān)鍵問題上，而對(duì)于不那么關(guān)鍵的瑕疵，可以有多種方式解決。
舉個(gè)例子，加入現(xiàn)在有一個(gè)集群A，它進(jìn)行計(jì)算后會(huì)將結(jié)果發(fā)往下游集群B，集群B收到計(jì)算結(jié)果后會(huì)將結(jié)果寫入數(shù)據(jù)庫。我們要在集群A到集群B的通信方式上進(jìn)行一次選型。直觀上，我們需要一個(gè)消息隊(duì)列來連接集群A和集群B，集群A是生產(chǎn)者，集群B是消費(fèi)者，并且需要考慮如何保證集群B的各個(gè)機(jī)器之間讀到的消息不能重復(fù)。但是，如果我們手邊并沒有合適的消息隊(duì)列選型，我們?cè)撛趺醋瞿?？有兩種方法可以推進(jìn)解決這個(gè)問題：

繼續(xù)尋找/定制開發(fā)
我們可以繼續(xù)尋找合適的消息隊(duì)列選型，或者選擇自己開發(fā)一套合適的消息隊(duì)列。這樣時(shí)間成本上和人力成本上必須加大投入。

繞開問題
消息隊(duì)列提供的能力不光是通信，還有持久化、保證順序、EXCECTLY-ONCE等能力。但是假如我們業(yè)務(wù)場(chǎng)景并不需要這些附加能力，而是僅僅需要“通信”這一個(gè)功能，那么其實(shí)我們完全可以使用“rpc單向調(diào)用”來完成通信。集群A發(fā)送rpc請(qǐng)求，集群B收到請(qǐng)求后立刻返回一個(gè)空結(jié)果（反正集群A也不關(guān)心返回內(nèi)容），然后進(jìn)行些數(shù)據(jù)庫操作。

上面提到的案例并不是鼓勵(lì)大家繞開問題，事實(shí)上，如果所有的人都繞開問題，就不會(huì)出現(xiàn)如今這么多優(yōu)秀的技術(shù)選型。我們要做的是：把精力放到核心問題上。如果開發(fā)一個(gè)消息隊(duì)列是我們要解決的核心問題，那我們絕不能繞開它，而是要知難而上；但如果我們是要完成一次業(yè)務(wù)架構(gòu)的選型，就不應(yīng)該把過多的注意力放在細(xì)枝末節(jié)上。

3.2 技術(shù)管理的取舍

由于筆者并沒有實(shí)際參與過管理崗位的工作，在這里只能從一個(gè)被管理者的視角給出一些觀點(diǎn)。在工作中，解決歷史遺留問題（俗稱填坑），是最沒有成就感的工作，而且“日后填坑”的成本遠(yuǎn)高于“當(dāng)時(shí)填坑”。日積月累，只能通過“爆破”（整體重構(gòu)）這種巨額成本的工作來解決歷史遺留問題。看上去破舊不堪的系統(tǒng)仍然繼續(xù)在線上運(yùn)轉(zhuǎn)，每天耗費(fèi)大量人力用于維護(hù)系統(tǒng)正常，這些都是多次選型不慎引入的長(zhǎng)久隱患。因此，筆者認(rèn)為，在技術(shù)選型時(shí)，維護(hù)團(tuán)隊(duì)的穩(wěn)定性、技術(shù)產(chǎn)品的穩(wěn)定性等因素的重要性要遠(yuǎn)大于較低的遷移成本的重要性。

如果感興趣，歡迎關(guān)注微信技術(shù)公眾號(hào)