我要開(kāi)花

前幾年匆匆寫(xiě)了一系列的spring微服務(wù)入門(mén)課程. 當(dāng)時(shí)主要用于總結(jié)心得和應(yīng)付新團(tuán)隊(duì)的內(nèi)部技術(shù)培訓(xùn), 處于有點(diǎn)交差的心態(tài), 很多點(diǎn)沒(méi)有持續(xù)深入, 說(shuō)老實(shí)話自己也不太滿(mǎn)意. 兩三年過(guò)去了, 現(xiàn)在我對(duì)微服務(wù)有更深入的認(rèn)識(shí), 業(yè)務(wù)知識(shí)也豐富了許多, 覺(jué)得自己是時(shí)候再寫(xiě)點(diǎn)深入的文章, 總結(jié)總結(jié)(加班)多年的心得了.

一開(kāi)始打算命名這個(gè)系列叫做springcloud微服務(wù)中高級(jí)系列, 在寫(xiě)代碼和心得的時(shí)候發(fā)現(xiàn)微服務(wù)的概念實(shí)在太大太廣了, 遂打算挑一些主題, 針對(duì)主題慢慢寫(xiě), 寫(xiě)細(xì)致, 寫(xiě)認(rèn)真. 這樣大家看得開(kāi)心, 我在寫(xiě)的時(shí)候也能查漏補(bǔ)缺, 補(bǔ)上自己的不足.

開(kāi)篇打算先寫(xiě)高并發(fā)系統(tǒng).

網(wǎng)上的高并發(fā)系列文章已經(jīng)很多了. 為了寫(xiě)出自己的特色, 我會(huì)以真實(shí)公司的業(yè)務(wù)和架構(gòu)設(shè)計(jì)標(biāo)準(zhǔn)來(lái)寫(xiě)這些文章. 大家能看到小肥爬爬(真實(shí)姓名老陳, 昵稱(chēng)肥叔) 剛以架構(gòu)師角色進(jìn)入一家公司, 他接到了一個(gè)優(yōu)化老架構(gòu)和設(shè)計(jì)新架構(gòu)的任務(wù), 然后他會(huì)結(jié)合實(shí)際業(yè)務(wù)進(jìn)行討論, 給出設(shè)計(jì)方案和相應(yīng)的權(quán)衡, 最后完成代碼. 這些業(yè)務(wù), 設(shè)計(jì)和代碼都或多或少真實(shí)存在于各家公司. 所以這個(gè)系列不空談, 不務(wù)虛, 打開(kāi)代碼就是干. 如果出現(xiàn)理論, 我會(huì)提個(gè)知識(shí)點(diǎn)或者放個(gè)鏈接, 大家可以自己去補(bǔ)理論知識(shí).

當(dāng)然作為一個(gè)小公司而非大廠的架構(gòu)師, 我的視野和技術(shù)能力肯定還有許多不足, 如果看到什么太離譜的錯(cuò)誤, 請(qǐng)大家指正.

正如之前的博客, 相關(guān)代碼會(huì)放到gitee/github上, 希望這些個(gè)人認(rèn)為挺有用的業(yè)務(wù)討論和代碼, 能夠勾搭到讀者的100個(gè)星星, 跪求了....

了解高并發(fā)概念與公司業(yè)務(wù)

云服務(wù)應(yīng)用軟件(系統(tǒng))由于托管在互聯(lián)網(wǎng), 天然就帶著"很可能有大量用戶(hù)訪問(wèn)"的概率和概念. 因此各家招聘單位在給出自己的招聘崗位要求的時(shí)候, 大多帶著"高流量, 高并發(fā)" 等字眼, 可是到底什么才是大流量, 什么才是高并發(fā)呢? 程序員要設(shè)計(jì)架構(gòu)到什么程度, 才能滿(mǎn)足要求? 程序員要具備什么樣的知識(shí), 才能不過(guò)度設(shè)計(jì)? (須知, 只要堆上硬件, 理論上99%的架構(gòu)要求都能滿(mǎn)足)

要回答高并發(fā)的這些問(wèn)題和實(shí)際動(dòng)手解決, 我認(rèn)為程序員(架構(gòu)師)要具備3個(gè)能力:

1. 了解掌握公司的業(yè)務(wù), 推導(dǎo), 預(yù)測(cè), 設(shè)計(jì)測(cè)試, 探索公司的真實(shí)高并發(fā)需求.

