在完成備選方案設(shè)計(jì)后，如何挑選最終的方案是一個(gè)很大的挑戰(zhàn)，因?yàn)槊總€(gè)備選方案都是可行的。但是，沒有哪個(gè)備選方案是完美的，因?yàn)槊總€(gè)方案都存在一些缺點(diǎn)或風(fēng)險(xiǎn)。此外，評(píng)價(jià)備選方案的標(biāo)準(zhǔn)也具有一定的主觀性，可能會(huì)導(dǎo)致設(shè)計(jì)師之間產(chǎn)生爭(zhēng)論。

因此，在實(shí)踐中，許多設(shè)計(jì)師或架構(gòu)師采取了下面幾種指導(dǎo)思想來選擇備選方案：

• 易用型

設(shè)計(jì)師挑選一個(gè)看起來最簡(jiǎn)單、最容易實(shí)現(xiàn)的方案。例如，如果要做全文搜索功能，MySQL的查詢功能比較簡(jiǎn)單，而Elasticsearch的倒排索引設(shè)計(jì)要復(fù)雜得多，所以可能會(huì)選擇MySQL。

• 高端型

高端型的做法與易用型正好相反，設(shè)計(jì)師會(huì)傾向于選擇技術(shù)上看起來最牛的方案。例如，如果要選擇一個(gè)搭配MySQL使用的緩存，可能會(huì)選擇Redis，因?yàn)樗С殖志没?shù)據(jù)字典、主備、集群等功能。

• 經(jīng)驗(yàn)型

設(shè)計(jì)師基于自己的過往經(jīng)驗(yàn)，選擇自己最熟悉的方案。例如，如果設(shè)計(jì)師曾經(jīng)是一個(gè)C++經(jīng)驗(yàn)豐富的開發(fā)人員，現(xiàn)在要設(shè)計(jì)一個(gè)運(yùn)維管理系統(tǒng)，因?yàn)閷?duì)Python或Ruby on Rails不熟悉，可能會(huì)繼續(xù)選擇C++來做運(yùn)維管理系統(tǒng)。

• 統(tǒng)籌規(guī)劃型

統(tǒng)籌規(guī)劃型，就是讓老板來決定最終方案。這種做法可能會(huì)讓設(shè)計(jì)師自己拿捏不定，但最終的責(zé)任會(huì)由領(lǐng)導(dǎo)來承擔(dān)。

不同的做法本身并不存在絕對(duì)的正確或者絕對(duì)的錯(cuò)誤，關(guān)鍵是要根據(jù)不同的場(chǎng)景選擇不同的方式。有時(shí)候要選擇最簡(jiǎn)單的方案，有時(shí)候要選擇最優(yōu)秀的方案，有時(shí)候要選擇最熟悉的方案，甚至有時(shí)候需要領(lǐng)導(dǎo)來拍板。因此，關(guān)鍵問題是如何判斷何時(shí)采用這些不同的選擇方式。在架構(gòu)設(shè)計(jì)流程的第3步：評(píng)估和選擇備選方案中，選擇備選方案的方法應(yīng)該根據(jù)具體場(chǎng)景和實(shí)際情況進(jìn)行評(píng)估和決策。

方案評(píng)估

在評(píng)估和選擇備選方案時(shí)，我們應(yīng)該采用全方位評(píng)估的方法。具體來說，我們需要列出我們需要關(guān)注的質(zhì)量屬性點(diǎn)，并從這些質(zhì)量屬性的維度去評(píng)估每個(gè)備選方案，再綜合挑選適合當(dāng)時(shí)情況的最優(yōu)方案。

常見的方案質(zhì)量屬性點(diǎn)包括性能、可用性、硬件成本、項(xiàng)目投入、復(fù)雜度、安全性、可擴(kuò)展性等。在評(píng)估這些質(zhì)量屬性時(shí)，需要遵循架構(gòu)設(shè)計(jì)原則1“合適原則”和原則2“簡(jiǎn)單原則”，避免貪大求全，基本上某個(gè)質(zhì)量屬性能夠滿足一定時(shí)期內(nèi)業(yè)務(wù)發(fā)展就可以了。

