2022年軟件系統(tǒng)平臺(tái)架構(gòu)設(shè)計(jì)方案模板

1、軟件系統(tǒng)平臺(tái)架構(gòu)設(shè)計(jì)方案模板目錄 TOC o 1-5 h z 簡(jiǎn)介4備選方案模板41需求介紹42.2需求分析52. 15W52.21H52.38C62.3復(fù)雜度分析73. 1高可用73.2高性能83.3可擴(kuò)展82.4備選方案84. 1備選方案1:采用開(kāi)源的Kafka92. 4.2備選方案2：集群+MySQL存儲(chǔ)92. 4.3備選方案3：集群+自研存儲(chǔ)102.5備選方案評(píng)估115. 1備選方案1:采用開(kāi)源Kafka方案112.5.2備選方案2：集群+MySQL存儲(chǔ)122.5.3備選方案3：集群+自研存儲(chǔ)系統(tǒng)132.5.4 360 度環(huán)表14架構(gòu)設(shè)計(jì)模板151總體方案153.2架構(gòu)總覽153.3核

2、心流程163. 1消息發(fā)送流程163.3.2消息讀取流程163.4詳細(xì)設(shè)計(jì)164. 1高可用設(shè)計(jì)164.2高性能設(shè)計(jì)184.3可擴(kuò)展設(shè)計(jì)184.4安全設(shè)計(jì)184.5其它設(shè)計(jì)184.6部署方案183.5架構(gòu)演進(jìn)規(guī)劃19簡(jiǎn)介架構(gòu)設(shè)計(jì)中最重要的兩個(gè)文檔的模板和關(guān)鍵說(shuō)明。這個(gè)案例 文檔僅給出一些關(guān)鍵內(nèi)容供你參考，部分細(xì)節(jié)無(wú)法全面覆蓋或者 完全保證正確。二備選方案模板2.1需求介紹需求介紹主要描述需求的背景、目標(biāo)、范圍等隨著微博業(yè)務(wù)的不斷發(fā)展，業(yè)務(wù)上拆分的子系統(tǒng)越來(lái)越多， 目前系統(tǒng)間的調(diào)用都是同步調(diào)用，由此帶來(lái)幾個(gè)明顯的系統(tǒng)問(wèn)題:性能問(wèn)題：當(dāng)用戶發(fā)布了一條微博后，微博發(fā)布子系統(tǒng)需要 同步調(diào)用“統(tǒng)計(jì)子系統(tǒng)

3、”“審核子系統(tǒng)“獎(jiǎng)勵(lì)子系統(tǒng)等共8個(gè) 子系統(tǒng)，性能很低。耦合問(wèn)題：當(dāng)新增一個(gè)子系統(tǒng)時(shí)，例如如果要增加“廣告子 系統(tǒng)，那么廣告子系統(tǒng)需要開(kāi)發(fā)新的接口給微博發(fā)布子系統(tǒng)調(diào) 用。效率問(wèn)題：每個(gè)子系統(tǒng)提供的接口參數(shù)和實(shí)現(xiàn)都有一些細(xì)微 的差別，導(dǎo)致每次都需要重新設(shè)計(jì)接口和聯(lián)調(diào)接口，開(kāi)發(fā)團(tuán)隊(duì)和 測(cè)試團(tuán)隊(duì)花費(fèi)了許多重復(fù)工作量?；谝陨媳尘埃覀冃枰?消息隊(duì)列進(jìn)行系統(tǒng)解耦，將目前的同步調(diào)用改為異步通知。2.2需求分析需求分析主要全方位地描述需求相關(guān)的信息2. 2. 1 5W5W 指 Who、When、What、Why、Whereo Who：需求利益干 系人，包括開(kāi)發(fā)者、使用者、購(gòu)買者、決策者等。When：需求

