技術選型背後的思考

技術選型背後的思考

筆者在工做經歷中曾屢次遇到關於技術選型的問題，而每一次的技術選型都無一例外的糾結、反覆。常常出現的現象是，在項目推動的過程當中屢次反覆修改技術選型，客觀上形成了效率的下降，而當最終選定某一個選型時，又以爲這個結果彷佛是顯而易見的。爲了不反覆糾結形成效率下降，筆者以爲有必要總結下選型中常見的思考方式，方便之後參考。
每一次技術選型都是在特定的需求場景下，結合各類各樣的主觀、客觀因素，最初一個最優的選擇。不少人以爲技術選型時只要選定的技術產品知足業務需求就能夠了，但筆者通過屢次觀察發現，知足場景需求只是一個前提條件，真正使人糾結的點每每在需求自己以外。
下面按照三個部分梳理了選型中要思考的幾個方向：技術特性、技術管理和取捨之道。

1 技術特性

瞭解各個技術選型的技術特性是一次選型的開始，也是必須作好的一部分工做。筆者經驗性的發現，每每選型過程當中的反覆、糾結，都是因爲一開始並無真正體系化的將每個選型理解透徹。仍是延續上面的說法：瞭解一個技術是否可以知足場景需求只是一個前提條件，除此之外還要了解的還有不少。下面筆者將結合我的經驗，一一說明。

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 管理模式

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

2.1 時間成本與人力成本

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

2.2 維護團隊

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

• 是否有維護團隊，團隊是否穩定
  在對比同是來源於公司內部的技術選型時，要調研技術選型背後的支持團隊是否仍然穩定存在。一個穩定的支持團隊至少說明了這個技術選型對公司十分重要，所以它出現的任何問題都會獲得高度重視。
• 維護團隊的技術能力與合做意願
  因爲不一樣公司各類組織架構劃分模式，致使並非全部的維護團隊都是具備強烈的合做意願的。通常狀況下，成熟穩定技術的維護團隊在解決穩定性問題和技術答疑上積極性較高，而在支持新feature和使用教學上熱情有限；新推廣技術的維護團隊在支持各類新feature的工做上有很強的合做意願。
• 維護團隊與自身團隊關係是否密切
  維護團隊和自身團隊的利益綁定關係是否牢靠，leader之間是否同出一門，這等等因素都會影響往後尋求幫助時的便利性。此間細節，每每會在不經意間影響業務的穩定性和迭代效率。

2.3 新feature的開發模式

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

• 提需求
  這種模式就是簡單的提需求，由維護團隊來開發，極大下降人力成本，可是可控性不強，若是和未還團隊之間沒有較強的利益綁定關係，很容易出現時間拖延的狀況。同時，這種模式帶來的另一個問題就是，自身團隊的成員對技術瞭解十分有限，難以得到成長。
• 共建
  這種方式多見於新推廣技術。業務團隊提供具體的業務場景，技術團隊進行技術抽象與打磨。在合做的同時，業務團隊的成員也有機會參與到技術開發中，提高技術儲備。這種方式是雙贏的，可是對時機和人事環境的要求相對苛刻。
• 自主研發
  可控性最強，團隊技術儲備增加最快。但需考慮是否存在重複建設，是否存在增量價值，可否孵化出有亮點的結果產出。

在筆者實際工做經歷中曾遇到過以下一次選型。
選型一：基本知足業務需求，技術成熟，不少業務線都在用，可是技術內部對外是一個黑盒，並且是一個與本團隊關係疏遠的團隊在維護
選型二：須要必定的開發才能知足業務需求，技術相對成熟，維護團隊與本團隊是兄弟團隊
選型三：徹底知足業務需求，是一個新型技術，團隊有能力自主研發，但周邊設施並非十分完善，與選型一存在大量的重複建設
在選型過程當中經歷了各類糾結，最終因爲不能重複建設而放棄了選型三，因爲兄弟團隊沒法支持定製開發而放棄了選型二，歸根結底仍是選擇了選型一。

3 取捨之道

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

3.1 技術特性的取捨

如1.1節中提到的，不少時候會出現沒有任何一個技術選型「完美知足」業務需求。此時除了進行定製開發一種思路外，還能夠選擇繞開問題，曲線超車。這裏的「繞開」並非逃避，而是集中把精力放在解決關鍵問題上，而對於不那麼關鍵的瑕疵，能夠有多種方式解決。
舉個例子，加入如今有一個集羣A，它進行計算後會將結果發往下游集羣B，集羣B收到計算結果後會將結果寫入數據庫。咱們要在集羣A到集羣B的通訊方式上進行一次選型。直觀上，咱們須要一個消息隊列來鏈接集羣A和集羣B，集羣A是生產者，集羣B是消費者，而且須要考慮如何保證集羣B的各個機器之間讀到的消息不能重複。可是，若是咱們手邊並無合適的消息隊列選型，咱們該怎麼作呢？有兩種方法能夠推動解決這個問題：

• 繼續尋找/定製開發
  咱們能夠繼續尋找合適的消息隊列選型，或者選擇本身開發一套合適的消息隊列。這樣時間成本上和人力成本上必須加大投入。
• 繞開問題
  消息隊列提供的能力不光是通訊，還有持久化、保證順序、EXCECTLY-ONCE等能力。可是假如咱們業務場景並不須要這些附加能力，而是僅僅須要「通訊」這一個功能，那麼其實咱們徹底可使用「rpc單向調用」來完成通訊。集羣A發送rpc請求，集羣B收到請求後馬上返回一個空結果（反正集羣A也不關心返回內容），而後進行些數據庫操做。

上面提到的案例並非鼓勵你們繞開問題，事實上，若是全部的人都繞開問題，就不會出現現在這麼多優秀的技術選型。咱們要作的是：把精力放到核心問題上。若是開發一個消息隊列是咱們要解決的核心問題，那咱們毫不能繞開它，而是要知難而上；但若是咱們是要完成一次業務架構的選型，就不該該把過多的注意力放在細枝末節上。

3.2 技術管理的取捨

因爲筆者並無實際參與過管理崗位的工做，在這裏只能從一個被管理者的視角給出一些觀點。在工做中，解決歷史遺留問題（俗稱填坑），是最沒有成就感的工做，並且「往後填坑」的成本遠高於「當時填坑」。日積月累，只能經過「爆破」（總體重構）這種鉅額成本的工做來解決歷史遺留問題。看上去破舊不堪的系統仍然繼續在線上運轉，天天耗費大量人力用於維護系統正常，這些都是屢次選型不慎引入的長久隱患。所以，筆者認爲，在技術選型時，維護團隊的穩定性、技術產品的穩定性等因素的重要性要遠大於較低的遷移成本的重要性。

若是感興趣，歡迎關注微信技術公衆號