技術方案設計沒有深度？試試這套方法論

平時聽到一些同學說技術方案沒什麼深度，很難講出來，怎麼去體現技術方案設計的深度是大家普遍關心的一個問題，這個問題不是個例問題，因此分享下自己的一些觀點和看法。主要從三個部分來講：第一部分主要分析為什麼技術方案沒有體現出深度，找到問題後就好解決，並提出技術方案的廣度和深度特征；第二部分是技術... ...

平時聽到一些同學說技術方案沒什麼深度，很難講出來，怎麼去體現技術方案設計的深度是大家普遍關心的一個問題，這個問題不是個例問題，因此分享下自己的一些觀點和看法。主要從三個部分來講：

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

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

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

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

場景簡單：業務場景很簡單，怎麼也設計不出花兒來；

複雜度低：業務複雜度低，很難講得出挑戰出來；

亮點少：運用的技術亮點少，基本上都是現有的中間件或框架來完成；

設計普通：方案缺乏新穎，業內也是這麼做的，沒有體現出自己的設計能力；

……

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

2 原因探究
個人覺得這個問題的最為核心的一點是就事論事，因為只是看到這個事，需要完成某個具體的功能點，而沒有跳出這個事情的表象，去思考到底要什麼、解決了什麼問題、價值是什麼，這樣思考很有可能你現在的解決方案只是其中一個很小的一個點，沒有站在全局去思考問題。曾經我的老師給我講一個觀點，把手掌放在眼前，你只能看到這個手掌，如果把手掌放在遠處，你的視野就更廣了，因此視野更關鍵，不要只關註事情的本身，可以跳出來看看，或者你能想到的更多。
就事論事只是一個表象，它背後還是深層次的原因，個人覺得是缺乏體系化地思考問題，"只見樹木、不見森林"，沒有從不同的維度上去思考問題，只是線性地思考，它直接的表現就是就事論事，只把手頭上的事情完成即可。講體系化思考的書籍很多，大家有興趣可以去瞭解下，幫助自己更好地思考問題。
到這裡其實還沒有結束，還有一個重要的原因是缺乏方法論引導，就是沒有形成自己的一套方法去思考問題、解決問題，這個不同的人有不同的方法，這裡也只是分享自己的一些觀點和方法，不同的人會有自己的方法，有了方法論的引導，拿到一個問題，知道怎麼去分析、思考、解決，遠比只是被動地接受一種具體的方案要好，下次場景變了，很有可能現有的方案是不能支撐的，因此需要建立一套適合自己的方法論，具體在第二部分會分享自己的方法論。

3 技術廣度和深度
廣度和深度對於我們來講並不陌生，大家都知道要體現出廣度和深度，卻不知道怎麼去做。廣度覺得從數量和類型兩個維度去分析（應該還有其它的維度，大家可以自行補充），是讓事物更加地豐富，比如動物園裡有不同的動物，種類比較多，就能更加滿足不同人的觀賞需求；深度主要體現出問題的識別和創新解決上，一個問題大家沒有發現，而你從中發現了，這就是一個深度，比如網上購物，站在今天來看，再平常不過了，但在20年前，並不是每個人能想到的，今天同樣是做電商，每個公司的打法、策略是不一樣的，這就是體現在深度上，深耕於某一個領域。
這裡拿自己的經歷來說明，在之前的公司做優惠券業務（當時營銷比較簡單，就是單一券業務），優惠券只是一種營銷的具體手段，行業內有卡、券、分、金，那麼對於技術來講就是豐富營銷基礎能力，從單一券能力發展至卡、券、分、金的營銷行業標配能力，這個就是體現廣度，從數量、類型上豐富了。而怎麼體現深度呢，營銷中有一個重要問題是如何防控資損，一旦有資損，問題就比較大，因此需要去好好思考和設計方案，當時借鑒穩定性方案，分成事前、事中、事後三個階段去防控資損，每一個階段里又包含了不同的方案，深度主要體現對問題的識別，以及怎樣創新地去解決，重點是創新，做到人無我有、人有我優。

4 怎樣證明技術方案是好的
大家在和別人分享、交流技術方案時，有人就會提出尖銳的問題，為什麼說你的技術方案是好的，其實這個問題是一個非常好的問題，值得大家去思考。
常見大家去講一個技術方案時，把背景、目標講完之後，直接給出了技術方案，其實技術方案本身並不重要，重要的是你是怎麼思考的，思考的過程非常重要，強調的是WHY，HOW很重要，但WHY更重要。這裡有兩個原則：

三段論：大前提、小前提、結論。一定要先講大前提，它是一個有力的支撐，比如寫議論文時，平時常寫"魯迅說過xxxxx"，這個就是大前提，對於技術方案設計上，就是要看業內的方案，業界的標桿在哪裡，和它有什麼不一樣、創新了什麼，一目瞭然，往往大家忽略了這個大前提，直接講自己的方案，哪怎麼證明你的就是好的呢，沒有對比就沒有感覺。

