摘要：技術選型背后的思考筆者在工作經歷中曾多次遇到關于技術選型的問題，而每一次的技術選型都無一例外的糾結反復。機器資源評估技術選型上線后，必然會引入機器資源的開銷。維護團隊一個技術選型要長期穩定完全的在生產上服務，離不開背后的維護團隊。

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

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

1.1 滿足場景需求

這個點其實是老生常談了，做技術選型當然要首先考慮各個選型是否能夠滿足場景需求。但是這里面有幾個容易被大家忽略的點，值得一提：

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

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

1.2 完善的技術體系

當一個技術選型基本滿足了場景需求后，作為一個技術人員，還要思考很多場景之外的問題。比如：

如何監控、運維
一個優秀的技術選型會在設計階段就將運維和監控等考慮在內，方便技術使用者可以清晰的了解到系統的運行狀態，方便問題的排查。這些配套的工具是否完善對于一個技術人員來說是至關重要的。個人覺得Flink之所以如此風靡，除了它的技術層面的成就外，也離不開它原生完備的監控運維可視化工具。

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

1.3 機器資源評估

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

1.4 技術產品的穩定性

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

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

2.1 時間成本與人力成本

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

2.2 維護團隊

一個技術選型要長期、穩定、完全的在生產上服務，離不開背后的維護團隊。一個維護團隊小則可以對使用過程中遇到的疑難問題進行解答，大則可以臨危受命解決技術選型引入的線上故障。因此，在進行技術選型時，要考慮如下幾點：

是否有維護團隊，團隊是否穩定
在對比同是來源于公司內部的技術選型時，要調研技術選型背后的支持團隊是否仍然穩定存在。一個穩定的支持團隊至少說明了這個技術選型對公司十分重要，因此它出現的任何問題都會得到高度重視。

維護團隊的技術能力與合作意愿
由于不同公司各種組織架構劃分模式，導致并不是所有的維護團隊都是具有強烈的合作意愿的。一般情況下，成熟穩定技術的維護團隊在解決穩定性問題和技術答疑上積極性較高，而在支持新feature和使用教學上熱情有限；新推廣技術的維護團隊在支持各種新feature的工作上有很強的合作意愿。

維護團隊與自身團隊關系是否密切
維護團隊和自身團隊的利益綁定關系是否牢靠，leader之間是否同出一門，這等等因素都會影響日后尋求幫助時的便利性。此間細節，往往會在不經意間影響業務的穩定性和迭代效率。

2.3 新feature的開發模式

在業務迭代過程中經常會出現對技術上新的feature需求，此時若需要在選型上進行開發，則需要尋找到一種技術開發團隊的有效合作方式，常見合作方式有如下：

提需求
這種模式就是簡單的提需求，由維護團隊來開發，極大降低人力成本，但是可控性不強，如果和未還團隊之間沒有較強的利益綁定關系，很容易出現時間拖延的情況。同時，這種模式帶來的另外一個問題就是，自身團隊的成員對技術了解十分有限，難以獲得成長。

共建
這種方式多見于新推廣技術。業務團隊提供具體的業務場景，技術團隊進行技術抽象與打磨。在合作的同時，業務團隊的成員也有機會參與到技術開發中，提升技術儲備。這種方式是共贏的，但是對時機和人事環境的要求相對苛刻。

自主研發
可控性最強，團隊技術儲備增長最快。但需考慮是否存在重復建設，是否存在增量價值，能否孵化出有亮點的結果產出。

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

選型的核心在于取舍，取舍也是體現一個技術人員技術視野和綜合判斷力的關鍵決定。筆者結合自身的一些思考，提出了以下經驗性結論。

3.1 技術特性的取舍

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

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

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

上面提到的案例并不是鼓勵大家繞開問題，事實上，如果所有的人都繞開問題，就不會出現如今這么多優秀的技術選型。我們要做的是：把精力放到核心問題上。如果開發一個消息隊列是我們要解決的核心問題，那我們絕不能繞開它，而是要知難而上；但如果我們是要完成一次業務架構的選型，就不應該把過多的注意力放在細枝末節上。

3.2 技術管理的取舍

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

如果感興趣，歡迎關注微信技術公眾號