作為架構(gòu)師，工作內(nèi)容并非迷霧重重。一個(gè)經(jīng)驗(yàn)豐富的架構(gòu)師必須對(duì)現(xiàn)有技術(shù)有深刻的了解，并且對(duì)已被實(shí)踐證明的架構(gòu)模式胸有成竹?；趯?duì)業(yè)務(wù)需求的深入理解，他們會(huì)選擇并組合恰當(dāng)?shù)募軜?gòu)模式，進(jìn)而對(duì)這些方案進(jìn)行必要的修改和優(yōu)化。

盡管軟件技術(shù)經(jīng)歷了幾十年的發(fā)展，并且持續(xù)涌現(xiàn)新技術(shù)，成熟的技術(shù)仍占主導(dǎo)，因?yàn)檫@些技術(shù)已被眾多應(yīng)用場(chǎng)景所驗(yàn)證。例如，涉及高可用性的主備方案、集群技術(shù)，高性能的負(fù)載均衡、多路復(fù)用技術(shù)，以及可擴(kuò)展的分層和插件化技術(shù)等，這些都是在明確目標(biāo)后可以迅速找到的解決方案。

通常情況下，只有當(dāng)現(xiàn)有方案無法滿足特定需求時(shí)，我們才考慮創(chuàng)新。然而，這些創(chuàng)新大多仍然建立在成熟的技術(shù)之上。

例如，NoSQL 中的 Key-Value 存儲(chǔ)與數(shù)據(jù)庫(kù)索引本質(zhì)上相似，而 Memcache 實(shí)際上是將數(shù)據(jù)庫(kù)索引轉(zhuǎn)變成獨(dú)立的緩存系統(tǒng)。

Hadoop 的大文件存儲(chǔ)解決方案，基于的是集群和數(shù)據(jù)復(fù)制的技術(shù)。

Docker 的虛擬化技術(shù)是建立在 Linux 容器（LXC）之上的。

同樣，LevelDB 使用的文件存儲(chǔ)結(jié)構(gòu)是跳表（Skip List）。

在《技術(shù)的本質(zhì)》一書中，對(duì)技術(shù)的組合有清晰的闡述：新技術(shù)都是在現(xiàn)有技術(shù)的基礎(chǔ)上發(fā)展起來的，現(xiàn)有技術(shù)又來源于先前的技術(shù)。將技術(shù)進(jìn)行功能性分組，可以大大簡(jiǎn)化設(shè)計(jì)過程，這是技術(shù)“模塊化”的首要原因。技術(shù)的“組合”和“遞歸”特征，將徹底改變我們對(duì)技術(shù)本質(zhì)的認(rèn)識(shí)。

盡管在很多情況下，通過組合和調(diào)整現(xiàn)有的技術(shù)或架構(gòu)模式，我們可以得到所需的解決方案，但這并不意味著架構(gòu)設(shè)計(jì)是一項(xiàng)簡(jiǎn)單的工作。由于可供選擇的模式眾多，可能的組合方案更是數(shù)不勝數(shù)，常常導(dǎo)致同一個(gè)問題可能有多種解決方案。如果在這些組合方案中加入創(chuàng)新元素，可選的解決方案則會(huì)增加更多。因此，設(shè)計(jì)最終的方案并不是一件容易的事，這一階段也常是許多架構(gòu)師易于出錯(cuò)的環(huán)節(jié)。

首先，一個(gè)常見的錯(cuò)誤是追求設(shè)計(jì)出最完美的架構(gòu)。許多架構(gòu)師在設(shè)計(jì)時(shí)常常懷有一種技術(shù)情結(jié)，認(rèn)為只有設(shè)計(jì)出一流的架構(gòu)才能展示他們的技術(shù)水平。例如，在設(shè)計(jì)高可用性方案時(shí)，他們可能會(huì)偏好使用集群方案而不是主備方案，因?yàn)榍罢吒觾?yōu)越和強(qiáng)大；在高性能方案中，可能會(huì)傾向于使用業(yè)界領(lǐng)先的技術(shù)如淘寶的某種方案。

然而，根據(jù)“適用原則”和“簡(jiǎn)單原則”，選擇適合自己業(yè)務(wù)、團(tuán)隊(duì)和技術(shù)能力的方案才是更為理智的選擇。否則，可能會(huì)造成資源的浪費(fèi)，如開發(fā)了遠(yuǎn)超實(shí)際需要的系統(tǒng)，或者設(shè)計(jì)出的系統(tǒng)根本無法由現(xiàn)有團(tuán)隊(duì)實(shí)現(xiàn)。