2. 根據(jù)公司實(shí)際需求進(jìn)行設(shè)計(jì)權(quán)衡, 裁剪云服務(wù)架構(gòu)以適配公司業(yè)務(wù)的能力.

3. 在項(xiàng)目啟動(dòng)實(shí)際獲得一定的流量數(shù)據(jù)之后, 總結(jié), 優(yōu)化, 提高架構(gòu)瓶頸的能力.

以上都是小肥爬爬多年踩坑的心得, 一一解釋如下.

挖掘公司真實(shí)的高并發(fā)需求

如果有家公司面試的時(shí)候問(wèn)你: "我們?nèi)栈钣脩?hù)有100萬(wàn), 你怎么設(shè)計(jì)一個(gè)高并發(fā)系統(tǒng)? " 或者" 我們一天的交易流水有1000萬(wàn), 你怎么設(shè)計(jì)一個(gè)高并發(fā)系統(tǒng)? " (這兩個(gè)都是小肥爬爬真實(shí)的公司經(jīng)驗(yàn))

這時(shí)候可千萬(wàn)別被嚇住! 這里面有一個(gè)老程序員顯而易見(jiàn)的坑在等著你跳: 用戶(hù)量和交易流水量都不代表著真正的高并發(fā), 具體問(wèn)題還是要具體分析. 那么怎么分析呢? 可以從兩個(gè)維度進(jìn)行出發(fā): 技術(shù)指標(biāo)和業(yè)務(wù)場(chǎng)景考慮.

技術(shù)指標(biāo): QPS/TPS/UV/PV

QPS: query per second (每秒讀的數(shù)據(jù)). TPS: transaction per second (每秒完成事務(wù)的數(shù)據(jù)) . 這兩個(gè)概念可以粗略分為讀和寫(xiě). 一般來(lái)說(shuō), 對(duì)于某個(gè)特定的介質(zhì)或系統(tǒng), 讀的數(shù)據(jù)會(huì)遠(yuǎn)遠(yuǎn)大于寫(xiě)的數(shù)據(jù). 這是一些關(guān)于讀寫(xiě)數(shù)據(jù)的常識(shí):

表格的第4行, 小肥爬爬讓大家接觸到熟悉的概念: 數(shù)據(jù)庫(kù). 以常用的mysql8 為例, 家用電腦的TPS大概在1-2000. 服務(wù)器版本的大概是級(jí)別呢? 一臺(tái)阿里云 2核16G , 承諾 3-4000 TPS 的mysql版本數(shù)據(jù)庫(kù), 價(jià)格約 1500元/月. 這挺貴的價(jià)格也只有3,4000TPS, 這說(shuō)明什么?

說(shuō)明其實(shí)大多數(shù)公司業(yè)務(wù)的TPS都不高.

再來(lái)看看UV和PV. UV (user visited) 表示每天訪問(wèn)的用戶(hù)數(shù), PV(page visited) 表示用戶(hù)所訪問(wèn)的總鏈接. 拿到系統(tǒng)的UV/PV數(shù)據(jù), 再結(jié)合業(yè)務(wù)和代碼, 就能把QPS和TPS大致摸出來(lái)了. 這也是業(yè)務(wù)分析的重要性, 單看一條訪問(wèn)請(qǐng)求, 不結(jié)合業(yè)務(wù), 誰(shuí)也不知道是TPS還是QPS.

業(yè)務(wù)場(chǎng)景分析

那么該公司什么樣的業(yè)務(wù)場(chǎng)景會(huì)產(chǎn)生高qps和tps呢? 接下來(lái)小肥爬爬經(jīng)過(guò)個(gè)人調(diào)研, 訪談, 查看合同, 閱讀代碼, 研究系統(tǒng)數(shù)據(jù)... 等方式, 逐漸了解新公司的業(yè)務(wù). 原來(lái)該公司有2個(gè)主要產(chǎn)品: SAAS商場(chǎng)運(yùn)營(yíng)系統(tǒng)和四方支付系統(tǒng). 前者主要為大客戶(hù)服務(wù), 大客戶(hù)手下有員工, 并有自己的C端用戶(hù)流量群體. 這些C端用戶(hù)會(huì)使用SAAS的小程序進(jìn)行支付 (暫時(shí)只有支付功能, 沒(méi)有商城), 然后產(chǎn)生交易流水....

