怎麼去體現技術方案設計的深度是大家普遍關心的一個問題，這個問題不是個例問題，因此本文主要分享下作者個人的一些觀點和看法。

文章主要分為三個部分：

第一部分主要分析為什麼技術方案沒有體現出深度，找到問題後就好解決，並提出技術方案的廣度和深度特徵。

第二部分是技術方案設計的方法論，主要包括了本質論、矛盾論、系統論、演進論四個方法論，構成一個閉環反饋鏈路。

第三部分是透過具體的案例，反覆運用第二部分的方法論闡述在例項的案例中如何去應用，加深對方法論的理解。

技術方案體現廣度和深度1. 方案設計常見的反饋

我們都希望自己設計的技術方案能夠讓人眼前一亮、歎為觀止、拍案叫絕……，然而在實際情況下，卻並不是這樣的，我們經常聽到如下的說法：

場景簡單：業務場景很簡單，怎麼也設計不出花兒來。複雜度低：業務複雜度低，很難講得出挑戰來。亮點少：運用的技術亮點少，基本上都是現有的中介軟體或框架來完成。設計普通：方案缺乏新穎，業內也是這麼做的，沒有體現出自己的設計能力。……

的確，上面反而是經常遇到的場景，那麼需要思考下背後的問題和原因，為什麼會有這樣的感受，如果這個事情交給另外一個人去做，為什麼他能設計出更好的方法，而當時你卻沒有想到呢？

2. 原因探究

個人覺得這個問題最為核心的一點是就事論事，因為只是看到這個事，需要完成某個具體的功能點，而沒有跳去這個事情的表象，去思考到底要什麼、解決了什麼問題、價值是什麼，這樣思考很有可能你現在的解決方案只是其中一個很小的點，沒有站在全域性去思考問題。曾經我的老師講過一個觀點：把手掌放在眼前，你只能看到這個手掌，如果把手掌放在遠處，你的視野就更廣了。因此視野更關鍵，不要只關注事情的本身，可以跳出來看看，或者你能想到的更多。

就事論事只是一個表象，背後還是深層次的原因，個人覺得是缺乏體系化的思考，"只見樹木、不見森林"，沒有從不同的維度上去思考問題，只是線性的思考，直接的表現就是【就事論事】，只把手頭上的事情完成即可。講體系化思考的書籍很多，大家有興趣可以去了解下，幫助自己更好地思考問題。

到這裡其實還沒有結束，還有一個重要的原因是缺乏方法論引導，就是沒有形成自己的一套方法去思考問題、解決問題，不同的人會有自己的方法，有了方法論的引導，拿到一個問題，知道怎麼去分析、思考、解決，遠比只是被動地接受一種具體的方案要好，下次場景變了，很有可能現有的方案是不能支撐的，因此需要建立一套適合自己的方法論，具體在第二部分會分享自己的方法論。

3. 技術廣度和深度

廣度和深度對於我們來講並不陌生，大家都知道要體現出廣度和深度，卻不知道怎麼去做。廣度覺得從數量和型別兩個維度去分析（應該還有其它的維度，大家可以自行補充），是讓事物更加地豐富，比如動物園裡有不同的動物，種類比較多，就能更加滿足不同人的觀賞需求；深度主要體現出問題的識別和創新解決上，一個問題大家沒有發現，而你從中發現了，這就是深度，比如網上購物，站在今天來看，再平常不過了，但在 20 年前，並不是每個人能想到的。現如今，同樣是做電商，每個公司的打法、策略是不一樣的，這就體現在深度上，深耕於某一個領域。

這裡拿自己的經歷來說明：之前本人在滴滴是做優惠券業務（當時營銷比較簡單，就是單一券業務），優惠券只是一種營銷的具體手段，行業內有卡、券、分、金，那麼對於技術來講就是豐富營銷基礎能力，從單一券能力發展至卡、券、分、金的營銷行業標配能力，這個就體現了廣度，從數量、型別上豐富了。而怎麼體現深度呢？營銷中有一個重要問題是如何防控資損，一旦有資損，問題就比較大，因此需要去好好思考和設計方案，當時借鑑穩定性方案，分成事前、事中、事後三個階段去防控資損，每一個階段裡又包含了不同的方案，深度主要體現對問題的識別，以及怎樣創新地去解決，重點是創新，做到人無我有、人有我優。

4. 怎樣證明技術方案是好的

大家在和別人分享、交流技術方案時，有人會提出一些尖銳的問題，比如：為什麼說你的技術方案是好的？其實這個問題非常好，值得大家去思考。

有一個很常見的情況，大家去講一個技術方案時，把背景、目標講完之後，直接給出了技術方案，其實技術方案本身並不重要，重要的是你是怎麼思考的，思考的過程非常重要，強調的是 WHY，HOW 很重要，但 WHY 更重要。這裡有兩個原則：

