這是一本正經的《設計奧義》。

我們經常在技術設計上會考慮這一點：這樣的技術設計合不合理？

促使我們考慮技術設計是否合理的出發(fā)點很多，換個說法就是——評判技術設計合理性的維度有很多。

就像我們是三維世界無法理解四維世界一樣，第四維到底是在三維空間之上加了空間維度還是時間維度？這一直頗受爭議，但你有沒有想過——萬一第四維不是空間也不是時間呢？

乍一聽這個質疑也挺“合理”的，但請別忘了，“維度”是由人類發(fā)明的，只是個數(shù)學模型而已，確實也存在于計算機（多維數(shù)組），但它在現(xiàn)實世界上并不存在，現(xiàn)實世界上我們已知的只存在三維，或許根本就不存在其他維度的時空，什么多世界理論、平行宇宙，全都是思想實驗，從有限的經驗推斷而來，沒有一個真正能“落地”的。

Whatever.

我們再回過頭來看：“合理”本身就是一個主觀的形容詞（定語），怎么定義你的技術設計是合理還是不合理，取決于評判者，評判者可以同時處于多個評判維度的“疊加態(tài)”，明確了評判維度之后，才能“坍縮”成具象的評判標準。如果我們沒有統(tǒng)一的認知，沒有約定俗成的評判標準，做項目就會像時空維度難題一樣，在計算機世界難以落地，畢竟，“PPT架構師”可不是個褒義詞。

“設計”的結果不是薛定諤的貓，它擺在那里，你看到與看不到，不影響它的客觀存在，“評判標準”就是主觀產生的，由數(shù)學推理或經驗總結而來。那在合理性設計的評判標準里，我們一般有什么經驗可以傳承或借鑒？

在這里，我給大家總結一些經驗之談。

程序員十二時辰

一問：數(shù)據一致性考慮了嗎？

CAP定理告訴我們，一致性、可用性、分區(qū)容錯性三者不可同時兼得，怎么記住這個特性？我們用不可能三角來理解它：

CAP原則的不可能三角

當然，這個有趣的三角形還能解釋其它比較著名的定律，比如投資不可能三角——投資的三個重要維度 “流動性”、“收益”和“風險”，他們往往不能全部同時保障。

炒房就是個很好的例子，雖然房產流動性差，但風險低、收益賊高呀；又比如炒期貨，高杠桿高收益，流動性好，但也伴隨著高風險的存在，買了期貨你就是暴富和韭菜的疊加態(tài)，永遠不知道自己哪一秒變韭菜。現(xiàn)在投資什么最好呢？30歲之前投資自己，30歲以后說不準，但是期貨就別買了（別問我怎么總結的）。

由CAP定理衍生出了BASE理論（基本可用、軟狀態(tài)、最終一致），可以說兩者是分布式系統(tǒng)的基石。在實際項目研發(fā)中，系統(tǒng)高可用基本上由運維部門來支撐的，分區(qū)容錯在設計各個微服務就已經考慮在內，而業(yè)務開發(fā)關心的更多是數(shù)據一致性，數(shù)據準不準確才是大部分開發(fā)人員需要考慮的事情。

具體是指哪方面的數(shù)據一致性呢？為什么會有數(shù)據一致性問題？

凡是涉及到網絡IO、磁盤IO都會產生一致性問題。比如程序（內存）與文件（磁盤）的數(shù)據同步，各個微服務之間的數(shù)據同步等，根本原因在于內存與內存之間、內存和磁盤之間、各個網絡服務之間存在區(qū)域邊界劃分（粒度不同）。計算機的兩個區(qū)域可不像兩個糾纏的量子一樣能同時發(fā)生變化，計算機的樂高世界是0和1，是集成電子電路，基本通訊單位是電子。數(shù)據會受到各個交換機之間通訊的影響、內外存交換時序的影響、CPU運算時差的影響等等，我們要解決的是數(shù)據在各種粒度分區(qū)下的通訊問題，所謂數(shù)據同步的“強一致”，在更細粒度的范圍還是會失效。

二問：隔離性怎么樣，邊界是否清晰？

思考一下，計算機為什么要刻意把內存和磁盤兩個區(qū)域劃分開來？內存使用磁盤的空間，不是能加載更多程序嗎？

之所以把它們劃分隔離開來，是因為設計之初就考慮把它們用于解決不同的問題——內存的數(shù)據需要快速存取，磁盤的數(shù)據需要持久穩(wěn)定，內存是計算機的工作場所，磁盤用來存放暫時不用的信息。內存是CPU和硬盤數(shù)據之間的緩沖，CPU只能讀取內存里的數(shù)據。從單一職責上看，它們各自負責各自的工作范疇，互不干涉而又緊密連接。

以小看大，我們在實際項目開發(fā)中是怎么做隔離的呢——跨庫表與表之間使用表/字段冗余隔離、領域模型使用邊界上下文隔離、不同的業(yè)務聚合使用微服務隔離、服務內部與feign之間使用防腐層隔離等等……這是一種對內高內聚、對外低耦合的設計、一種“變化”與“不變”的博弈。

任何一個事物都應該有清晰的邊界，當邊界不清晰的時候，我們就需要考慮把它們給輪廓化，少一些模糊地帶，明確職責以后，也有利于團隊協(xié)作與組織管理。

