?[[417292]]?

本文轉(zhuǎn)載自微信公眾號(hào)「Java補(bǔ)習(xí)課」，作者九靈。轉(zhuǎn)載本文請(qǐng)聯(lián)系Java補(bǔ)習(xí)課公眾號(hào)。

淚目，不堪回首!

博主畢業(yè)4年了，最近秋招開始了，每次回想起自己的秋招，都感覺(jué)到當(dāng)時(shí)自己特別的可惜(菜是原罪),自己當(dāng)時(shí)簡(jiǎn)歷上面的項(xiàng)目，只有一個(gè) 農(nóng)資電商平臺(tái),當(dāng)時(shí)的秒殺系統(tǒng)還沒(méi)有那么普及(簡(jiǎn)歷人均秒殺系統(tǒng))。

第一次微眾面試

當(dāng)年自己的八股文背的其實(shí)還可以，但是自己的項(xiàng)目就只是一個(gè)單機(jī)系統(tǒng)，分布式?微服務(wù)?什么玩意?,還記得當(dāng)時(shí)微眾面試，是二面，在一個(gè)酒店房間，面試官笑嘻嘻的看著我，說(shuō)讓我先畫一下我項(xiàng)目里面的農(nóng)資電商平臺(tái)， 我腦子嗡嗡叫，啥?咋畫， 就一個(gè)安卓系統(tǒng)，一個(gè)前端頁(yè)面，和一個(gè)后臺(tái)系統(tǒng)?

大概長(zhǎng)這樣子

??

我擦，這也太簡(jiǎn)單了吧， 我是不是該畫復(fù)雜一點(diǎn)? 或者說(shuō)，我這個(gè)能叫架構(gòu)嗎?就這樣，猶豫之間，毛線都沒(méi)有畫出來(lái)... 我記得當(dāng)時(shí)好像畫了個(gè)這樣子的玩意。。毫無(wú)意外的，嗝屁了～

這玩意有點(diǎn)四不像，不說(shuō)了，丟臉～

??

第二次微眾面試

第二次微眾面試，畢業(yè)有快一年了，抱著試一下的心態(tài)，找了個(gè)師姐內(nèi)推, 那時(shí)候我在干啥呢，在搞爬蟲。公司離微眾比較近，就在金蝶那邊,下班了溜過(guò)去，跟面試官吧啦了一會(huì)八股文，好家伙，沒(méi)一會(huì)就掏出了一張紙：

來(lái)畫一下你們現(xiàn)在這個(gè)爬蟲系統(tǒng)的架構(gòu)圖!

當(dāng)時(shí)系統(tǒng)的部署架構(gòu)長(zhǎng)這樣吧， 比上面的看起來(lái)還簡(jiǎn)單一點(diǎn)。

??

但是，我就是畫不出手啊!!!心里想著太簡(jiǎn)單了啊!!這玩意能叫架構(gòu)嗎?

攤牌了， 我不會(huì)畫!

現(xiàn)在想起來(lái)，真的太憋屈了，年輕啊!那如果現(xiàn)在來(lái)回頭看的話，能怎么畫呢?

單體系統(tǒng)的部署架構(gòu)圖

??

爬蟲系統(tǒng)的分層架構(gòu)圖

??

爬蟲系統(tǒng)的業(yè)務(wù)架構(gòu)

??

架構(gòu)圖

從上面的各個(gè)方向描述架構(gòu)來(lái)看，其實(shí)即使是單體系統(tǒng) 也能夠畫出不一般的架構(gòu)圖!(為啥當(dāng)時(shí)我就不會(huì)呢!)

最近在看架構(gòu)相關(guān)的內(nèi)容(華仔的課)，在4+1 視圖里面，從多方面描述了我們的系統(tǒng)，可以參考下面的描述，

??

你的秒殺系統(tǒng)，架構(gòu)是怎么樣的?

單體系統(tǒng)

不管你們簡(jiǎn)歷吹的多牛逼，我猜你們的服務(wù)，大部分都是長(zhǎng)這個(gè)樣子的，猜對(duì)的話點(diǎn)個(gè)關(guān)注, 只有瀏覽器是分布式的。