"哦對(duì)了", 老板最后輕飄飄加了一段: "下半年我們會(huì)上個(gè)商城, 會(huì)做秒殺功能, 你好好設(shè)計(jì)一下架構(gòu). "

費(fèi)了九牛二虎之力, 小肥爬爬總算把業(yè)務(wù)需求澄清得七七八八. 最后他把業(yè)務(wù)場(chǎng)景歸納為以下幾類(lèi):

架構(gòu)師小肥爬爬經(jīng)過(guò)周密的業(yè)務(wù)研究和分析之后, 成功地跳出了這個(gè)坑. 他不再是處于戰(zhàn)爭(zhēng)迷霧里兩眼一黑的指揮官. 公司的一系列業(yè)務(wù), 數(shù)據(jù)總量其實(shí)都不大, 瞬時(shí)流量也不大, 所以并發(fā)量并不大. 發(fā)現(xiàn)該公司唯一可能產(chǎn)生"高并發(fā)"請(qǐng)求的業(yè)務(wù)場(chǎng)景, 就是即將上線的商城秒殺任務(wù)了.

掌握了情報(bào)的小肥松了一口氣, 開(kāi)始下一階段的架構(gòu)設(shè)計(jì)工作.

程序員技巧: 如何迅速挖掘新系統(tǒng)的性能要求

1.用grep/sed命令, 統(tǒng)計(jì)nginx或者微服務(wù)的日志頻率并排序, 找出top10-20 pv的接口. (如果運(yùn)維環(huán)境有 prometheus 之類(lèi)應(yīng)用就更簡(jiǎn)單, 直接看數(shù)據(jù)即可. )

2.閱讀該接口代碼和查看數(shù)據(jù)庫(kù)數(shù)據(jù), 和業(yè)務(wù)人員討論業(yè)務(wù), 迅速了解該接口的業(yè)務(wù)背景.

最終目標(biāo), 是快速得出以下量化的性能數(shù)據(jù)分析表, 以做到心中有數(shù), 并且可以和團(tuán)隊(duì)技術(shù)人員進(jìn)行溝通.

image.png

(以上數(shù)據(jù)均有虛構(gòu), 如有雷同, 請(qǐng)聯(lián)系我進(jìn)行刪除)

可以看出, 其實(shí)系統(tǒng)的QPS和TPS 均不高.

標(biāo)準(zhǔn)的云應(yīng)用(微服務(wù))架構(gòu)

作為多年互聯(lián)網(wǎng)開(kāi)發(fā)老兵, 小肥爬爬此時(shí)已經(jīng)知道, 公司的性能要求并不高, 標(biāo)準(zhǔn)的微服務(wù)架構(gòu)就可以支撐. 即使未來(lái)上了秒殺業(yè)務(wù), 稍加改造一些性能關(guān)鍵點(diǎn)即可. 但是作為程序員, 嚴(yán)謹(jǐn)是必須放在第一位的. 架構(gòu)師必須給出明確的架構(gòu)設(shè)計(jì), 和各個(gè)部件的量化指標(biāo), 以作公司的技術(shù)要案?jìng)浞莺统蔀榇蠹业挠懻摶A(chǔ), 含糊其辭就干, 會(huì)讓項(xiàng)目很容易陷入到忙亂和爭(zhēng)吵之中. 比如這個(gè)技術(shù)該不該要? MQ該用哪個(gè)?服務(wù)器該買(mǎi)什么樣的標(biāo)準(zhǔn)? 你做決定的依據(jù)是什么? ....

說(shuō)到底, 努力用心, 經(jīng)過(guò)詳細(xì)分析設(shè)計(jì)的系統(tǒng)才是好系統(tǒng), 才不會(huì)前期背負(fù)太多技術(shù)債務(wù), 才容易隨著業(yè)務(wù)演化而重構(gòu)代碼. 拍腦袋就上, 后期消滅不了代碼屎山的項(xiàng)目, 老程序員已經(jīng)見(jiàn)過(guò)好幾個(gè)了.

裁剪微服務(wù)架構(gòu)

image.png

