## 選型需要什么 **言歸正傳，我認為有三點不可或缺：分析、實驗和膽量。** ### 分析 分析主要有定性分析和定量分析。實際操作中，前者主要針對的是模型維度的估計，用來考慮一個組件是否有可能達到它宣稱的目的，后者主要用來驗證，用來確認它是否在真的做到了。 比如在語言選型時，你要考慮它的范型、內存模型和并發設計；數據庫選型時你要考慮存儲模型、支撐量級、成本開銷；開源項目要考慮它的社區發展、文檔完善程度；如果是庫或者中間件，還要考慮他的易用性、靈活性以及可替代性，等等。 需要說明的一點是，我個人并不覺得閱讀全部源碼或者文檔這種事情是必須的，這不局限在OS、VM層面。不僅因為這樣的事情會耗費過多精力，而且受制于代碼以及文檔質量，就算真正閱讀完畢也未必意味著完全領會。 這些都是定性的，而定性的東西就有可能存在理解偏差。一個庫可以完成工作，并不代表它在高并發壓力下依然表現正常；一個語言做到了自動管理內存，并不代表他能做得很好沒有副作用；一件事情設計者覺得達到了目標并不代表能夠滿足使用者期望。因此我們還需要量化分析，也就是一直口口相傳的，用數據說話。 量化分析需要你構建或使用現成的工具和數據集，對服務進行特定場景下的分析。通過提高壓力、增加容量或者針對性的測試，來驗證之前的定性分析是否達到預期，并分析不同技術之間的差異和表現。 ### 實驗 量化分析可以為真正的實驗做一些準備和幫助，但是實驗要走的明顯更遠。到了這一步，意味著要在真正的業務場景下進行驗證，這跟量化分析中通用性場景有所不同。 在真正的業務中采用需要很多細致和瑣碎的工作，除此之外，還要構建自己的測試工具集，這需要非常扎實的業務理解能力和勤奮的工作。而所有這些，你需要在開發環境做一次，在沙箱環境做一次，然后在仿真環境再做一次。 這幾步經常被簡化，但經驗告訴我們，如果你想做一個高可用的系統，你就不應該少走任何一步。 “步子大了，容易扯到蛋。” ### 膽量 實驗做完，剩下的就是上線，但這一步有很多人跨不過去。因為就算做了再多準備，你依然不敢說百分百保證沒問題。現實情況是，80%的線上問題都是升級或者上線引起的。 你需要膽量。 這不是說要硬著頭皮做，人家都是藝高才膽大。所以為了讓膽子大一點，你首先需要考慮降級和開關。從最悲觀的角度來重新審視整個方案，如果升級出現問題怎么辦，如何才能讓出現的問題影響最小化。 而只要弄完了這些，也就只要再記住一句話就行： “你行你上啊！”