??

那我該如何去描述我的單體系統(tǒng)呢?

架構(gòu)設(shè)計(jì)的三大原則：

• 簡(jiǎn)單原則
• 合適原則
• 演進(jìn)原則

每一條原則都符合我們大學(xué)做的秒殺系統(tǒng)啊!!

簡(jiǎn)單原則：一個(gè)系統(tǒng)就可以滿足我們秒殺服務(wù)的所有動(dòng)作，沒(méi)有太多的中間件依賴

合適原則：在我們的實(shí)踐項(xiàng)目中，單體系統(tǒng)是最適合不過(guò)的了。(主要是沒(méi)錢啊!拆分服務(wù)，引入中間件，部署集群，都得錢啊!)

演進(jìn)原則：這個(gè)比較好理解，沒(méi)有什么系統(tǒng)架構(gòu)是一出生就定下來(lái)的，是隨著時(shí)間，業(yè)務(wù)需求，不斷演變出來(lái)的。

總結(jié)：

我們架構(gòu)的優(yōu)勢(shì)： 成本低，系統(tǒng)復(fù)雜度低，維護(hù)成本低，快速定位問(wèn)題

劣勢(shì)：穩(wěn)定性差，并發(fā)量低，擴(kuò)展性弱等

在梳理架構(gòu)時(shí)，每個(gè)方案都有他的優(yōu)勢(shì)和缺點(diǎn)，所以需要了解你目前方案的優(yōu)缺點(diǎn)。才能更好的向面試官展示你的系統(tǒng)!

服務(wù)拆分

好家伙，參加了個(gè)科創(chuàng)比賽，資金到位了，能買更多機(jī)器了，那不得將服務(wù)優(yōu)化一下，拆分個(gè)微服務(wù)系統(tǒng)出來(lái)!

??

在這個(gè)服務(wù)拆分的架構(gòu)中，我們做了哪些動(dòng)作?

• 靜態(tài)資源隔離(CDN加速)
• 代理服務(wù)器(Nginx)
• 服務(wù)拆分，應(yīng)用獨(dú)立部署
• 服務(wù)rpc通信 (rpc框架 & 注冊(cè)中心)

1、前后端分離

在單體系統(tǒng)中，我們的靜態(tài)資源(Html,JS,CSS 和 IMG)可能都是通過(guò)我們服務(wù)端進(jìn)行返回，存在的問(wèn)題是：

前端代碼維護(hù)成本比較高(全棧開發(fā)成本也高)

前端代碼發(fā)布，需要整個(gè)系統(tǒng)進(jìn)行發(fā)布

服務(wù)器帶寬，請(qǐng)求資源占用等

那么通過(guò)前后端分離所帶來(lái)的好處就很明顯了：

代碼獨(dú)立維護(hù)(低耦合),發(fā)布成本低(高效率)

前后端通過(guò)接口交互動(dòng)態(tài)數(shù)據(jù)

CDN資源訪問(wèn)加速,減少后端服務(wù)壓力(高性能)

2、反向代理

反向代理的作用比較明顯， 由于我們服務(wù)拆分成多個(gè)，那么我們和前端進(jìn)行交互時(shí)，需要提供一個(gè)通用的入口。而這個(gè)入口，就是我們的反向代理服務(wù)器(Nginx)。例如：服務(wù)域名：https://www.jiuling.com ，根據(jù)restful規(guī)范，我們可以通過(guò) https://www.jiuling.com/user/1.0/login 將請(qǐng)求轉(zhuǎn)發(fā)到 用戶服務(wù)的登錄接口中。

3.進(jìn)程間通信

隨著服務(wù)的拆分，在部分功能的實(shí)現(xiàn)上，就會(huì)涉及到服務(wù)間相互調(diào)用的情況，例如：

??

在常見的實(shí)現(xiàn)方案上，我們會(huì)采用 注冊(cè)中心 和 RPC框架,來(lái)實(shí)現(xiàn)這一能力。而我們比較常用的實(shí)現(xiàn)方案就是 zookeeper & dubbo。