三問：擴展性怎么樣，能否快速擁抱業(yè)務變化？

擴展性考慮的是抽象能力，在PRD分析的時候，要考慮到哪些數(shù)據模型、哪些表、哪些字段后續(xù)可能會擴展的，反復與產品經理確認，評估一下需要抽象到什么程度。

舉個簡單的例子，比如一張表既要保存銷售訂單也要保存售后訂單，如果用一個字段存銷售單號進行關聯(lián)，另一個字段存售后單號進行關聯(lián)，萬一以后再加一個采購單等等各種單，就需要重新加一個采購單號的字段……這時我們在設計之初就要考慮清楚，以后會不會有別的類型的訂單，如果有，就抽象成單據類型+業(yè)務單號來表示。

對于明確不會擴展的部分也不需要過于抽象，抽象也不一定總比具象優(yōu)，還是要根據實際業(yè)務場景來評判。

四問：業(yè)務時序正確嗎？

有很多時候我們時序圖，是為了搞懂業(yè)務時序、系統(tǒng)操作時序，避免出現(xiàn)期望的步驟執(zhí)行顛倒產生的時序邏輯錯誤。

舉個簡單的例子，在訂單中心異步調用支付中心創(chuàng)建某條記錄，隨即在同一個線程內又同步調用支付中心操作這條記錄。如果異步線程無法在主線程后續(xù)操作這條數(shù)據之前完成數(shù)據創(chuàng)建，就會發(fā)生時序錯誤。在流程復雜的情況下，同步異步各種流程穿插在一起，就特別容易出錯。

這就需要考驗邏輯是否縝密了，數(shù)據什么時候該生成，什么時候該操作，什么時候該歸檔或銷毀，把數(shù)據模型的生命周期給管理起來，用戶和各個模型之間的生命周期是如何關聯(lián)起來的，想明白就不難了。

五問：高并發(fā)場景扛得住嗎？

開發(fā)之前我們經常會考慮一些實際業(yè)務場景：這個功能是給誰用的，會有多少人同時使用？實際上我們考慮的是高并發(fā)場景。

高并發(fā)的本質是什么？它的瓶頸在哪里呢？怎么評判合理范圍？

高并發(fā)指的是高并發(fā)讀寫，一般用于評判系統(tǒng)對數(shù)據的吞吐能力、處理能力，當有大量的讀寫請求過來的時候，系統(tǒng)能不能接得住這些流量。

• 如果是讀多寫少，是不是要考慮在內存預加載磁盤數(shù)據，使用緩存，提高讀IO速度；
• 如果是寫多讀少，是不是要保證寫入順序，防止并發(fā)問題，能不能批量寫入，減少寫IO次數(shù)。

了解了底層邏輯以后，評判合理范圍就變成簡單的數(shù)學問題了，先分析資源瓶頸在CPU、IO、還是內存等等，通過算式可得：峰值資源瓶頸=單位平均資源*峰值數(shù)量。

當單機的CPU、IO利用率已經最大化，還是不能滿足實際業(yè)務場景，這時就多機擴展并行處理業(yè)務流量，或者引入一些中間件來實現(xiàn)“削峰填谷”、“熔斷降級”，最終實現(xiàn)高并發(fā)、高性能、高擴展的新“三高”設計。

從這個層面上講，架構設計實際上也是一種管理活動，只是架構師們在這里管理的不是人，而是計算機資源，包括CPU、內存、磁盤IO、網絡IO等，把計算機資源有效地組織管理起來即可。

架構師需要考慮的事情很多，數(shù)據一致性、隔離性、擴展性、高并發(fā)等等，這只是評判業(yè)務設計、架構設計的幾個常用維度，我們需要做的就是不斷總結并應用于實際問題上。

怎么把一些好的思維方式方法與實際問題關聯(lián)起來呢？分享一個好方法給你——

當你學習到一個新的思維方式方法的時候，先把它用思維導圖記下來，然后把3個已知的問題與之關聯(lián)起來；當你遇到問題的時候，把它記錄下來，然后調用你的一個思維方式與之關聯(lián)。久而久之，咱們解決問題與思維方式的關聯(lián)性就越來越強，處理問題不再靠過去的經驗，而是使用科學高效的思維方式方法來解決，不斷給自己筑建“元能力（Meta capability）”的壁壘。

技術思維與管理思維一樣，存在普適性，所以我們不講特殊，我們只有真正掌握那些“不變”的東西，把那些“變化”的事情固化成流程（升維的過程），才能在工作中，為企業(yè)“降本增效”。

這篇聽起來可能有點“PPT”的味道，先當個“PPT架構師”也未嘗不可，現(xiàn)在創(chuàng)業(yè)公司先賣PPT解決方案的就不在少數(shù)，前提是畫的餅夠不夠大、有沒有人愿意聽，成長的路上總會有“眼高手低”的過程。

所以，有時候適當抽象概括一些概念也挺好的，時常給自己的思維充充電。

就好比——“設計合不合理”可以抽象成“設計的合理性”，“能否快速擁抱業(yè)務變化”可以概括成“業(yè)務擴展性”，你說“看完點了個贊”能不能提高我的“分享積極性”？

老規(guī)矩，一鍵三連，日進兩千，點贊在看，年薪百萬！