作者 | 高福來（不拔）
來源 | 阿裡技術公衆号
平時聽到一些同學說技術方案沒什麼深度，好難講出來，怎麼去展現技術方案設計的深度是大家普遍關心的一個問題，這個問題不是個例問題，是以分享下自己的一些觀點和看法。主要從三個部分來講：
- 第一部分主要分析為什麼技術方案沒有展現出深度，找到問題後就好解決，并提出技術方案的廣度和深度特征；
- 第二部分是技術方案設計的方法論，主要包括了本質論、沖突論、系統論、演進論四個方法論方法，構成一個閉環回報鍊路；
- 第三部分是通過具體的案例，反複運用第二部分的方法論闡述在執行個體的案例中如何去應用，加深對方法論的了解。
一 技術方案展現廣度和深度
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對于大家來講，入門比較簡單，基本上能看得懂，沒太大的難度。平台側不需要像之前那樣完全投入人力去學習業務知識、開發、測試上線。
技術方案設計案例3
四 總結
本要分享了技術方案設計的一些思路，整個方法論包括本質論、沖突論、系統論、演進論，通過三個具體的案例闡述怎麼去運用方法論。