??

為什么要使用 RPC 框架?

當(dāng)我們提到使用 RPC框架 的時(shí)候，是否有去思考過(guò)，為什么要使用 RPC框架? 每個(gè)服務(wù)提供 RESTful 接口，不是也能夠完成服務(wù)間通信嗎?

這里就需要進(jìn)行對(duì)比 RPC 和 RESTful 的區(qū)別了:

• 數(shù)據(jù)報(bào)文小&傳輸效率快：RPC簡(jiǎn)化了傳輸協(xié)議中一些必要的頭部信息，從而加快了傳輸效率。
• 開發(fā)成本低：例如 Dubbo框架，封裝好了服務(wù)間調(diào)用的邏輯(如：反射，建連和超時(shí)控制等)，只需要開發(fā)相應(yīng)的接口和數(shù)據(jù)模型即可。
• 服務(wù)治理: 在分布式場(chǎng)景下，我們的服務(wù)提供者不止一臺(tái)，那么就涉及到 服務(wù)健康，負(fù)載均衡和服務(wù)流控等情況需要處理，而這部分能力在rpc & 注冊(cè)中心 的架構(gòu)下，都已經(jīng)滿足了。

說(shuō)完優(yōu)點(diǎn)后，再來(lái)分析一下，RPC的缺點(diǎn):

• 耦合性強(qiáng)：相較于 RESTful而言，RPC 框架在跨語(yǔ)言的場(chǎng)景下實(shí)現(xiàn)比較困難。并且版本依賴比較強(qiáng)。服務(wù)脫離了當(dāng)前內(nèi)網(wǎng)環(huán)境后，無(wú)法正常提供服務(wù),遷移成本高。
• 內(nèi)網(wǎng)調(diào)用：RPC更適合內(nèi)網(wǎng)傳輸，在公網(wǎng)環(huán)境下，顯得沒(méi)那么安全。

分布式微服務(wù)

在上一個(gè)版本的服務(wù)拆分中, 我們根據(jù)不同的業(yè)務(wù)邊界，功能職責(zé),劃分出了多個(gè)子系統(tǒng),而針對(duì)不同的系統(tǒng)，他所承受的負(fù)載壓力是不一樣的，例如：訂單服務(wù)的每個(gè)請(qǐng)求處理耗時(shí)較長(zhǎng)(其他服務(wù)壓力不大)，為了挺升我們的下單量，我們可以只擴(kuò)容訂單服務(wù)即可,這就是我們?cè)诜?wù)拆分所帶來(lái)的收益，性能使用率提升!

??

從上面的圖我們可以看到，有些服務(wù)出現(xiàn)了不同的重影，每一個(gè)方塊,可以理解為一臺(tái)機(jī)器,在這個(gè)架構(gòu)中， 為了保證我們的下單成功率，以及下單量，我們主要將服務(wù)器集中在了訂單服務(wù)。

除此之前，再來(lái)看看我們的中間件集群部署：

• mysql 主從架構(gòu)：讀寫分離，減輕主庫(kù)壓力，確保數(shù)據(jù)能正常寫入，保障訂單數(shù)據(jù)落庫(kù).
• zookeeper 主從架構(gòu)：保障注冊(cè)中心可用，避免導(dǎo)致全鏈路雪崩。
• redis 哨兵集群：避免redis宕機(jī)導(dǎo)致大流量直接打到數(shù)據(jù)庫(kù)中。

小結(jié)

到這里為止，一般我們自己開發(fā)的系統(tǒng)，也就基本完成了整個(gè)秒殺系統(tǒng)的演進(jìn)了?？赡艽蠡镆恢庇袀€(gè)疑問(wèn)，為什么少了我們最熟悉的MQ呢?

在整個(gè)調(diào)用鏈路中，我都是以同步調(diào)用的方式去講述這一個(gè)秒殺系統(tǒng)的架構(gòu),因?yàn)檫@個(gè)已經(jīng)滿足我們當(dāng)前的流量訴求了，在架構(gòu)設(shè)計(jì)的原則里面，提到的，合適原則，和演進(jìn)原則。在當(dāng)前滿足流量需求的情況下，我們需要先思考引入消息中間件，帶來(lái)的問(wèn)題是什么?解決的問(wèn)題又是什么?在權(quán)衡利弊后，才是我們決策是否要使用這個(gè)方案的時(shí)候。