4、使 用時(shí)間，包括季節(jié)、時(shí)間、里程碑等What：需求的產(chǎn)出是什么， 包括系統(tǒng)、數(shù)據(jù)、文件、開(kāi)發(fā)庫(kù)、平臺(tái)等。Where：需求的應(yīng)用場(chǎng) 景，包括國(guó)家、地點(diǎn)、環(huán)境等，例如測(cè)試平臺(tái)只會(huì)在測(cè)試環(huán)境使 用。Why：需求需要解決的問(wèn)題，通常和需求背景相關(guān)消息隊(duì)列的5W分析如下：Who：消息隊(duì)列系統(tǒng)主要是業(yè)務(wù)子系統(tǒng)來(lái)使用，子系統(tǒng)發(fā)送 消息或者接收消息。When：當(dāng)子系統(tǒng)需要發(fā)送異步通知的時(shí)候，需要使用消息隊(duì) 列系統(tǒng)。What：需要開(kāi)發(fā)消息隊(duì)列系統(tǒng)。Where：開(kāi)發(fā)環(huán)境、測(cè)試環(huán)境、生產(chǎn)環(huán)境都需要部署。Why：消息隊(duì)列系統(tǒng)將子系統(tǒng)解耦，將同步調(diào)用改為異步通 知。2. 2.2 1H這里的How不是設(shè)計(jì)方案也不是架構(gòu)方

5、案，而是關(guān)鍵業(yè)務(wù) 流程。消息隊(duì)列系統(tǒng)這部分內(nèi)容很簡(jiǎn)單，但有的業(yè)務(wù)系統(tǒng)1H就 是具體的用例了，有興趣的同學(xué)可以嘗試寫(xiě)寫(xiě)ATM機(jī)取款的業(yè) 務(wù)流程。如果是復(fù)雜的業(yè)務(wù)系統(tǒng)，這部分也可以獨(dú)立成“用例文 檔”消息隊(duì)列有兩大核心功能：業(yè)務(wù)子系統(tǒng)發(fā)送消息給消息隊(duì)列。業(yè)務(wù)子系統(tǒng)從消息隊(duì)列獲取消息。2. 2. 3 8C8C指的是8個(gè)約束和限制,即Constraints,包括性能 Performance 成本 Cost、時(shí)間 Time、可靠性 Reliab訂ity、 安全性 Security、合規(guī)性 Compliance 技術(shù)性 Technology 兼容性 Compatibility注：需求中涉及的性能、成本、可

6、靠性等僅僅是利益關(guān)聯(lián)方 提出的訴求，不一定準(zhǔn)確；如果經(jīng)過(guò)分析有的約束沒(méi)有必要，或 成本太高、難度太大，這些約束是可以調(diào)整的。性能：需要達(dá)到Kafka的性能水平。成本：參考XX公司的設(shè)計(jì)方案，不超過(guò)10臺(tái)服務(wù)器。時(shí)間：期望3個(gè)月內(nèi)上線第一個(gè)版本，在兩個(gè)業(yè)務(wù)嘗試使 用?？煽啃裕喊凑諛I(yè)務(wù)的要求，消息隊(duì)列系統(tǒng)的可靠性需要達(dá)到99. 99%o安全性：消息隊(duì)列系統(tǒng)僅在生產(chǎn)環(huán)境內(nèi)網(wǎng)使用，無(wú)需考慮網(wǎng) 絡(luò)安全；如消息中有敏感信息，消息發(fā)送方需要自行進(jìn)行加密, 消息隊(duì)列系統(tǒng)本身不考慮通用的加密。合規(guī)性：消息隊(duì)列系統(tǒng)需要按照公司目前的DevOps規(guī)范進(jìn) 行開(kāi)發(fā)。技術(shù)性：目前團(tuán)隊(duì)主要研發(fā)人員是Java,最好用Java

