相關(guān)文章：《80后聊架構(gòu)：究竟什么是架構(gòu)設(shè)計(jì)？ | 架構(gòu)師之路》

做了多年架構(gòu)設(shè)計(jì)，很多人連架構(gòu)設(shè)計(jì)的關(guān)鍵流程和步驟都不知道。

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

總的來說，架構(gòu)設(shè)計(jì)有四個(gè)大的步驟，其中第二個(gè)步驟最容易被大家忽略。

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

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

Understand the problem & Identify the scope of the system.

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

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

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

Research on existing systems.

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

步驟三：頂層設(shè)計(jì)。

high-level architecture design.

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

• 使用機(jī)房，還是云？
• 使用單體，還是微服務(wù)?
• 要不要cache，要不要mq?
• 用rdb，還是nosql?
• ...

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

步驟四：也是非常重要的一個(gè)步驟啊，解決主要矛盾迭代設(shè)計(jì)。

Refine the design.

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

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

例如：你要做一個(gè)計(jì)數(shù)系統(tǒng)，對(duì)推文的閱讀，轉(zhuǎn)發(fā)，點(diǎn)贊，評(píng)論數(shù)進(jìn)行計(jì)數(shù)。

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

那可能就要加入一些樂觀鎖，異步，批量請(qǐng)求，Copy On Write等巧妙設(shè)計(jì)，甚至犧牲一些一致性。

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

那可能就要加入一些互斥，校驗(yàn)，write-ahead logging等巧妙設(shè)計(jì)。

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

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

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

這也是我非常推崇的兩大核心架構(gòu)設(shè)計(jì)理念：

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

這兩個(gè)架構(gòu)理念，我會(huì)在接下來的100個(gè)架構(gòu)知識(shí)點(diǎn)里反復(fù)提及。

咱們舉個(gè)例子。

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

(4) 如何來做架構(gòu)設(shè)計(jì)呢？

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

分類信息的特點(diǎn)是什么？

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

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

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

需求的性能要求是什么？

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

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

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

①如何品類擴(kuò)展？

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

②如何擴(kuò)展屬性？

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

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

早期利用 MongoDB 的索引，后期利用搜索服務(wù)...

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

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

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

第三步，架構(gòu)頂層設(shè)計(jì)。

宏觀上，結(jié)合 Craigslist 的一些成熟實(shí)踐：

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

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

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

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

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

② 主要矛盾2：多品類帖子屬性的分級(jí)，擴(kuò)展與校驗(yàn)，怎么解？

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

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

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

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

回歸今日話題，架構(gòu)設(shè)計(jì)的四大步驟：

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

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

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

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

“借鑒”這一點(diǎn)，任何不接地氣的架構(gòu)方法，都不會(huì)有人說。

補(bǔ)充閱讀材料

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