高性能

在上述架構(gòu)演進(jìn)的過(guò)程中，我們通過(guò)服務(wù)拆分，垂直擴(kuò)容，分布式部署等方式,提升了我們架構(gòu)的性能和穩(wěn)定性,對(duì)于我們自研階段的架構(gòu)演進(jìn)已經(jīng)是足夠滿足我們的流量訴求了，但如果我們想繼續(xù)優(yōu)化我們的系統(tǒng)，提升服務(wù)性能，可以從以下幾個(gè)方面進(jìn)行優(yōu)化：

• 資源預(yù)熱
• 緩存預(yù)熱
• 異步調(diào)用

1、資源預(yù)熱

在上面的服務(wù)拆分階段, 我們就提到了資源動(dòng)靜分離, 這里的靜態(tài)資源包括：html,js,css,img 等。我們活動(dòng)階段，可以通過(guò)后臺(tái)管理系統(tǒng)，將商品服務(wù)中的活動(dòng)的靜態(tài)資源預(yù)熱到CDN，加速資源的訪問(wèn)。

資源預(yù)熱： 通過(guò)預(yù)先將資源加載到CDN
回源：CDN找不到資源后，會(huì)觸發(fā)源站（商品服務(wù)）調(diào)用，進(jìn)行查詢對(duì)應(yīng)資源，如果源站存在該資源，則會(huì)返回到CDN中進(jìn)行緩存。
OSS： 實(shí)際存儲(chǔ)靜態(tài)資源的服務(wù)（可參考阿里云OSS）

??

上面有反復(fù)提到，引入一個(gè)技術(shù)的時(shí)候，需要同時(shí)考慮它所帶來(lái)的利和弊，那么 CDN的風(fēng)險(xiǎn)是什么呢?

• 成本 : 比較直接，就是得多花錢!
• 帶寬 ：在大流量的訪問(wèn)下， CDN 是否能支撐那么多的帶寬，每個(gè)服務(wù)器能支撐的流量是有限的，需要考慮CDN是否能支撐業(yè)務(wù)的訪問(wèn)量。
• CDN命中率: 在CDN命中率低的情況下，比如活動(dòng)圖片,每一個(gè)小時(shí)都會(huì)發(fā)生改變，那么每次圖片的替換，都會(huì)觸發(fā)回源操作,這時(shí)候的資源訪問(wèn)效率反而有所下降。

2、緩存預(yù)熱

與上面的靜態(tài)資源加速相對(duì)比，動(dòng)態(tài)數(shù)據(jù)則需要通過(guò)緩存進(jìn)行性能上的優(yōu)化，老生常談，為什么redis 那么快?

單線程(redis的性能瓶頸并不在這，所以這個(gè)不算優(yōu)勢(shì))

• 多路I/O復(fù)用模型
• 數(shù)據(jù)結(jié)構(gòu)簡(jiǎn)單
• 基于內(nèi)存操作

??

引入 redis 帶來(lái)的風(fēng)險(xiǎn)主要有:

• reids 宕機(jī)：?jiǎn)螜C(jī)部署的情況下，會(huì)導(dǎo)致大量的服務(wù)調(diào)用超時(shí)，最終引起服務(wù)雪崩?？赏ㄟ^(guò)Sentinel集群優(yōu)化。
• 緩存擊穿：大流量下，緩存MISS和緩存過(guò)期等情況，會(huì)導(dǎo)致請(qǐng)求穿透到數(shù)據(jù)庫(kù)，如果數(shù)據(jù)庫(kù)扛不住壓力，會(huì)造成服務(wù)雪崩?？梢酝ㄟ^(guò) 布隆過(guò)濾器進(jìn)行優(yōu)化。
• 數(shù)據(jù)一致性：緩存數(shù)據(jù)與DB 的數(shù)據(jù)一致性問(wèn)題，需要通過(guò)更新策略進(jìn)行保障。

