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

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

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

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

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

步驟一：理解需求以及定義系統(tǒng)邊界。

Understand the problem & Identify the scope of the system.

理解需求，核心是和產(chǎn)品確定功能要求，以及根據(jù)業(yè)務確定性能要求。

定義系統(tǒng)邊界，核心是要明確系統(tǒng)哪些要做，哪些不做。

步驟二：也就是最容易被忽略的一個步驟，調(diào)研已有的類似的系統(tǒng)。

Research on existing systems.

你做的系統(tǒng)，是業(yè)內(nèi)首創(chuàng)嗎？如果不是，看看類似的系統(tǒng)是怎么做架構設計的。參考成熟的方案，能讓你的架構設計事半功倍。

步驟三：頂層設計。

high-level architecture design.

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

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

這里要包含系統(tǒng)架構的粗略圖，以及實現(xiàn)核心需求的流程圖。

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

Refine the design.

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

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

例如：你要做一個計數(shù)系統(tǒng)，對推文的閱讀，轉發(fā)，點贊，評論數(shù)進行計數(shù)。

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

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

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

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

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

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

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

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

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

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

咱們舉個例子。

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

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

第一步，探究功能需求，性能需求，確定系統(tǒng)邊界。

分類信息的特點是什么？

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

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

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

需求的性能要求是什么？

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

第二步，調(diào)研類似系統(tǒng)的方案。

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

①如何品類擴展？

服務垂直拆分，數(shù)據(jù)垂直拆分...

②如何擴展屬性？

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

③如何實現(xiàn)搜索？

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

④如何應對大數(shù)據(jù)量，高并發(fā)量？

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

總之，通過調(diào)研，對已有的方案有個初步的了解。

第三步，架構頂層設計。

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

• 業(yè)務垂直拆分；
• 微服務分層，集群化；
• 數(shù)據(jù)庫水平切分；
• 緩存降壓；
• ...

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

第四步，根據(jù)主要矛盾迭代設計。

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

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

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

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

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

潛在方案：統(tǒng)一信息檢索服務E-search。

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

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

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

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

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

保持開放的心態(tài)，借鑒優(yōu)秀的方案，是優(yōu)秀架構師的核心品質(zhì)。

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

補充閱讀材料

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