例如，在設(shè)計(jì)一個(gè)購(gòu)物網(wǎng)站時(shí)，如果我們預(yù)期1年內(nèi)能夠發(fā)展到TPS 2000（業(yè)務(wù)一年翻倍已經(jīng)是很好的情況了），在評(píng)估方案的性能時(shí)，只要能超過2000的都是合適的方案，而不是按照淘寶的標(biāo)準(zhǔn)要實(shí)現(xiàn)TPS 10萬。

在評(píng)估未來業(yè)務(wù)發(fā)展的規(guī)模時(shí)，需要考慮架構(gòu)設(shè)計(jì)原則3“演化原則”，避免過度設(shè)計(jì)、一步到位的想法。即使出現(xiàn)業(yè)務(wù)迅猛發(fā)展，也要遵循這個(gè)原則，盡可能讓系統(tǒng)能夠簡(jiǎn)單地?cái)U(kuò)容來跟上業(yè)務(wù)的發(fā)展。

通常情況下，如果某個(gè)質(zhì)量屬性評(píng)估和業(yè)務(wù)發(fā)展有關(guān)系（例如，性能、硬件成本等），可以通過將當(dāng)前的業(yè)務(wù)規(guī)模乘以2 ~4來評(píng)估未來的業(yè)務(wù)發(fā)展規(guī)模。例如，現(xiàn)在的TPS是1000，則按照TPS 4000來設(shè)計(jì)方案；如果現(xiàn)在TPS是10000，則按照TPS 20000來設(shè)計(jì)方案。

完成方案的360度環(huán)評(píng)后，我們可以基于評(píng)估結(jié)果整理出360度環(huán)評(píng)表，一目了然地看到各個(gè)備選方案的優(yōu)劣點(diǎn)。但是360度環(huán)評(píng)表也只能幫助我們分析各個(gè)備選方案，還是沒有告訴我們具體選哪個(gè)方案。因?yàn)闆]有哪個(gè)方案是完美的，不同備選方案之間的差異要比較明顯，差異明顯的備選方案不可能所有的優(yōu)缺點(diǎn)都是一樣的。

如何選擇備選方案

面臨多個(gè)備選方案的選擇時(shí)，我們應(yīng)該按照優(yōu)先級(jí)選擇備選方案。即綜合當(dāng)前的業(yè)務(wù)發(fā)展情況、團(tuán)隊(duì)人員規(guī)模和技能、業(yè)務(wù)發(fā)展預(yù)測(cè)等因素，按照優(yōu)先級(jí)選擇，即架構(gòu)師綜合當(dāng)前的業(yè)務(wù)發(fā)展情況、團(tuán)隊(duì)人員規(guī)模和技能、業(yè)務(wù)發(fā)展預(yù)測(cè)等因素，將質(zhì)量屬性按照優(yōu)先級(jí)排序，首先挑選滿足第一優(yōu)先級(jí)的，如果方案都滿足，那就再看第二優(yōu)先級(jí)，以此類推。

有時(shí)候會(huì)出現(xiàn)兩個(gè)或者多個(gè)方案，每個(gè)質(zhì)量屬性的優(yōu)缺點(diǎn)都一樣的情況。理論上是可能的，但實(shí)際上不太可能。因?yàn)樵趥溥x方案設(shè)計(jì)時(shí)，不同的備選方案之間的差異要比較明顯，差異明顯的備選方案不可能所有的優(yōu)缺點(diǎn)都是一樣的。

實(shí)戰(zhàn)

備選方案評(píng)審會(huì)議

以之前講過的微博系統(tǒng)設(shè)計(jì)為例，針對(duì)提出的3個(gè)備選方案，架構(gòu)師組織了備選方案評(píng)審會(huì)議，參加的人有研發(fā)、測(cè)試、運(yùn)維和幾個(gè)核心業(yè)務(wù)的主管。