7、開(kāi) 發(fā)。兼容性：之前沒(méi)有類似系統(tǒng)，無(wú)需考慮兼容性。2.3復(fù)雜度分析分析需求的復(fù)雜度，復(fù)雜度常見(jiàn)的有高可用、高性能、可 擴(kuò)展等，具體分析方法子主題注：文檔的內(nèi)容省略了分析過(guò)程，實(shí)際操作的時(shí)候每 個(gè)約束和限制都要有詳細(xì)的邏輯推導(dǎo)，避免完全拍腦袋式?jīng)Q策。2. 3.1高可用對(duì)于微博子系統(tǒng)來(lái)說(shuō)，如果消息丟了，導(dǎo)致沒(méi)有審核，然后 觸犯了國(guó)家法律法規(guī)，則是非常嚴(yán)重的事情；對(duì)于等級(jí)子系統(tǒng)來(lái) 說(shuō)，如果用戶達(dá)到相應(yīng)等級(jí)后，系統(tǒng)沒(méi)有給他獎(jiǎng)品和專屬服務(wù), 則VIP用戶會(huì)很不滿意，導(dǎo)致用戶流失從而損失收入，雖然也 比較關(guān)鍵，但沒(méi)有審核子系統(tǒng)丟消息那么嚴(yán)重。綜合來(lái)看，消息 隊(duì)列需要高可用性，包括消息寫(xiě)入、消息存儲(chǔ)、消息讀

8、取都需要 保證高可用性。2. 3.2高性能微博系統(tǒng)用戶每天發(fā)送1000萬(wàn)條微博，那么微博子系統(tǒng)一 天會(huì)產(chǎn)生1000萬(wàn)條消息，平均一條消息有10個(gè)子系統(tǒng)讀取， 那么其他子系統(tǒng)讀取的消息大約是1億次。將數(shù)據(jù)按照秒來(lái)計(jì) 算，一天內(nèi)平均每秒寫(xiě)入消息數(shù)為115條，每秒讀取的消息數(shù) 是1150條；再考慮系統(tǒng)的讀寫(xiě)并不是完全平均的，設(shè)計(jì)的目標(biāo) 應(yīng)該以峰值來(lái)計(jì)算。峰值一般取平均值的3倍，那么消息隊(duì)列 系統(tǒng)的TPS是345, QPS是3450,考慮一定的性能余量。由于 現(xiàn)在的基數(shù)較低，為了預(yù)留一定的系統(tǒng)容量應(yīng)對(duì)后續(xù)業(yè)務(wù)的發(fā)展, 我們將設(shè)計(jì)目標(biāo)設(shè)定為峰值的4倍，因此最終的性能要求是： TPS 為 1380, QP

9、S 為 13800o TPS 為 1380 并不高，但 QPS 為 13800已經(jīng)比較高了，因此高性能讀取是復(fù)雜度之一。2. 3.3可擴(kuò)展消息隊(duì)列的功能很明確，基本無(wú)須擴(kuò)展，因此可擴(kuò)展性不是 這個(gè)消息隊(duì)列的關(guān)鍵復(fù)雜度。2.4備選方案?jìng)溥x方案設(shè)計(jì)，至少3個(gè)備選方案，每個(gè)備選方案需要描 述關(guān)鍵的實(shí)現(xiàn)，無(wú)須描述具體的實(shí)現(xiàn)細(xì)節(jié)。此處省略具體方案描2. 4.1備選方案1：采用開(kāi)源的KafkaKafka是成熟的開(kāi)源消息隊(duì)列方案，功能強(qiáng)大，性能非常高， 而且已經(jīng)比較成熟，很多大公司都在使用。2. 4.2備選方案2：集群+ MySQL存儲(chǔ)首先考慮單服務(wù)器高性能。高性能消息讀取屬于“計(jì)算高可 用”的范疇，單服務(wù)

