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

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

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

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

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

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

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

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

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

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

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

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

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

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

方案：

圖片

方案概述如下：

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

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

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

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

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