備選方案1：采用開源Kafka方案

• 業(yè)務(wù)主管意見： 傾向于采用Kafka方案，因?yàn)镵afka已經(jīng)比較成熟，各個(gè)業(yè)務(wù)團(tuán)隊(duì)或多或少都了解過Kafka。

• 中間件團(tuán)隊(duì)意見： 部分研發(fā)人員支持使用Kafka，因?yàn)槭褂肒afka能節(jié)省大量的開發(fā)投入；但部分人員認(rèn)為Kafka可能并不適合我們的業(yè)務(wù)場(chǎng)景，因?yàn)镵afka的設(shè)計(jì)目的是為了支撐大容量的日志消息傳輸，而我們的消息隊(duì)列是為了業(yè)務(wù)數(shù)據(jù)的可靠傳輸。

• 運(yùn)維代表意見： 提出強(qiáng)烈反對(duì)意見。首先，Kafka是Scala語言編寫的，運(yùn)維團(tuán)隊(duì)沒有維護(hù)Scala語言開發(fā)的系統(tǒng)的經(jīng)驗(yàn)，出問題后很難快速處理；其次，目前運(yùn)維團(tuán)隊(duì)已經(jīng)有一套成熟的運(yùn)維體系，包括部署、監(jiān)控、應(yīng)急等，使用Kafka無法融入這套體系，需要單獨(dú)投入運(yùn)維人力。

• 測(cè)試代表意見： 傾向于引入Kafka，因?yàn)镵afka比較成熟，無須太多測(cè)試投入。

備選方案2：集群 + MySQL存儲(chǔ)

• 中間件團(tuán)隊(duì)意見： 部分研發(fā)人員認(rèn)為這個(gè)方案比較簡(jiǎn)單，但部分研發(fā)人員認(rèn)為使用MySQL來存儲(chǔ)消息數(shù)據(jù)，性能肯定不如使用文件系統(tǒng)；并且有的研發(fā)人員擔(dān)心做這樣的方案是否會(huì)影響中間件團(tuán)隊(duì)的技術(shù)聲譽(yù)，看起來比較“土”、比較另類。

• 運(yùn)維代表意見： 贊同這個(gè)方案，因?yàn)檫@個(gè)方案可以融入到現(xiàn)有的運(yùn)維體系中，而且使用MySQL存儲(chǔ)數(shù)據(jù)，可靠性有保證，運(yùn)維團(tuán)隊(duì)也有豐富的MySQL運(yùn)維經(jīng)驗(yàn)。但運(yùn)維團(tuán)隊(duì)認(rèn)為這個(gè)方案的成本比較高，一個(gè)數(shù)據(jù)分組就需要4臺(tái)機(jī)器（2臺(tái)服務(wù)器 + 2臺(tái)數(shù)據(jù)庫(kù)）。

• 測(cè)試代表意見： 認(rèn)為這個(gè)方案測(cè)試人力投入較大，包括功能測(cè)試、性能

• 測(cè)試、可靠性測(cè)試等都需要大量地投入人力。

• 業(yè)務(wù)主管意見： 既不肯定也不否定，因?yàn)榉凑疾皇菢I(yè)務(wù)團(tuán)隊(duì)來投入人力來開發(fā)，系統(tǒng)維護(hù)也是中間件團(tuán)隊(duì)負(fù)責(zé)，對(duì)業(yè)務(wù)團(tuán)隊(duì)來說，只要保證消息隊(duì)列系統(tǒng)穩(wěn)定和可靠即可。

備選方案3：集群 + 自研存儲(chǔ)系統(tǒng)