環境論：有時業內還沒有具體的方案，或者是當下你的公司不適合業內頂配的方案，比如"中國特色社會主義"，它就是強調當前的環境，結合了具體的業務場景來權衡考慮的，並不是行業內的最優方案就是適合你的，方案的設計一定要有權衡、選擇，設計出最適合當前環境的方案。

技術方案設計的廣度和深度

二技術方案設計的方法論
1 方法論到底是什麼
經常有人講方法論，方法論也讓人感覺比較玄乎，感覺是一種虛無縹緲的東西，方法論在百科中的解釋是方法論是關於人們認識世界、改造世界的方法的理論，看了這個定義，大家還是不清楚它到底是什麼，只知道它挺厲害的，但不知道方法論到底是什麼、有哪些方法論、應該如何去運用方法論，所以這裡談下自己的理解。
自己對方法論的理解是方法論是讓方法更成更方法的方法，方法論拆分成兩個詞方法和論，因此它首先是一種方法，方法是為瞭解決具體的問題，比如大家熟知的穩定性建設，全鏈路壓測、異常監控等都是具體的方法，但這些方法都是一個個散的點，並不是最好的方法，方法論強調的是好的方法；然後再看"論"，論是議論、分析、思考的過程，它最大的好處是讓方法更好，還是拿穩定性建設來講，現在有成熟的方法論，分成事前、事中、事後三個階段，事前包括容量評估、全鏈路壓測、強弱依賴……，這樣講就比較成體系，將它劃分成事前、事中、事後，全覆蓋了整個過程，你基本上挑不出什麼毛病出來。因此方法論是對解決方法進一步的升華和提煉，形成更通用、成體系的方法，它並不是虛無縹緲的東西。
方法論是通過不完全歸納法總結出來的，方法論並不是萬能的，比如你看到的天鵝都是白色的，萬一哪天出現了一隻黑天鵝，就說明當時的歸納是不完全歸納的。

2 技術方案設計方法論
下麵所說的方法論都是存在的，自己只是組合運用了這些方法論而已，下麵總結下自己工作中使用的一些受益比較大的方法論：

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

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

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

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

技術方案設計設計方法論

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

1 高併發技術方案
高併發在之前是非常火的，大家也都能說出一些解決措施，如使用緩存、MQ、並行……下麵談下自己的一些思路。

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

問題分析
高併發的矛盾就是有限的資源對大量的請求，解決了這個矛盾就解決了高併發的問題。接下來就是平衡這對矛盾，一般是採用"中和"的思想，就像中醫治病的，寒病用熱藥、熱病用寒藥，因此就會站在資源和請求兩個維度去思考，資源能不能變多了，常見的有水平擴展，資源能不能變強呢，常見的是性能優化，性能優化又會分成前端優化、網路優化、計算優化、存儲優化、程式優化……，請求能不能減少呢，比如通過答題錯峰，合併請求等等，這樣解決問題的思路就一下子打開了。
解決方案是重要的，但設計的過程更為重要，清楚了問題是什麼、怎麼去分析，解決方案是自然而然就出來了，重點的還是分析的過程。

技術方案設計案例1

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

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

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

技術方案設計案例2

3 可擴展性技術方案
可擴展性設計是現在一個非常典型的場景，當時遇到的場景是實時人群計算場景，每當業務方提一個需求過來，就要進行對數據口徑，然後熟悉業務方的一些業務，接下來就是編寫Flink任務，測試、核對，最後上線，整個流程下來至少2周，需求提一個簡單需求，很疑惑為什麼要2周才能上線。
問題定義：業務方希望快速上線而實際開發要2周的矛盾，究其主要原因是不懂業務，需要有熟悉的階段，這個階段耗時比較多，真正開發的時間不多，怎麼去解決這個問題呢。
問題分析：雖然主要的矛盾找到了，很明顯的一個方向是讓業務方的開發參與進來，平臺只做一些支撐、答疑的作用，然而讓業務方的同學進來，就有一個挑戰，別人沒有學過Flink，你讓他來開發，業務方願意麽。對整個業務進一步的抽象，發現我們的需求場景是變化的，實時指標也是變化的，但整個流程卻是不變的，用 y = f(x) 來表示，就是來一個x經過計算、變換成結果 y，所以當時就梳理了出了哪些是變化的、哪些是不變的，從多變中找不變的東西，這裡還需要一種能力是抽象分層，如果把 f() 只當作一層，就只有一個抽象分層，如果裡面它還有複合函數，那麼就有多個抽象層，這起決於對問題的思考，不同的人設計出的抽象層次是不一樣的。當時借鑒了Flink的一些設計思想，將整個過程產品化了，業務方只要選擇、勾選一些信息，會自動生成Flink SQL，然後點擊運行即可，SQL對於大家來講，入門比較簡單，基本上能看得懂，沒太大的難度。平臺側不需要像之前那樣完全投入人力去學習業務知識、開發、測試上線。