之前我發過一次孫玄（人稱：玄姐）會在阿里云開發者社區開一個五節課程的架構師成長之路直播課，我也學習了他的第一課《技術人的道與術》后做了學習整理筆記并分享成文。今天，和你分享我學習他的第四課《架構設計思維模型》做的學習筆記，會和你分享三個架構師需要具備的架構設計思維模型。

1、模型1：業務需求至簡抽象分析模型

玄姐認為，架構師需要具備的第一個重要的思維模型就是：業務需求至簡抽象分析思維模型。通俗來講，就是能不能抽象地分析出業務方或者客戶方提出的一個需求背后，他真正的需求是什么。換句話說，能否分析出這個需求背后的本質是什么，而這個過程，就是業務需求抽象的過程。

其實這個思維模型也是產品經理的必修課，對于產品經理來說，挖掘「一匹更快的馬」背后真實的用戶動機是最重要的基本功，不要停留在用戶提出的所謂需求上。

有句關于產品需求挖掘的名言「用戶不需要1/4 英寸的鉆頭，他需要的是1/4 英寸的洞」「用戶需要的也不是1/4 英寸的洞，而是在墻上掛一幅畫」「用戶不是需要畫，他需要房間的格調」等等。這些聽起來像是抬杠的演繹，其實就是不斷探索和挖掘真正需求的過程。

在實際的實踐過程中，我們可能經常使用的方法是5個Why，即連續提問5個為什么，從而追究其根本原因，試著找到用戶背后的真正動機。

我在之前學習劉潤老師的《商業洞察力》時，了解到洞察力這個概念，其實它就對應了這個需求抽象分析的過程。所謂洞察力，就是透過表象，看清“系統”這個黑盒子里，要素以及它們之間連接關系的能力。

潤總說，任何系統都可以進一步拆解為多個要素，以及要素之間的連接方式，即系統=要素 x連接關系。

舉個例子，對于電腦來說，主板、顯示器等組件和零件就是要素，而它們之間如何銜接和搭配讓電腦這個系統運轉起來，就是連接關系。我們往往容易看見整體，卻容易忽視連接關系。

所有無法解決的問題，可能都是因為我們看不清。例如，普通的人觀察一只手表，有洞察力的人可能會洞察幾百個零件之間的“連接關系”。普通的人觀察一次合作，有洞察力的人可能會洞察協議背后的利益分配、分析轉嫁的“連接關系”。普通的人觀察一個團隊，有洞察力的人洞察團隊里責、權、利的錯綜復雜的“連接關系”。

因此，我也認為，洞察力也是玄姐提到的這個業務需求至簡抽象分析模型的關鍵。

2、模型2：哲學本質架構設計思維模型

玄姐認為，市面上有很多的架構，比如單體架構、SOA架構、微服務架構等等，他們的存在都有一個最本質的原因，那就是：“滿足公司多業務場景的需求，最終達到公司層面降本增效的終極目的”。換句話說，只有做出的架構最終能夠幫助公司實現降本增效，才是滿足公司的業務場景的架構。

當然，這對于我們來說還是太抽象，于是玄姐給了細化的內容，也就是在做架構設計的時候，有一些最基本的定律。如果我們能夠一層一層的抽象和分析，將架構設計映射到這些定律，那么就具備了這些架構設計的思維模型。

一種思維模型是：CAP架構設計思維模型

CAP是三個英文單詞的首字母，分別是consistency、availability、partition tolerance。即強一致性、可用性、網絡分區容忍性。CAP定律說的是，分布式系統三者只能同時滿足二者，強一致性、可用性、網絡分區容忍性三者同時滿足的情況不存在。

如果我們能夠結合業務場景，將CAP模型用起來，那么我們就能夠掌握這個思維模型，就會離本質又進一步。否則，我們僅僅是掌握了CAP定律，而不知道怎么去應用。

另一種思維模型是：BASE架構設計思維模型