• 中間件團(tuán)隊(duì)意見： 部分研發(fā)人員認(rèn)為這是一個(gè)很好的方案，既能夠展現(xiàn)中間件團(tuán)隊(duì)的技術(shù)實(shí)力，性能上相比MySQL也要高；但另外的研發(fā)人員認(rèn)為這個(gè)方案復(fù)雜度太高，按照目前的團(tuán)隊(duì)人力和技術(shù)實(shí)力，要做到穩(wěn)定可靠的存儲(chǔ)系統(tǒng)，需要耗時(shí)較長(zhǎng)的迭代，這個(gè)過程中消息隊(duì)列系統(tǒng)可能因?yàn)榇鎯?chǔ)出現(xiàn)嚴(yán)重問題，例如文件損壞導(dǎo)致丟失大量數(shù)據(jù)。

• 運(yùn)維代表意見： 不太贊成這個(gè)方案，因?yàn)檫\(yùn)維之前遇到過幾次類似的存儲(chǔ)系統(tǒng)故障導(dǎo)致數(shù)據(jù)丟失的問題，損失慘重。例如，MongoDB丟數(shù)據(jù)、Tokyo Tyrant丟數(shù)據(jù)無法恢復(fù)等。運(yùn)維團(tuán)隊(duì)并不相信目前的中間件團(tuán)隊(duì)的技術(shù)實(shí)力足以支撐自己研發(fā)一個(gè)存儲(chǔ)系統(tǒng)。

• 測(cè)試代表意見： 贊同運(yùn)維代表的意見，并且自研存儲(chǔ)系統(tǒng)的測(cè)試難度也很高，投入也很大。

• 業(yè)務(wù)主管意見： 持保留意見，因?yàn)閺臍v史經(jīng)驗(yàn)來看，新系統(tǒng)上線肯定有bug，而存儲(chǔ)系統(tǒng)出bug是最嚴(yán)重的，一旦出bug導(dǎo)致大量消息丟失，對(duì)系統(tǒng)的影響會(huì)嚴(yán)重。

以上備選方案的評(píng)審意見都有利有弊，因此在架構(gòu)設(shè)計(jì)流程的第3步：評(píng)估和選擇備選方案中，需要對(duì)這些意見進(jìn)行綜合考慮，權(quán)衡各自的利弊，并根據(jù)實(shí)際情況選擇最優(yōu)方案。在選擇備選方案時(shí)，應(yīng)該根據(jù)具體的場(chǎng)景和需求，選擇最適合自己的方案，而不是盲目追求某一種派別的方案。

針對(duì)3個(gè)備選方案的討論初步完成后，架構(gòu)師列出了3個(gè)方案的全方位評(píng)估表：

列出這個(gè)表格后，無法一眼看出具體哪個(gè)方案更合適，于是大家都把目光投向架構(gòu)師，決策的壓力現(xiàn)在集中在架構(gòu)師身上了。

架構(gòu)師經(jīng)過思考后，給出了最終選擇備選方案2，原因有：

• 排除備選方案1的主要原因是可運(yùn)維性，因?yàn)樵俪墒斓南到y(tǒng)，上線后都可能出問題，如果出問題無法快速解決，則無法滿足業(yè)務(wù)的需求；并且Kafka的主要設(shè)計(jì)目標(biāo)是高性能日志傳輸，而我們的消息隊(duì)列設(shè)計(jì)的主要目標(biāo)是業(yè)務(wù)消息的可靠傳輸。

• 排除備選方案3的主要原因是復(fù)雜度，目前團(tuán)隊(duì)技術(shù)實(shí)力和人員規(guī)模（總共6人，還有其他中間件系統(tǒng)需要開發(fā)和維護(hù)）無法支撐自研存儲(chǔ)系統(tǒng)（參考架構(gòu)設(shè)計(jì)原則2：簡(jiǎn)單原則）。

• 備選方案2的優(yōu)點(diǎn)就是復(fù)雜度不高，也可以很好地融入現(xiàn)有運(yùn)維體系，可靠性也有保障。

針對(duì)備選方案2的缺點(diǎn)，架構(gòu)師解釋是：