10、器高性能備選方案有很多種。考慮到團(tuán)隊(duì)的 開(kāi)發(fā)語(yǔ)言是Java,雖然有人覺(jué)得C/C+語(yǔ)言更加適合寫(xiě)髙性能 的中間件系統(tǒng)，但架構(gòu)師綜合來(lái)看，認(rèn)為無(wú)須為了語(yǔ)言的性能優(yōu) 勢(shì)而讓整個(gè)團(tuán)隊(duì)切換語(yǔ)言，消息隊(duì)列系統(tǒng)繼續(xù)用Java開(kāi)發(fā)。由 于Netty是Java領(lǐng)域成熟的髙性能網(wǎng)絡(luò)庫(kù)，因此架構(gòu)師選擇 基于Netty開(kāi)發(fā)消息隊(duì)列系統(tǒng)。由于系統(tǒng)設(shè)計(jì)的QPS是13800,即使單機(jī)采用Netty來(lái) 構(gòu)建高性能系統(tǒng)，單臺(tái)服務(wù)器支撐這么高的QPS還是有很大風(fēng) 險(xiǎn)的，因此架構(gòu)師選擇采取集群方式來(lái)滿足高性能消息讀取，集 群的負(fù)載均衡算法采用簡(jiǎn)單的輪詢即可。同理，“高可用寫(xiě)入”和“高性能讀取” 一樣，可以采取集群 的方式來(lái)滿足。因

11、為消息只要寫(xiě)入集群中一臺(tái)服務(wù)器就算成功寫(xiě) 入，因此“高可用寫(xiě)入”的集群分配算法和“高性能讀取”也一 樣采用輪詢，即正常情況下，客戶端將消息依次寫(xiě)入不同的服務(wù) 器；某臺(tái)服務(wù)器異常的情況下，客戶端直接將消息寫(xiě)入下一臺(tái)正 常的服務(wù)器即可。整個(gè)系統(tǒng)中最復(fù)雜的是“高可用存儲(chǔ)和“高可用讀取”，“高可用存儲(chǔ)”要求已經(jīng)寫(xiě)入的消息在單臺(tái)服務(wù)器宕機(jī)的情況下 不丟失；“高可用讀取”要求已經(jīng)寫(xiě)入的消息在單臺(tái)服務(wù)器宕機(jī) 的情況下可以繼續(xù)讀取。架構(gòu)師第一時(shí)間想到的就是可以利用 MySQL的主備復(fù)制功能來(lái)達(dá)到“高可用存儲(chǔ)“的目的，通過(guò)服務(wù) 器的主備方案來(lái)達(dá)到“高可用讀取”的目的。具體方案：采用數(shù)據(jù)分散集群的架構(gòu)，集群中的服

12、務(wù)器進(jìn)行分組，每個(gè) 分組存儲(chǔ)一部分消息數(shù)據(jù)。每個(gè)分組包含一臺(tái)主MySQL和一臺(tái)備MySQL,分組內(nèi)主備 數(shù)據(jù)復(fù)制，分組間數(shù)據(jù)不同步。正常情況下，分組內(nèi)的主服務(wù)器對(duì)外提供消息寫(xiě)入和消息讀 取服務(wù)，備服務(wù)器不對(duì)外提供服務(wù)；主服務(wù)器宕機(jī)的情況下，備 服務(wù)器對(duì)外提供消息讀取的服務(wù)。客戶端采取輪詢的策略寫(xiě)入和讀取消息。2. 4.3備選方案3：集群+自研存儲(chǔ)在備選方案2的基礎(chǔ)上，將MySQL存儲(chǔ)替換為自研實(shí)現(xiàn) 存儲(chǔ)方案，因?yàn)镸ySQL的關(guān)系型數(shù)據(jù)庫(kù)的特點(diǎn)并不是很契合消 息隊(duì)列的數(shù)據(jù)特點(diǎn)，參考Kafka的做法，可以自己實(shí)現(xiàn)一套文 件存儲(chǔ)和復(fù)制方案（此處省略具體的方案描述，實(shí)際設(shè)計(jì)時(shí)需要 給出方案）?？梢钥闯?/p>

