架構設計第 1 步：識別復雜度

在設計軟件架構的過程中，識別并理解系統的復雜性是至關重要的一步。這是因為，只有當我們準確地分析出系統面臨的主要復雜性時，才能確保架構設計方案的正確性。如果分析失誤，無論設計方案多么高級，都可能偏離解決實際問題的正確路徑，導致效果不佳。

考慮一個例子：假設一個系統主要的復雜性來源于其業務邏輯的復雜和功能之間的緊密耦合。如果在這種情況下，架構師設計了一個以高吞吐量（TPS為50000/秒）為目標的架構，那么無論這個架構的性能表現有多優秀，它都未能解決系統實際的復雜性問題。

通常，架構的復雜性源于需求對高性能、高可用性、可擴展性等方面的要求。但在分析系統復雜性時，架構師不應該機械地認為所有系統都必須同時滿足這些要求。實際上，大多數情況下，復雜性問題主要集中在上述幾個方面的某一個或某兩個方面。真正同時面臨三個或以上復雜性問題的情況非常罕見，這種情況通常意味著之前的系統設計存在問題，或者是架構師的分析判斷有誤。即便確實面對多重復雜性要求，也應進行優先級排序，逐一解決。

以一個億級用戶平臺為例，該平臺最初的設計目標是模仿騰訊QQ的用戶規模和功能復雜度，導致其設計了超過40個子系統。這種過度設計不僅導致系統過于復雜、運維困難、開發效率低下，而且由于業務并未達到預期的規模，造成了大量資源的浪費。最終，團隊不得不花費額外的兩年時間進行重構，將子系統數量減半，系統才逐漸趨于穩定。

面對一個同時存在多個復雜度問題的系統，最合理的做法是分步驟解決。首先，明確系統面臨的主要復雜度問題，并根據業務需求、技術現狀和團隊能力進行優先級排序。例如，在上述億級用戶平臺的案例中，團隊首先將精力集中在減少子系統數量上，這一改進不僅提高了開發效率，還減少了系統的故障率。在此基礎上，團隊又成功實施了異地多活方案，進一步提升了系統的穩定性。

擔心按優先級解決問題可能導致后續需推倒重來的方案是有理論基礎的，但在實踐中幾乎不會發生。軟件系統的可塑性和靈活性意味著對于同一問題，通常存在多種解決方案。即使真的需要重構，新方案也應該能夠同時解決之前已解決的問題，而這通常依賴于新技術的引入。比如，Hadoop就是一個能夠同時處理大數據的高性能、高可用性和大容量問題的技術解決方案。

對架構師而言，識別系統復雜性是一項挑戰，需要在深入理解需求的基礎上進行全面分析。有經驗的架構師可能能迅速洞察復雜性所在，而對于經驗較少的架構師，則可能需要通過排查法，從不同角度逐一分析，才能準確把握系統的復雜性。

圖片

識別復雜度實戰

在創業公司“前浪微博(虛擬)”的快速發展過程中，其系統架構開始顯現出效率低下的問題，尤其是在多個業務子系統間的協作上。以發布微博為例，從審核到統計、廣告預測再到消息推送，微博子系統需要與十幾個其他系統進行接口調用，每增加一個通知，就意味著額外的接口設計和測試工作，這大大降低了開發效率，同時使問題定位變得異常復雜。同樣的情況也出現在用戶升級至VIP等級時，等級子系統需要通知諸如福利、客服、商品子系統等多個系統進行相應處理。

針對這些挑戰，一位新加入的架構師提出引入消息隊列系統來解耦各個子系統的直接依賴。經過一系列的分析、討論和審批后，該提案得到了批準。

在對消息隊列系統的需求進行深入分析時，中間件團隊采用了“排查法”來確定其面臨的主要復雜性。首先關注的是性能問題。假設前浪微博每天產生1000萬條微博消息，每條微博消息需被十個子系統處理，這意味著日總消息處理量約為1億次。將這個數字分解到每秒，意味著平均每秒需處理115條寫入消息和1150條讀取消息。但為了應對峰值，設計目標通常設定為平均值的三倍，即TPS（每秒事務處理量）為345，QPS（每秒查詢處理量）為3450。即使如此，考慮到業務增長，性能設計目標被進一步設定為峰值的四倍，即TPS為1380，QPS為13800，以保證系統對未來業務增長的充分準備。

接下來是高可用性的需求分析。考慮到消息丟失可能帶來的嚴重后果，如審核系統的消息丟失可能導致違反法規，VIP等級獎勵的不發放可能導致用戶不滿，消息隊列在寫入、存儲和讀取各環節都需保證高度的可靠性。

至于可擴展性，鑒于消息隊列的功能較為固定，當前看來并不是主要的復雜度所在。

綜合上述分析，消息隊列系統面臨的主要復雜性在于高性能的消息讀取和全流程的高可用性保障。這次詳細的分析和討論，不僅適用于“前浪微博”面臨的挑戰，也為其他企業提供了一種系統性問題解決的框架。需要注意的是，這里的性能目標設定為峰值的四倍主要是基于對業務增長速度的預估，并不是一個固定的倍數，不同業務場景下的預估倍數可能會有所不同。