• 備選方案2的第一個(gè)缺點(diǎn)是性能，業(yè)務(wù)目前需要的性能并不是非常高，方案2能夠滿足，即使后面性能需求增加，方案2的數(shù)據(jù)分組方案也能夠平行擴(kuò)展進(jìn)行支撐（參考架構(gòu)設(shè)計(jì)原則3：演化原則）。

• 備選方案2的第二個(gè)缺點(diǎn)是成本，一個(gè)分組就需要4臺(tái)機(jī)器，支撐目前的業(yè)務(wù)需求可能需要12臺(tái)服務(wù)器，但實(shí)際上備機(jī)（包括服務(wù)器和數(shù)據(jù)庫(kù)）主要用作備份，可以和其他系統(tǒng)并行部署在同一臺(tái)機(jī)器上。

• 備選方案2的第三個(gè)缺點(diǎn)是技術(shù)上看起來并不很優(yōu)越，但我們的設(shè)計(jì)目的不是為了證明自己（參考架構(gòu)設(shè)計(jì)原則1：合適原則），而是更快更好地滿足業(yè)務(wù)需求。

最后，大家針對(duì)一些細(xì)節(jié)再次討論后，確定了選擇備選方案2。

通過微博這個(gè)案例我們可以看出，備選方案的選擇和很多因素相關(guān)，并不單單考慮性能高低、技術(shù)是否優(yōu)越這些純技術(shù)因素。業(yè)務(wù)的需求特點(diǎn)、運(yùn)維團(tuán)隊(duì)的經(jīng)驗(yàn)、已有的技術(shù)體系、團(tuán)隊(duì)人員的技術(shù)水平都會(huì)影響備選方案的選擇。因此，同樣是上述3個(gè)備選方案，有的團(tuán)隊(duì)會(huì)選擇引入Kafka（例如，很多創(chuàng)業(yè)公司的初創(chuàng)團(tuán)隊(duì)，人手不夠，需要快速上線支撐業(yè)務(wù)），有的會(huì)選擇自研存儲(chǔ)系統(tǒng)（例如，阿里開發(fā)了RocketMQ，人多力量大，業(yè)務(wù)復(fù)雜是主要原因）。

總結(jié)

備選方案評(píng)估和選擇是架構(gòu)師工作的一個(gè)重要方面。架構(gòu)師需要根據(jù)當(dāng)前業(yè)務(wù)的實(shí)際情況，對(duì)備選方案進(jìn)行全方位的評(píng)估，從各個(gè)質(zhì)量屬性的維度去評(píng)估每個(gè)方案，再綜合挑選適合當(dāng)時(shí)情況的最優(yōu)方案。在評(píng)估備選方案時(shí)，需要遵循架構(gòu)設(shè)計(jì)原則1“合適原則”和原則2“簡(jiǎn)單原則”，避免貪大求全，基本上某個(gè)質(zhì)量屬性能夠滿足一定時(shí)期內(nèi)業(yè)務(wù)發(fā)展就可以了。同時(shí)也要遵循原則3“演化原則”，避免過度設(shè)計(jì)，一步到位的想法。最后，在選擇備選方案時(shí)，需要按照質(zhì)量屬性的優(yōu)先級(jí)排序，逐個(gè)選擇最適合的方案。

總之，備選方案評(píng)估和選擇是一個(gè)全方位的過程，需要綜合考慮多方面的因素。只有在評(píng)估和選擇過程中遵循合適原則、簡(jiǎn)單原則和演化原則，并按照優(yōu)先級(jí)逐個(gè)選擇最適合的方案，才能設(shè)計(jì)出高質(zhì)量、可擴(kuò)展、易維護(hù)、高性能的系統(tǒng)架構(gòu)。

如果本文對(duì)你有幫助的話，歡迎點(diǎn)贊分享，這對(duì)我繼續(xù)分享&創(chuàng)作優(yōu)質(zhì)文章非常重要。感謝 ！