相關文章：《80后聊架構：究竟什么是架構設計？ | 架構師之路》

做了多年架構設計，很多人連架構設計的關鍵流程和步驟都不知道。

很多人確實上線了很多系統，也確實做了很多需求，但基本上都是毫無方法，全憑自己想象的在做架構設計。

總的來說，架構設計有四個大的步驟，其中第二個步驟最容易被大家忽略。

畫外音：別人寫文章，都說最后一個步驟最重要，我就是不按套路出牌，說第二個步驟最重要。

步驟一：理解需求以及定義系統邊界。

Understand the problem & Identify the scope of the system.

理解需求，核心是和產品確定功能要求，以及根據業務確定性能要求。

定義系統邊界，核心是要明確系統哪些要做，哪些不做。

步驟二：也就是最容易被忽略的一個步驟，調研已有的類似的系統。

Research on existing systems.

你做的系統，是業內首創嗎？如果不是，看看類似的系統是怎么做架構設計的。參考成熟的方案，能讓你的架構設計事半功倍。

步驟三：頂層設計。

high-level architecture design.

設計系統的主要組件，以及它們之間的交互方式。例如:

• 使用機房，還是云？
• 使用單體，還是微服務?
• 要不要cache，要不要mq?
• 用rdb，還是nosql?
• ...

這里要包含系統架構的粗略圖，以及實現核心需求的流程圖。

步驟四：也是非常重要的一個步驟啊，解決主要矛盾迭代設計。

Refine the design.

(1) 頂層設計完之后，哪里是系統的主要矛盾？

我們要根據潛在的主要矛盾，細化與迭代頂層設計。

例如：你要做一個計數系統，對推文的閱讀，轉發，點贊，評論數進行計數。

(2) 假如主要矛盾如果是并發，1秒10萬次？

那可能就要加入一些樂觀鎖，異步，批量請求，Copy On Write等巧妙設計，甚至犧牲一些一致性。

(3) 假如主要矛盾是一致性，不允許數據出錯？

那可能就要加入一些互斥，校驗，write-ahead logging等巧妙設計。

迭代設計，解決完一個主要矛盾，繼續解決次要矛盾，直到所有的功能需求與性能需求得到滿足。

這里面有個地方要注意：在第四步迭代設計的過程中，有可能會發現第三步頂層設計的缺陷。這個時候，可能要優化甚至推翻第三步頂層設計。

這也是為什么，一些系統運行了幾年，就要進行重構。當初的頂層設計已經滿足不了現有的業務需求了。在原有頂層設計基礎上，解決不了主要矛盾了，那就重構頂層設計來解決。

這也是我非常推崇的兩大核心架構設計理念：

• 其一，任何脫離業務的架構設計都是耍流氓；
• 其二，架構不只是設計而來的，更是迭代與演進而來的；

這兩個架構理念，我會在接下來的100個架構知識點里反復提及。

咱們舉個例子。

假如業務需求是：“我想做一個1萬屬性，100億數據，每秒10萬吞吐的分類信息平臺，像58同城一樣，2個月實現”。

(4) 如何來做架構設計呢？

第一步，探究功能需求，性能需求，確定系統邊界。

分類信息的特點是什么？

招聘、房產、二手、二手車、黃頁... 品類繁多，帖子schema不固定...

分類信息的典型場景是什么？

帖子發布，帖子瀏覽，帖子搜索（每個屬性都可能被搜索）...

需求的性能要求是什么？

數據量巨大，吞吐量巨大，用戶實時訪問，請求延時敏感...

第二步，調研類似系統的方案。

國外信息分類做得最好的應該是 Craigslist 了，網上調研一些相關的資料，可以了解到，其核心的一些關鍵設計點：

①如何品類擴展？

服務垂直拆分，數據垂直拆分...

②如何擴展屬性？

利用 MongoDB 的 schema-free 特性...

③如何實現搜索？

早期利用 MongoDB 的索引，后期利用搜索服務...

④如何應對大數據量，高并發量？

數據水平切分，邏輯處理服務化，集群化，緩存降低數據庫壓力...

總之，通過調研，對已有的方案有個初步的了解。

第三步，架構頂層設計。

宏觀上，結合 Craigslist 的一些成熟實踐：

• 業務垂直拆分；
• 微服務分層，集群化；
• 數據庫水平切分；
• 緩存降壓；
• ...

大的方向基本就能把握住。

第四步，根據主要矛盾迭代設計。

① 主要矛盾1：多品類帖子數據的分開存儲，使得核心業務流程及其復雜，怎么解？

潛在方案：統一帖子中心服務IMC（Info Management Center）。

② 主要矛盾2：多品類帖子屬性的分級，擴展與校驗，怎么解？

潛在方案：統一分類管理服務CMC（Category Management Center）。

③ 主要矛盾3：大數據量，高并發，跨品類的多屬性搜索，怎么解？

潛在方案：統一信息檢索服務E-search。

這里，是一個架構設計過程的案例演示，主要用以說明設計流程。具體“1萬屬性，100億數據，每秒10萬吞吐的分類信息平臺”的設計細節，詳見后文的補充閱讀資料。

回歸今日話題，架構設計的四大步驟：

• 其一，理解需求以及定義系統邊界；
• 其二，調研已有的類似的系統；
• 其三，頂層設計，定義核心組件與交互；
• 其四，針對主要矛盾迭代設計；

有人問，第二步借鑒已有成熟系統的方案，在別的架構設計方法中，沒有看到過這個步驟呀？莫不是搞笑的吧。

我非常嚴肅地聲明，這個步驟非常重要，調研一定要多花時間。不行的程序員，看誰的代碼都是屎；不行的架構師才會認為，我的方案最牛逼，別人的方案都是屎，但其實，自己原創的大部分方案才是屎。

保持開放的心態，借鑒優秀的方案，是優秀架構師的核心品質。

“借鑒”這一點，任何不接地氣的架構方法，都不會有人說。

補充閱讀材料

上述案例架構設計方案細節，詳見：《1萬屬性，100億數據，每秒10萬吞吐，架構如何設計？》