13、，高性能消息讀取單機(jī)系統(tǒng)設(shè)計(jì)這部分時(shí)并沒(méi)有多 個(gè)備選方案可選，備選方案2和備選方案3都采取基于Netty 的網(wǎng)絡(luò)庫(kù)，用Java語(yǔ)言開(kāi)發(fā)，原因就在于團(tuán)隊(duì)的Java背景約 束了備選的范圍。通常情況下，成熟的團(tuán)隊(duì)不會(huì)輕易改變技術(shù)棧， 反而是新成立的技術(shù)團(tuán)隊(duì)更加傾向于采用新技術(shù)。上面簡(jiǎn)單地給出了 3個(gè)備選方案用來(lái)示范如何操作，實(shí)踐 中要比上述方案復(fù)雜一些。架構(gòu)師的技術(shù)儲(chǔ)備越豐富、經(jīng)驗(yàn)越多， 備選方案也會(huì)更多，從而才能更好地設(shè)計(jì)備選方案。例如，開(kāi)源 方案選擇可能就包括Kafka、ActiveMQ、RabbitMQ；集群方案的 存儲(chǔ)既可以考慮用MySQL,也可以考慮用HBase,還可以考慮用 Redis與

14、MySQL結(jié)合等；自研文件系統(tǒng)也可以有多個(gè)，可以參 考Kafka,也可以參考LevelDB,還可以參考HBase等。限于 篇幅，這里就不一一展開(kāi)了。2.5備選方案評(píng)估2. 5.1備選方案1:采用開(kāi)源Kafka方案業(yè)務(wù)主管傾向于采用Kafka方案，因?yàn)镵afka已經(jīng)比較 成熟，各個(gè)業(yè)務(wù)團(tuán)隊(duì)或多或少都了解過(guò)Kafkao中間件團(tuán)隊(duì)部分研發(fā)人員也支持使用Kafka,因?yàn)槭褂?Kafka能節(jié)省大量的開(kāi)發(fā)投入；但部分人員認(rèn)為Kafka可能并 不適合我們的業(yè)務(wù)場(chǎng)景，因?yàn)镵afka的設(shè)計(jì)目的是為了支撐大 容量的日志消息傳輸，而我們的消息隊(duì)列是為了業(yè)務(wù)數(shù)據(jù)的可靠 傳輸。運(yùn)維代表提出了強(qiáng)烈的反對(duì)意見(jiàn)：首先,Kaf

15、ka是Scala語(yǔ) 言編寫(xiě)的，運(yùn)維團(tuán)隊(duì)沒(méi)有維護(hù)Scala語(yǔ)言開(kāi)發(fā)的系統(tǒng)的經(jīng)驗(yàn)， 出問(wèn)題后很難快速處理；其次，目前運(yùn)維團(tuán)隊(duì)已經(jīng)有一套成熟的 運(yùn)維體系，包括部署、監(jiān)控、應(yīng)急等，使用Kafka無(wú)法融入這 套體系，需要單獨(dú)投入運(yùn)維人力。測(cè)試代表也傾向于引入Kafka,因?yàn)镵afka比較成熟，無(wú) 須太多測(cè)試投入。2. 5. 2備選方案2：集群+ MySQL存儲(chǔ)中間件團(tuán)隊(duì)的研發(fā)人員認(rèn)為這個(gè)方案比較簡(jiǎn)單，但部分研發(fā) 人員對(duì)于這個(gè)方案的性能持懷疑態(tài)度，畢竟使用MySQL來(lái)存儲(chǔ) 消息數(shù)據(jù)，性能肯定不如使用文件系統(tǒng)；并且有的研發(fā)人員擔(dān)心 做這樣的方案是否會(huì)影響中間件團(tuán)隊(duì)的技術(shù)聲譽(yù)，畢竟用MySQL 來(lái)做消息隊(duì)列，