小肥爬爬知道, 這是一個(gè)標(biāo)準(zhǔn)的微服務(wù)架構(gòu)圖, 可以說(shuō)這個(gè)架構(gòu)是萬(wàn)能的. 從業(yè)務(wù)系統(tǒng)開(kāi)發(fā) -> 數(shù)據(jù)倉(cāng)庫(kù)建設(shè)都一把完成了. 可是它也比較笨重, 需要維護(hù)的中間件也有點(diǎn)多. 之前說(shuō)過(guò)架構(gòu)師要懂得根據(jù)業(yè)務(wù)進(jìn)行權(quán)衡, 那么前期沒(méi)有數(shù)據(jù)倉(cāng)庫(kù)的時(shí)候, 是不是可以不用數(shù)據(jù)倉(cāng)庫(kù)的建設(shè)呢? 比如如果實(shí)際流量不大, 是否可以省個(gè)MQ? ... 諸如此類(lèi), 于是針對(duì)快要上線的商場(chǎng)秒殺功能, 他先做了個(gè)架構(gòu)草圖, 如下:

image.png

這是一個(gè)簡(jiǎn)單得不能再簡(jiǎn)單的"架構(gòu)", 事實(shí)上就是后端網(wǎng)站的配置做法, 每個(gè)后端開(kāi)發(fā)程序員入門(mén)學(xué)習(xí)的時(shí)候接觸的都是這樣的東西. 小肥爬爬需要作出說(shuō)明的是: 如何進(jìn)行業(yè)務(wù)設(shè)計(jì), 才讓這個(gè)架構(gòu)滿(mǎn)足公司的并發(fā)需求?

熟悉互聯(lián)網(wǎng)開(kāi)發(fā)的同學(xué)會(huì)發(fā)現(xiàn), 其實(shí)這和單體結(jié)構(gòu)沒(méi)什么區(qū)別. 但是用微服務(wù)的好處, 就是后期擴(kuò)展容易, 特別是業(yè)務(wù)分工更合理, 項(xiàng)目整體節(jié)奏加快. (當(dāng)然也見(jiàn)過(guò)沒(méi)有加快的案例, 那純粹是團(tuán)隊(duì)能力問(wèn)題了)

商城的秒殺指標(biāo)

同時(shí)經(jīng)過(guò)內(nèi)部討論, 歷史數(shù)據(jù)研究, 后續(xù)業(yè)務(wù)數(shù)據(jù)預(yù)判, 業(yè)務(wù)需求討論, 運(yùn)營(yíng)目標(biāo)討論.... 一系列動(dòng)作, 小肥爬爬和他的團(tuán)隊(duì)制定了商城的數(shù)據(jù)指標(biāo):

1. 單次參與秒殺的商品數(shù)量不多于4000件. (業(yè)務(wù)方需求)

2. 要能支持最多10萬(wàn)用戶(hù)并發(fā)搶單. (業(yè)務(wù)方和技術(shù)方妥協(xié)需求)

作為業(yè)務(wù)方來(lái)說(shuō), 能夠支持越來(lái)越多的用戶(hù)搶單當(dāng)然好, 這能擴(kuò)大產(chǎn)品的影響力; 可是作為技術(shù)方和已經(jīng)掌握公司業(yè)務(wù)數(shù)據(jù)的小肥架構(gòu)師, 這個(gè)餅不能無(wú)限地畫(huà)大. 更多的用戶(hù)意味著更多的服務(wù)器, 意味著更多的投入, 還可能誤導(dǎo)團(tuán)隊(duì)做出過(guò)度的技術(shù)設(shè)計(jì). 從已有數(shù)據(jù)來(lái)看, 小肥爬爬甚至覺(jué)得有一兩萬(wàn)用戶(hù)參加就不錯(cuò)了, 最終大家在友好的氣氛中互毆, 啊不, 達(dá)成協(xié)議: 按照10萬(wàn)用戶(hù)搶單來(lái)進(jìn)行設(shè)計(jì).

這是大多數(shù)軟件公司的現(xiàn)狀: 業(yè)務(wù)團(tuán)隊(duì)雄心勃勃但容易誤導(dǎo)技術(shù)團(tuán)隊(duì), 架構(gòu)師要具備腳踏實(shí)地并適當(dāng)前瞻的技術(shù)水平, 帶領(lǐng)公司技術(shù)方向前進(jìn).

由于這篇教程的代碼都是跑在本地而不是真實(shí)的多服務(wù)器生產(chǎn)環(huán)境, 所以我對(duì)目標(biāo)略微作了一下調(diào)整. 調(diào)整成支持2000件商品參與秒殺, 1萬(wàn)用戶(hù)參與并發(fā). 這樣已經(jīng)足夠作為代碼演示了.

下一篇會(huì)正式開(kāi)始擼代碼.