第二個(gè)常見錯(cuò)誤是只制定一個(gè)方案。許多架構(gòu)師可能會(huì)在心中簡(jiǎn)單比較幾個(gè)方案，然后選擇一個(gè)看似最佳的方案進(jìn)行深入設(shè)計(jì)。這種做法存在多個(gè)缺點(diǎn)：評(píng)估可能過于膚淺，沒有全面考慮，或是由于某個(gè)方案的一個(gè)缺點(diǎn)就草率地否決了它，而忽略了這可能是綜合最優(yōu)的選擇。架構(gòu)師的經(jīng)驗(yàn)和知識(shí)是有限的，有時(shí)候他們的評(píng)估標(biāo)準(zhǔn)可能已過時(shí)或不適用于新情況，或者某些評(píng)估標(biāo)準(zhǔn)本身就是錯(cuò)誤的。

因此，架構(gòu)師應(yīng)該設(shè)計(jì)多個(gè)備選方案，理想的方案數(shù)量是三到五個(gè)。少于三個(gè)可能由于思考不夠全面，多于五個(gè)則可能花費(fèi)過多時(shí)間和精力，且方案間的差異可能不明顯。備選方案應(yīng)具有較大的差異性，如主備和集群方案的區(qū)別，或者不同技術(shù)實(shí)現(xiàn)主備的差異明顯，如使用ZooKeeper與使用Keepalived。

最后，第三個(gè)錯(cuò)誤是備選方案過于詳細(xì)。一些架構(gòu)師可能會(huì)將備選方案寫得非常詳細(xì)，這不僅消耗大量時(shí)間和精力，還可能使人過于關(guān)注細(xì)節(jié)而忽視整體設(shè)計(jì)，從而導(dǎo)致備選方案數(shù)量不足或差異不大。正確的方法是在備選階段關(guān)注技術(shù)選型的顯著差異，而不是深入到技術(shù)細(xì)節(jié)。例如，使用ZooKeeper與Keepalived來實(shí)現(xiàn)主備就是一個(gè)較大的技術(shù)差異，而在使用相同技術(shù)的方案中進(jìn)行細(xì)節(jié)上的區(qū)分，如節(jié)點(diǎn)設(shè)計(jì)的微小變化，這樣的區(qū)分在備選階段并不必要，具體的節(jié)點(diǎn)設(shè)計(jì)可以在最終方案中決定。

方案：

圖片

方案概述如下：

• 實(shí)施一個(gè)分散數(shù)據(jù)的集群架構(gòu)，集群內(nèi)的服務(wù)器按組劃分，每組負(fù)責(zé)存儲(chǔ)特定部分的消息數(shù)據(jù)。
• 每個(gè)服務(wù)器組配置一臺(tái)主用 MySQL 和一臺(tái)備用 MySQL，組內(nèi)實(shí)現(xiàn)主備數(shù)據(jù)復(fù)制，而組間數(shù)據(jù)保持獨(dú)立不進(jìn)行同步。
• 在正常運(yùn)行時(shí)，每組的主服務(wù)器負(fù)責(zé)處理外部的消息寫入和讀取請(qǐng)求，備服務(wù)器則不提供服務(wù)。若主服務(wù)器發(fā)生故障，備服務(wù)器將接管并提供消息讀取服務(wù)。
• 客戶端使用輪詢策略進(jìn)行消息的寫入和讀取操作。

備選方案 3：自主研發(fā)存儲(chǔ)系統(tǒng)的集群方案

在備選方案 2 的基礎(chǔ)上，我們考慮替換 MySQL 存儲(chǔ)，因?yàn)殛P(guān)系型數(shù)據(jù)庫(kù)的特性并不完全符合消息隊(duì)列的數(shù)據(jù)處理需求。借鑒 Kafka 的設(shè)計(jì)思路，可以自行開發(fā)一套專門的文件存儲(chǔ)和復(fù)制系統(tǒng)（具體方案細(xì)節(jié)將在實(shí)際設(shè)計(jì)階段詳細(xì)闡述）。

從高性能消息讀取的單機(jī)系統(tǒng)設(shè)計(jì)來看，由于團(tuán)隊(duì)主要使用 Java，備選方案 2 和 3 均采用了基于 Netty 的高性能網(wǎng)絡(luò)庫(kù)。這反映了團(tuán)隊(duì)的技術(shù)背景對(duì)選擇范圍的影響。一般而言，成熟的團(tuán)隊(duì)不易頻繁更換技術(shù)棧，而新成立的團(tuán)隊(duì)則更可能嘗試新技術(shù)。

以上簡(jiǎn)要介紹了三種備選方案以示范設(shè)計(jì)流程，實(shí)際應(yīng)用中方案會(huì)更為復(fù)雜。架構(gòu)師的技術(shù)儲(chǔ)備和經(jīng)驗(yàn)越豐富，能夠提供的備選方案就越多，這有助于更有效地制定設(shè)計(jì)方案。例如，在開源方案中不僅可以選擇 Kafka，還可以考慮 ActiveMQ、RabbitMQ 等；在考慮集群的存儲(chǔ)方案時(shí)，除了 MySQL，還可以考慮使用 HBase 或?qū)?Redis 與 MySQL 結(jié)合使用；自研的文件系統(tǒng)也可以參考 Kafka、LevelDB 或 HBase 等多種模型。這里由于篇幅限制，不再詳細(xì)展開。