此為筆記
課程鏈結
從今天開始，我將分 4 期，結合複雜度**和架構設計原則，通過乙個模擬的設計場景「前浪微博」，和你一起看看在實踐中究竟如何進行架構設計。今天先來看架構設計流程第 1 步：識別複雜度。
我在前面講過，架構設計的本質目的是為了解決軟體系統的複雜性，所以在我們設計架構時，首先就要分析系統的複雜性。只有正確分析出了系統的複雜性，後續的架構設計方案才不會偏離方向；否則，如果對系統的複雜性判斷錯誤，即使後續的架構設計方案再完美再先進，都是南轅北轍，做的越好，錯的越多、越離譜。
例如，如果乙個系統的複雜度本來是業務邏輯太複雜，功能耦合嚴重，架構師卻設計了乙個 tps 達到 50000/ 秒的高效能架構，即使這個架構最終的效能再優秀也沒有任何意義，因為架構沒有解決正確的複雜性問題。
架構的複雜度主要**於「高效能」「高可用」「可擴充套件」等幾個方面，但架構師在具體判斷複雜性的時候，不能生搬硬套，認為任何時候架構都必須同時滿足這三方面的要求。實際上大部分場景下，複雜度只是其中的某乙個，少數情況下包含其中兩個，如果真的出現同時需要解決三個或者三個以上的複雜度，要麼說明這個系統之前設計的有問題，要麼可能就是架構師的判斷出現了失誤，即使真的認為要同時滿足這三方面的要求，也必須要進行優先順序排序。
由於業務沒有發展，最初的設計人員陸續離開，後來接手的團隊，無奈又花了 2 年時間將系統重構，合併很多子系統，將原來 40 多個子系統合併成不到 20 個子系統，整個系統才逐步穩定下來。
如果運氣真的不好，接手了乙個每個複雜度都存在問題的系統，那應該怎麼辦呢？答案是乙個個來解決問題，不要幻想一次架構重構解決所有問題。例如這個「億級使用者平台」的案例，後來接手的團隊其實面臨幾個主要的問題：系統穩定性不高，經常出各種莫名的小問題；系統子系統數量太多，系統關係複雜，開發效率低；不支援異地多活，機房級別的故障會導致業務整體不可用。如果同時要解決這些問題，就可能會面臨這些困境：
因此，正確的做法是將主要的複雜度問題列出來，然後根據業務、技術、團隊等綜合情況進行排序，優先解決當前面臨的最主要的複雜度問題。「億級使用者平台」這個案例，團隊就優先選擇將子系統的數量降下來，後來發現子系統數量降下來後，不但開發效率提公升了，原來經常發生的小問題也基本消失了，於是團隊再在這個基礎上做了異地多活方案，也取得了非常好的效果。
對於按照複雜度優先順序解決的方式，存在乙個普遍的擔憂：如果按照優先順序來解決複雜度，可能會出現解決了優先順序排在前面的複雜度後，解決後續複雜度的方案需要將已經落地的方案推倒重來。這個擔憂理論上是可能的，但現實中幾乎是不可能出現的，原因在於軟體系統的可塑性和易變性。對於同乙個複雜度問題，軟體系統的方案可以有多個，總是可以挑出綜合來看價效比最高的方案。
即使架構師決定要推倒重來，這個新的方案也必須能夠同時解決已經被解決的複雜度問題，一般來說能夠達到這種理想狀態的方案基本都是依靠新技術的引入。例如，hadoop 能夠將高可用、高效能、大容量三個大資料處理的複雜度問題同時解決。
識別複雜度對架構師來說是一項挑戰，因為原始的需求中並沒有哪個地方會明確地說明複雜度在**，需要架構師在理解需求的基礎上進行分析。有經驗的架構師可能一看需求就知道複雜度大概在**；如果經驗不足，那只能採取「排查法」，從不同的角度逐一進行分析。
我們假想乙個創業公司，名稱叫作「前浪微博」。前浪微博的業務發展很快，系統也越來越多，系統間協作的效率很低，例如：
新來的架構師在梳理這些問題時，結合自己的經驗，敏銳地發現了這些問題背後的根源在於架構上各業務子系統強耦合，而訊息佇列系統正好可以完成子系統的解耦，於是提議要引入訊息佇列系統。經過一分析二討論三開會四匯報五審批等一系列操作後，訊息佇列系統終於立項了。其他背景資訊還有：
針對前浪微博的訊息佇列系統，採用「排查法」來分析複雜度，具體分析過程是：
我們假設前浪微博系統使用者每天傳送 1000 萬條微博，那麼微博子系統一天會產生 1000 萬條訊息，我們再假設平均一條訊息有 10 個子系統讀取，那麼其他子系統讀取的訊息大約是 1 億次。
1000 萬和 1 億看起來很嚇人，但對於架構師來說，關注的不是一天的資料，而是 1 秒的資料，即 tps 和 qps。我們將資料按照秒來計算，一天內平均每秒寫入訊息數為 115 條，每秒讀取的訊息數是 1150 條；再考慮系統的讀寫並不是完全平均的，設計的目標應該以峰值來計算。峰值一般取平均值的 3 倍，那麼訊息佇列系統的 tps 是 345，qps 是 3450，這個量級的資料意味著並不要求高效能。
雖然根據當前業務規模計算的效能要求並不高，但業務會增長，因此系統設計需要考慮一定的效能餘量。由於現在的基數較低，為了預留一定的系統容量應對後續業務的發展，我們將設計目標設定為峰值的 4 倍，因此最終的效能要求是：tps 為 1380，qps 為 13800。tps 為 1380 並不高，但 qps 為 13800 已經比較高了，因此高效能讀取是複雜度之一。注意，這裡的設計目標設定為峰值的 4 倍是根據業務發展速度來預估的，不是固定為 4 倍，不同的業務可以是 2 倍，也可以是 8 倍，但一般不要設定在 10 倍以上，更不要一上來就按照 100 倍預估。
對於微博子系統來說，如果訊息丟了，導致沒有審核，然後觸犯了國家法律法規，則是非常嚴重的事情；對於等級子系統來說，如果使用者達到相應等級後，系統沒有給他獎品和專屬服務，則 vip 使用者會很不滿意，導致使用者流失從而損失收入，雖然也比較關鍵，但沒有審核子系統丟訊息那麼嚴重。
綜合來看，訊息佇列需要高可用性，包括訊息寫入、訊息儲存、訊息讀取都需要保證高可用性。
訊息佇列的功能很明確，基本無須擴充套件，因此可擴充套件性不是這個訊息佇列的複雜度關鍵。
為了方便理解，這裡我只排查「高效能」「高可用」「擴充套件性」這 3 個複雜度，在實際應用中，不同的公司或者團隊，可能還有一些其他方面的複雜度分析。例如，金融系統可能需要考慮安全性，有的公司會考慮成本等。
綜合分析下來，訊息佇列的複雜性主要體現在這幾個方面：高效能訊息讀取、高可用訊息寫入、高可用訊息儲存、高可用訊息讀取。
「前浪微博」的訊息佇列設計才剛完成第 1 步，專欄下一期會根據今天識別的複雜度設計備選方案，前面提到的場景在下一期還會用到哦。
spark 1 架構設計 基本流程
spark執行架構包括 1 集群資源管理器 cluster manager 2 執行作業任務的工作節點 worker node 3 每個應用的任務控制節點 driver 和每個工作節點上負責具體任務的執行程序 executor 其中，集群資源管理器可以是spark自帶的資源管理器，也可以是yarn或...
IT四架構設計模型
按照頂層設計理論和方法的定義，資訊化頂層體系結構包括業務架構 資訊架構 應用架構和技術架構四大範疇。業務架構定義了整體業務能力以及各部門 各業務的協作關係，由業務要素模型表達整體業務能力，包括業務職能 業務布局和業務組合形態，由業務流程模型表達各部門 各業務的協作關係 資訊架構定義了全域性資訊資源組...
架構設計（3） 架構模式
架構設計學習思維導圖 架構設計系列主要的adm 架構開發方法 主要基於togaf9或者togaf9.1來論述。這是個人學習實踐和總結筆記，專注並不斷積累和更新，努力精進自己。個人拙見,僅供參考。1 架構概述 了解架構基礎知識 架構定義 分類 級別 應用架構演進 架構是否合理 架構誤區等。談談架構 2...