平時聽到一些同學說技術方案沒什么深度，很難講出來，怎么去體現技術方案設計的深度是大家普遍關心的一個問題，這個問題不是個例問題，因此分享下自己的一些觀點和看法，主要從三個部分來講：
-
第一部分主要分析為什么技術方案沒有體現出深度，找到問題后就好解決，并提出技術方案的廣度和深度特征；
-
第二部分是技術方案設計的方法論，主要包括了本質論、矛盾論、系統論、演進論四個方法論，構成一個倍訓反饋鏈路；
-
第三部分是通過具體的案例，反復運用第二部分的方法論闡述在實體的案例中如何去應用，加深對方法論的理解，
一 技術方案體現廣度和深度
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
四 總結
本要分享了技術方案設計的一些思路，整個方法論包括本質論、矛盾論、系統論、演進論，通過三個具體的案例闡述怎么去運用方法論，
作者丨高福來
本文來自博客園，作者：古道輕風，轉載請注明原文鏈接：https://www.cnblogs.com/88223100/p/Methodology-of-technical-solutions.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/513111.html
標籤：架構設計
上一篇：微服務架構 | 服務架構的演進