BASE是對CAP中一致性和可用性權衡的結果，其核心思想是即使無法做到強一致性，但每個應用都可以根據自身業務特點，采用適當的方式來使系統達到最終一致性。在很多情況下，我們都是沒辦法用CAP定律來進行映射的，但是可以通過映射到BASE的思維模型來去做。這時候能不能把它映射到BASE模型上去做，也是很重要的。

玄姐也給出了一個例子，以設計分布式鎖為例聊了一下存儲模型的選擇。

一般情況下，分布式鎖是一個CP模型，我們要求你的鎖不能重復。但是，難道分布式鎖的實現永遠是CP模型嗎，有沒有一些場景，AP模型也是可以的。當然，只要涉及到金融相關的，比如說，我的交易，我的支付，我的轉賬，要求一定是CP模型。但是，當涉及到社交相關的，比如說，我發一個消息給朋友，本來消息發重復了以后應該過濾掉，但是它沒有過濾掉，朋友收到我兩條重復的消息，比如說今天晚上有空一起吃飯嗎，本來他不想回我，當他發現這個消息發了兩遍，他覺得我的邀請非常誠懇，他就答應我了。在這種場景下是可以用AP模型的。所以分布式鎖也要根據場景折中，一定要把架構設計映射到CAP定律，到底采用一個什么樣的模型來打造會比較合適，是非常重要的一個方向。

有了這樣的思維模型之后，再去設計分布式鎖就會比較明晰。在存儲模型的選擇上，如果是一個AP模型，可以用redis來做。如果是一個CP模型，則可以用etcd來做。有了最底層的架構設計之道，再去做其他場景也是很容易遷移復用的。

玄姐說：一切脫離業務場景談架構都是耍流氓！

3、模型3：根據場景Balance架構設計思維模型

玄姐認為，我們需要根據實際的業務場景來合理地設計系統架構，這個業務場景，包括了項目時間、團隊研發能力、團隊運維能力等。但是，最重要的還是要根據場景去折中或者平衡的這樣的一種能力，其實也是一種重要的思維模型。

比如，有些人在大廠經歷了許多磨練，具備了一定的架構設計能力，但當他去一個小廠或者一個創業公司的時候，再根據大廠的業務來設計架構的時候，他其實不一定能夠設計出一個適合于當前業務的架構。因為，他沒有場景折中能力，只能依葫蘆畫瓢，但是畫出來的不一定是最優雅的。

將場景折中能力進一步細化，就會得到“合適”架構設計思維模型。換句話說，在大廠我們可以用這樣的分布式架構，但是去了小廠，則不一定要繼續設計一個分布式架構，這時對于初創期的小廠，可能一個單體架構會是一個比較好的起點方向。

什么叫做合適，可能還是比較抽象，對它進一步拆解，就會得到適度超前架構設計思維模型。換句話說，我們設計的架構應該是能夠滿足一定時間內業務的發展的，那么多長的時間算適度？玄姐認為半年到一年的時間段比較符合適度超前的。

看到這里，我回顧了一下我所在公司的架構設計，基本也是朝著適度超前的原則來設計的，我們基本是朝著滿足未來一年內的需求來約定的。

4、學習小結

跟玄姐學習了思維模型，這其實是一種以不變應萬變的設計能力，不變的是架構設計的思維模型，萬變的則是各種業務場景。架構設計的終極之道，也是玄姐提到的哲學本質就是降本增效，我們所有的設計其最終目的都是希望公司能夠降低成本提高效益。

參考資料

孫玄，《架構師的架構設計思維模型》from 阿里云開發者社區

findyi，《人與人的差異在于認知》

劉潤，《商業洞察力30講》

專欄：EdisonTalk（愛迪生說）

本文作者EdisonZhou，架構師，阿里云MVP，博客園"推薦博客"博主，Scrum聯盟認證CSM，愛好閱讀與分享。

本文首發于EdisonZhou的公眾號“恰童鞋騷年”，歡迎關注，第一時間獲得更多內容分享。