三段論：大提前、小提前、結論。一定要先講大提前，它是一個有力的支撐，比如寫議論文時，平時常寫"魯迅說過 xxxxx"，這個就是大提前；在技術方案設計上，就是要看業內的方案、業界的標杆在哪裡，和它有什麼不一樣、創新了什麼，一目瞭然，往往大家忽略了這個大提前，直接講自己的方案，怎麼證明你的就是好的呢？沒有對比就沒有感覺。環境論：有時業內還沒有具體的方案，或者是當下你的公司不適合業內頂配的方案，比如"中國特色社會主義"，它就是強調當前的環境，結合了具體的業務場景來權衡考慮的，並不是行業內的最優方案就是適合你的，方案的設計一定要有權衡、選擇，設計出最適合當前環境的方案。技術方案設計的方法論1. 方法論到底是什麼

經常有人講方法論，方法論也讓人感覺比較玄乎，感覺是一種虛無縹緲的東西，方法論在百科中的解釋是：“方法論是關於人們認識世界、改造世界的方法的理論”，看了這個定義，大家還是不清楚它到底是什麼，只知道它挺厲害的，但不知道方法論到底是什麼、有哪些方法論、應該如何去運用方法論，所以這裡談下自己的理解。

個人對方法論的理解是方法論是讓方法變成更方法的方法，方法論拆分成兩個詞方法和論。因此它首先是一種方法，方法是為了解決具體的問題，比如大家熟知的穩定性建設，全鏈路壓測、異常監控等都是具體的方法，但這些方法都是一個個散的點，並不是最好的方法，方法論強調的是好的方法；然後再看"論"，論是議論、分析、思考的過程，它最大的好處是讓方法更好，還是拿穩定性建設來講，現在有成熟的方法論，分成事前、事中、事後三個階段，事前包括容量評估、全鏈路壓測、強弱依賴……，這樣講就比較成體系，將它劃分成事前、事中、事後，覆蓋了整個過程，你基本上挑不出什麼毛病出來。因此方法論是對解決方法進一步的昇華和提煉，形成更通用、成體系的方法，它並不是虛無縹緲的東西。

方法論是透過不完全歸納法總結出來的，方法論並不是萬能的，比如你看到的天鵝都是白色的，萬一哪天出現了一隻黑天鵝，就說明當時的歸納是不完全歸納的。

2. 技術方案設計方法論

下面所說的方法論都是存在的，自己只是組合運用了這些方法論而已，下面總結下自己工作中使用的一些受益比較大的方法論。

本質論是我第一個受益的方法論，本質論強調的是透過現象看本質，這句話聽起來是比較簡單的，但要做到卻是非常難的。看透本質至關重要，能讓你真正把控事物的核心，我個人的一個方法是使用不超過 15 個字概括出事物的本質，因為本質的東西是簡單的、美的、直揭主旨的，所以判斷是否抓住了事物本質的一個標準就是用簡單的話能否概括出事物的主旨。比如高併發，現在不再是一個新鮮的詞彙，甚至大學生都知道怎麼去做，快取、非同步操作、並行……，這些都是具體的措施，問高併發到底是什麼，大家都能回答一些，比如流量大、系統壓力大、使用者多……，這些都是具體的特徵，用一句話概括高併發：有限的資源應對大量的請求，概括出了高併發的根本特性，抓住了本質的東西就比較解決問題。帶應屆生的時候，我提到一個觀點：工作三年以後，要能說得出 10 句對技術本質理解的話，提早給自己定下目標，在平時中積累一些思考和沉澱。

矛盾論揭示的是事物之間的矛盾，矛盾是推動事物不斷髮展的動力，一般從事物本質中，可以看到一些矛盾出來，比如上面高併發的本質是有限的資源應對大量的請求，有限對大量本身就是一對矛盾，找到了矛盾就去解決矛盾，解決的一個方向就是平衡矛盾，矛盾解決了，問題自然就解決了，比如現在資源是大量的，完全可以應對大量的請求，這樣高併發的場景對於你來講就不是一個問題。

系統論是從系統各個要素出發，多維度思考問題，最為簡單的是從矛盾雙方出發思考問題，比如有限的資源，能不能讓資源的數量變多呢？能不能提升資源的處理能力呢？……，從這些方向去思考，思路就一下子打開了，所謂的快取等常說的方法只是一個個具體的解決手段，我們需要更加立體、多維的解決思路，再結合具體的場景、現狀組合一些解決方法。

演進論強調事物是進化的，符合事物的發展規律和人的認識，有可能我們想得非常完善，不可能等所有的事情都做好了再上線，得有計劃、分階段地解決問題，優先解決主要矛盾、核心訴求。也有可能經過一段時間之後，事物的主要矛盾發生了變化，我們的方案也得演進式設計。