3、異步調(diào)用

通過(guò)異步的方式，將減庫(kù)存成功的用戶，通過(guò)消息的方式，發(fā)送給訂單服務(wù)，進(jìn)行后續(xù)的下單操作?？梢栽诙虝r(shí)間內(nèi)，將所有的商品銷售出去。整體的流程如下圖所示：

MQ異步調(diào)用為什么能過(guò)提升我們服務(wù)的吞吐量呢?

主要原因在于，通過(guò)異步調(diào)用的方式，我們將消息投遞過(guò)去了，就完成了這一次的請(qǐng)求處理，那么性能的瓶頸，由訂單服務(wù)，轉(zhuǎn)移到了秒殺服務(wù)這里。通過(guò)減少調(diào)用依賴，從而提升了整體服務(wù)的吞吐量。

??

MQ 帶來(lái)的常見問(wèn)題：

• 數(shù)據(jù)一致性
• 重復(fù)消費(fèi)：由于生產(chǎn)者重復(fù)投遞消息，或者消費(fèi)緩慢導(dǎo)致重復(fù)推送消息。需要通過(guò)加鎖，消費(fèi)冪等來(lái)保證消費(fèi)正常。
• 消息堆積：生產(chǎn)能力遠(yuǎn)大于消費(fèi)能力情況下，會(huì)導(dǎo)致消息堆積。
• MQ可用性：MQ宕機(jī)的情況下，需要支持同步調(diào)用切換。
• 這里不做詳細(xì)介紹，后面會(huì)專門寫一篇MQ相關(guān)的文章。

高可用

能看到這里真不容易，感謝大家的支持。關(guān)于可用性這里，之前有寫過(guò)一篇 # 《高可用實(shí)戰(zhàn)》-B站蹦了，關(guān)我A站什么事?感興趣可以看一下。

高可用主要可以從：

• 動(dòng)態(tài)擴(kuò)容：根據(jù)服務(wù)壓力，針對(duì)不同服務(wù)進(jìn)行動(dòng)態(tài)擴(kuò)容。
• 限流熔斷：可參考我之前的文章：# 《高可用實(shí)戰(zhàn)》-B站蹦了，關(guān)我A站什么事?
• 異地多活: 通過(guò)多機(jī)房部署，避免物理攻擊!

同城雙活

部署在同一個(gè)城市不同區(qū)的機(jī)房，用專用網(wǎng)絡(luò)連接。兩個(gè)機(jī)房距離一般就是幾十千米，網(wǎng)絡(luò)傳輸速度幾乎和同一個(gè)機(jī)房相同，降低了系統(tǒng)復(fù)雜度、成本。

??

這個(gè)模式無(wú)法解決極端的災(zāi)難情況，例如某個(gè)城市的地震、水災(zāi)，此方式是用來(lái)解決一些常規(guī)故障的，例如機(jī)房的火災(zāi)、停電、空調(diào)故障。

異地多活

在上述模式中，沒(méi)辦法解決城市級(jí)別的服務(wù)容災(zāi)，比如水災(zāi)，地震等情。而通過(guò)異地多活的部署方案，則可以解決這種問(wèn)題。

但是每個(gè)方案都是存在利和弊的，那么異地多活的弊端主要體現(xiàn)在網(wǎng)絡(luò)傳輸和數(shù)據(jù)一致性的問(wèn)題上!

跨城異地主要問(wèn)題就是網(wǎng)絡(luò)傳輸延遲，例如北京到廣州，正常情況下的RTT（Round-Trip Time 往返時(shí)延）是50毫秒，
當(dāng)遇到網(wǎng)絡(luò)波動(dòng)等情況，會(huì)升到500毫秒甚至1秒，而且會(huì)有丟包問(wèn)題。

物理距離必然導(dǎo)致數(shù)據(jù)不一致，這就得從“數(shù)據(jù)”特性來(lái)解決，
如果是強(qiáng)一致性要求的數(shù)據(jù)（如存款余額），就無(wú)法做異地多活。

圖片地址：draw.io原圖