16、看起來(lái)比較“土”、比較另類。運(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ù)主管對(duì)這個(gè)方案既不肯定也不否定，因?yàn)榉凑疾皇菢I(yè) 務(wù)團(tuán)隊(duì)來(lái)投入人力來(lái)開(kāi)發(fā)，系統(tǒng)維護(hù)也是中間件團(tuán)隊(duì)負(fù)責(zé)，對(duì)業(yè) 務(wù)團(tuán)隊(duì)來(lái)說(shuō)，只要保證消息隊(duì)列系統(tǒng)穩(wěn)定和可靠即可。2. 5.3備選方案3：集群+自研存儲(chǔ)系統(tǒng)中間件團(tuán)隊(duì)部分研發(fā)人員認(rèn)為這是一

17、個(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è)過(guò)程中消息隊(duì)列系統(tǒng)可能因?yàn)榇鎯?chǔ)出現(xiàn)嚴(yán)重問(wèn)題，例如文件 損壞導(dǎo)致丟失大量數(shù)據(jù)。運(yùn)維代表不太贊成這個(gè)方案，因?yàn)檫\(yùn)維之前遇到過(guò)幾次類似 的存儲(chǔ)系統(tǒng)故障導(dǎo)致數(shù)據(jù)丟失的問(wèn)題，損失慘重。例如,MongoDB 丟數(shù)據(jù)、Tokyo Tyrant丟數(shù)據(jù)無(wú)法恢復(fù)等。運(yùn)維團(tuán)隊(duì)并不相信 目前的中間件團(tuán)隊(duì)的技術(shù)實(shí)力足以支撐自己研發(fā)一個(gè)存儲(chǔ)系統(tǒng) （這讓中間件團(tuán)隊(duì)的人員感覺(jué)有點(diǎn)不爽）。測(cè)試代表贊同運(yùn)維代表的意見(jiàn)，并且自研存儲(chǔ)

18、系統(tǒng)的測(cè)試難 度也很高，投入也很大。業(yè)務(wù)主管對(duì)自研存儲(chǔ)系統(tǒng)也持保留意見(jiàn)，因?yàn)閺臍v史經(jīng)驗(yàn)來(lái) 看，新系統(tǒng)上線肯定有bug,而存儲(chǔ)系統(tǒng)出bug是最嚴(yán)重的， 一旦出bug導(dǎo)致大量消息丟失，對(duì)系統(tǒng)的影響會(huì)嚴(yán)重。2. 5.4 360度環(huán)表最終選擇備選方案2：排除備選方案1的主要原因是可運(yùn)維性，因?yàn)樵俪墒斓南?統(tǒng)，上線后都可能出問(wèn)題，如果出問(wèn)題無(wú)法快速解決，則無(wú)法滿 足業(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)需要開(kāi)發(fā)和維護(hù)） 無(wú)法支撐自研存儲(chǔ)系統(tǒng)

19、（參考架構(gòu)設(shè)計(jì)原則2：簡(jiǎn)單原則）。備選方案2的優(yōu)點(diǎn)就是復(fù)雜度不高，也可以很好地融入現(xiàn) 有運(yùn)維體系，可靠性也有保障。備選方案2的缺點(diǎn)：備選方案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ù)上看起來(lái)并不很優(yōu)越，但 我們的設(shè)計(jì)目的不是為了證明自己（參考架構(gòu)設(shè)計(jì)原則1