技術方案設計案例

下面拿三個具體的案例來講怎麼將方法論落地於實際的技術方案設計，讓大家能夠感覺到方法論的真正作用，不再是一種虛的感覺。

1. 高併發技術方案

高併發在之前是非常火的，大家也都能說出一些解決措施，如使用快取、MQ、並行……，下面談下自己的一些思路。

問題定義：高併發的本質是有限的資源應對大量的請求，它的核心問題就是現狀不足已支撐那麼大量的請求，系統的負載太高，很可能出現網站打不開、使用者下不了單等現象。

問題分析：高併發的矛盾就是有限的資源對大量的請求，解決了這個矛盾就解決了高併發的問題。接下來就是平衡這對矛盾，一般是採用"中和"的思想，就像中醫治病：寒病用熱藥、熱病用寒藥，因此就會站在資源和請求兩個維度去思考。資源能不能變多：常見的有水平擴充套件；資源能不能變強：常見的是效能最佳化，效能最佳化又會分成前端最佳化、網路最佳化、計算最佳化、儲存最佳化、程式最佳化……。請求能不能減少呢？比如透過答題錯峰，合併請求等等，這樣解決問題的思路就一下打開了。

解決方案是重要的，但設計的過程更為重要，清楚了問題是什麼、怎麼去分析，解決方案自然而然就出來了，重要的還是分析的過程。

2. 非同步處理技術方案

說到非同步處理，大家最容易想到的方案就是 MQ。MQ 是常見解決的技術方案，如下圖所示：貸款端系統向放款端系統傳送標的資訊，一天的量大約有 4000 多筆，每天偶爾有幾個是超時的，影響放款。怎麼去解決這個問題呢？用 MQ 是最容易想到的，當時公司還不有用到 MQ 中介軟體，去搭建一個不現實，怎麼辦呢。

問題定義：現有的系統能力無法支撐實時處理，同步呼叫對系統的壓力很大，很有可能某個時間點系統的負載比較大，處理慢了介面呼叫就超時了。

問題分析：借鑑 MQ 的設計原理，傳送方將訊息先發送至 Broker 上，消費方從 Broker 上拉取訊息消費，抽象出非同步處理的本質就是資料暫存 + 擇機處理，那麼問題來了，資料暫存在哪裡呢，記憶體？檔案？資料庫？……，擇機處理的方式是拉還是推，定時還是隨機……，這樣一思考，發現除了 MQ 還有很多其它的解決方法，總結出通用的解決方案後，可以在不同具體的環境中演繹出不同的方案。當時設計的方案就是將資料儲存到 ftp 伺服器上，實現也比較簡單，方案沒有最好，只有適不適合，難道公司沒有 MQ 中介軟體，這個事情就不能解決了嗎？

3. 可擴充套件性技術方案

可擴充套件性設計是現在一個非常典型的場景，當時遇到的場景是實時人群計算場景，每當業務方提一個需求過來，就要進行對資料口徑，然後熟悉業務方的一些業務，接下來就是編寫 Flink 任務，測試、核對，最後上線，整個流程下來至少 2 周，需求提一個簡單需求，很疑惑為什麼要 2 周才能上線。

問題定義：業務方希望快速上線而實際開發要 2 周的矛盾，究其主要原因是不懂業務，需要有熟悉的階段，這個階段耗時比較多，真正開發的時間不多，怎麼去解決這個問題呢？

問題分析：雖然主要的矛盾找到了，很明顯的一個方向是讓業務方的開發參與進來，平臺只做一些支撐、答疑的作用，但是讓業務方的同學進來，就有一個挑戰：別人沒有學過 Flink，你讓他來開發，業務方願意嗎？對整個業務進一步的抽象，發現我們的需求場景是變化的，實時指標也是變化的，但整個流程卻是不變的，用 y = f(x) 來表示，就是來一個 x 經過計算、變換成結果 y，所以當時就梳理出了哪些是變化的、哪些是不變的，從多變中找不變的東西。這裡還需要一種能力是抽象分層，如果把 f() 只當作一層，就只有一個抽象分層，如果裡面它還有複合函式，那麼就有多個抽象層，這取決於對問題的思考，不同的人設計出的抽象層次是不一樣的。當時借鑑了 Flink 的一些設計思想，將整個過程產品化了，業務方只要選擇、勾選一些資訊，就會自動生成 Flink SQL，然後點選執行即可。SQL 對於大家來講，入門比較簡單，基本上能看得懂，沒太大的難度。平臺側不需要像之前那樣完全投入人力去學習業務知識、開發、測試上線。

總結

本要分享了技術方案設計的一些思路，整個方法論包括本質論、矛盾論、系統論、演進論，透過三個具體的案例闡述怎麼去運用方法論。