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

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

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

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

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

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

同樣，LevelDB 使用的文件存儲結構是跳表（Skip List）。

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

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

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

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

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

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

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

方案：

圖片

方案概述如下：

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

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

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

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

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