20、：合適 原則），而是更快更好地滿足業(yè)務(wù)需求。三架構(gòu)設(shè)計(jì)模板備選方案評(píng)估后會(huì)選擇一個(gè)方案落地實(shí)施，架構(gòu)設(shè)計(jì)文檔 就是用來(lái)詳細(xì)描述細(xì)化方案的3.1總體方案總體方案需要從整體上描述方案的結(jié)構(gòu)，其核心內(nèi)容就是 架構(gòu)圖，以及針對(duì)架構(gòu)圖的描述，包括模塊或者子系統(tǒng)的職責(zé)描 述、核心流程3.2架構(gòu)總覽架構(gòu)總覽給出架構(gòu)圖以及架構(gòu)的描述架構(gòu)關(guān)鍵設(shè)計(jì)點(diǎn)：采用數(shù)據(jù)分散集群的架構(gòu)，集群中的服務(wù)器進(jìn)行分組，每個(gè) 分組存儲(chǔ)一部分消息數(shù)據(jù)。每個(gè)分組包含一臺(tái)主MySQL和一臺(tái)備MySQL,分組內(nèi)主備 數(shù)據(jù)復(fù)制，分組間數(shù)據(jù)不同步。正常情況下，分組內(nèi)的主服務(wù)器對(duì)外提供消息寫(xiě)入和消息讀 取服務(wù)，備服務(wù)器不對(duì)外提供服務(wù)；主服務(wù)器宕機(jī)的

21、情況下，備 服務(wù)器對(duì)外提供消息讀取的服務(wù)。客戶端采取輪詢的策略寫(xiě)入和讀取消息。3. 3核心流程3. 3.1消息發(fā)送流程此處省略流程描述3. 3.2消息讀取流程此處省略流程描述3.4詳細(xì)設(shè)計(jì)詳細(xì)設(shè)計(jì)需要描述具體的實(shí)現(xiàn)細(xì)節(jié)，跟隨實(shí)際情況增刪3. 4.1高可用設(shè)計(jì)消息發(fā)送可靠性：業(yè)務(wù)服務(wù)器中嵌入消息隊(duì)列系統(tǒng)提供的SDK, SDK支持輪詢 發(fā)送消息，當(dāng)某個(gè)分組的主服務(wù)器無(wú)法發(fā)送消息時(shí)，SDK挑選下 一個(gè)分組主服務(wù)器重發(fā)消息，依次嘗試所有主服務(wù)器直到發(fā)送成 功；如果全部主服務(wù)器都無(wú)法發(fā)送，SDK可以緩存消息，也可以 直接丟棄消息，具體策略可以在啟動(dòng)SDK的時(shí)候通過(guò)配置指定。如果SDK緩存了一些消息未發(fā)送

22、，此時(shí)恰好業(yè)務(wù)服務(wù)器又 重啟，則所有緩存的消息將永久丟失，這種情況SDK不做處理， 業(yè)務(wù)方需要針對(duì)某些非常關(guān)鍵的消息自己實(shí)現(xiàn)永久存儲(chǔ)的功能。消息存儲(chǔ)可靠性：消息存儲(chǔ)在MySQL中，每個(gè)分組有一主一備兩臺(tái)MySQL服 務(wù)器，MySQL服務(wù)器之間復(fù)制消息以保證消息存儲(chǔ)高可用。如果 主備間出現(xiàn)復(fù)制延遲，恰好此時(shí)MySQL主服務(wù)器宕機(jī)導(dǎo)致數(shù)據(jù) 無(wú)法恢復(fù)，則部分消息會(huì)永久丟失，這種情況不做針對(duì)性設(shè)計(jì), DBA需要對(duì)主備間的復(fù)制延遲進(jìn)行監(jiān)控，當(dāng)復(fù)制延遲超過(guò)30秒 的時(shí)候需要及時(shí)告警并進(jìn)行處理。消息讀取可靠性每個(gè)分組有一主一備兩臺(tái)服務(wù)器，主服務(wù)器支持發(fā)送和讀取 消息，備服務(wù)器只支持讀取消息，當(dāng)主服務(wù)器正常的時(shí)候備服務(wù) 器不對(duì)外提供服務(wù)，只有備服務(wù)器判斷主服務(wù)器故障的時(shí)候才對(duì) 外提供消息讀取服務(wù)。每個(gè)分組有一主一備兩臺(tái)服務(wù)器，主服務(wù)器支持發(fā)送和讀取 消