前1號店技術(shù)總監(jiān)黃哲鏗揭秘：微服務(wù)架構(gòu)在千萬級別日調(diào)用量、億級別海量數(shù)

時間：2022-08-12 04:42:01 | 來源：網(wǎng)站運(yùn)營

時間：2022-08-12 04:42:01 來源：網(wǎng)站運(yùn)營

上周，前1號店技術(shù)總監(jiān)、海爾農(nóng)業(yè)電商CTO，《技術(shù)管理之巔》作者黃哲鏗為大家?guī)砹艘粓鲫P(guān)于微服務(wù)架構(gòu)的分享，包含了微服務(wù)架構(gòu)在千萬級別日調(diào)用量、億級別海量數(shù)據(jù)場景下的應(yīng)用實(shí)踐；從領(lǐng)域驅(qū)動設(shè)計、服務(wù)依賴治理、服務(wù)高可用、故障熔斷降級快速恢復(fù)等方面，結(jié)合大型移動電商系統(tǒng)等應(yīng)用案例，全面剖析微服務(wù)的應(yīng)用等豐富的內(nèi)容。





下面是場主整理的聽課筆記，有需要的小伙伴可以收藏哦~

微服務(wù)架構(gòu)在大型電商中的運(yùn)用

電商是促銷拉動式的場景，也是價格戰(zhàn)驅(qū)動的場景。618和雙11都是典型的促銷活動。其實(shí)都是在搶用戶、擴(kuò)市場占有率。在這樣的場景之下，對秒殺、搶購是很熱衷的玩法。

促銷式的拉動對系統(tǒng)的挑戰(zhàn)是什么呢？

可以從上圖里看到：對高可用性的要求是非常高的，需要99.99%的高可用性。快速迭代對對系統(tǒng)容性的要求很高，從幾萬單變成幾十萬單、百萬單，架構(gòu)上不能影響快速迭代，所以有空中加油或者是高速公路換輪胎的說法。

另外，為了應(yīng)對瞬間的海量訪問（尤其是秒殺場景），系統(tǒng)需要高可伸縮（快速擴(kuò)容和縮容），這些都是對系統(tǒng)的要求。

大型電商系統(tǒng)的架構(gòu)

從下往上，數(shù)據(jù)層，埋點(diǎn)數(shù)據(jù)把用戶行為數(shù)據(jù)，實(shí)時數(shù)據(jù)存儲在NoSQL、關(guān)系型數(shù)據(jù)庫、大數(shù)據(jù)平臺 。

基礎(chǔ)架構(gòu)層

這層實(shí)際上是中間件和服務(wù)，包括MQ的消息、job的調(diào)試中心、sso聯(lián)合登陸，還有發(fā)消息的，分布式的文件存儲，用戶上傳的一些圖片等等，除此之外還有應(yīng)用監(jiān)控的整個體系、自動發(fā)布的框架，支持到AB測試。

基礎(chǔ)服務(wù)層

再上面一層就是基礎(chǔ)服務(wù)層，這實(shí)際上是用基礎(chǔ)架構(gòu)層提供的組件和服務(wù)，加上一些業(yè)務(wù)邏輯，構(gòu)建了一些公用的服務(wù)，包括OMS、PMS采購，運(yùn)費(fèi)模板、配送區(qū)域等，這些都是電商最常用的基礎(chǔ)服務(wù)。

業(yè)務(wù)服務(wù)層

業(yè)務(wù)服務(wù)層我們可以看到的是，比如用戶在前臺能看到的界面，比如購物車、訂單、首頁，不管是不是微服務(wù)，至少是服務(wù)化的。這層就是所有網(wǎng)站應(yīng)用的核心。除此之外就是第三方平臺的api對接。

虛擬類目相當(dāng)于“標(biāo)簽”，比如我們正常的類目叫做“生鮮”、“服裝”，還有一些虛擬的類目叫做“618特賣”，里面會聚合很多的商品，可以理解為一個標(biāo)簽，作為展示用。

暴露在最頂層的我們可以看到，這些就是各個端，比如H5、PC、官網(wǎng)，這就是最終可見的端。

微服務(wù)架構(gòu)的設(shè)計

應(yīng)用的無狀態(tài)化

很多網(wǎng)站一開始可能不是微服務(wù)化的，在早期的一些項(xiàng)目里，我們?yōu)榱丝焖偕暇€交付，會做一些單體的應(yīng)用。隨著訂單量的發(fā)展，我們就開始做所謂的“微服務(wù)化”，第一步是把所謂的單體應(yīng)用，變成應(yīng)用的無狀態(tài)化，以登錄SSO來看，就是一種解決去狀態(tài)化的方法。我們會拿到一個token，每次訪問都會帶著token，這就是所謂的去狀態(tài)化。之后每一個應(yīng)用都有橫向可擴(kuò)的能力。當(dāng)訪問量大的時候，就可以通過加服務(wù)器來增強(qiáng)水平擴(kuò)展的能力。




這種應(yīng)用無狀態(tài)，其實(shí)配置文件還是有狀態(tài)的。比如訪問的數(shù)據(jù)庫和節(jié)點(diǎn)，這些是通過配置文件來完成。我說到的案例基本都是基于spring boot來做微服務(wù)化，相關(guān)技術(shù)框架包括：dubbo、zk、hystrix、rocketmq、elasticsearch、redis等等。

單體應(yīng)用的拆分

在做了應(yīng)用的無狀態(tài)之后，就是對單體應(yīng)用的拆分。拆分有幾個維度，一個是從系統(tǒng)的維度，最簡單的拆法就是前后臺拆開。比如購物車、商品、搜索、首頁等屬于前端，而后端給網(wǎng)站運(yùn)營人員用。




還可以按功能的維度來拆分，對于用戶服務(wù)，從service層到表結(jié)構(gòu)，其實(shí)是可以獨(dú)立部署的，這就是微服務(wù)的概念。技術(shù)架構(gòu)反應(yīng)的就是組織架構(gòu)，在這種架構(gòu)下開發(fā)團(tuán)隊分為用戶服務(wù)開發(fā)組，價格開發(fā)組，商品開發(fā)組等。




還可以根據(jù)讀寫維度進(jìn)行拆分。比如搜索和商城的索引肯定是獨(dú)立的兩個服務(wù)。用戶注冊下單支付是一個完整的業(yè)務(wù)流程。這些是由若干個微服務(wù)構(gòu)成。

服務(wù)架構(gòu)搭建

數(shù)據(jù)的異構(gòu)

在大型電商系統(tǒng)里面的服務(wù)架構(gòu)搭建的經(jīng)驗(yàn)和技巧。首先是數(shù)據(jù)的異構(gòu)，以訂單表為例，一般訂單都非常龐大，一般按照id來分表分庫。這種分法對于查詢用戶所有訂單時就要去各表撈數(shù)據(jù)，因此可以按用戶維度來異構(gòu)一張表。對于數(shù)據(jù)的存儲，會分為熱數(shù)據(jù)、冷數(shù)據(jù)和溫數(shù)據(jù)，分別存在不同的地方。同時也會對數(shù)據(jù)進(jìn)行聚合。在一些訂單詳情頁，由于有很多ajax請求，由于請求數(shù)太多，也需要做一些請求合并。后臺的服務(wù)也要做一個合并。




以商品詳情頁為例，使幾個接口的數(shù)據(jù)緩存合并在redis中，從redis中取得聚合好的數(shù)據(jù)，稱為數(shù)據(jù)閉環(huán)。這是優(yōu)化網(wǎng)絡(luò)請求的通常做法。

緩存

緩存在大型電商系統(tǒng)中是常用的優(yōu)化技巧。瀏覽器級別的緩存通過響應(yīng)頭進(jìn)行設(shè)置。還會用到app客戶端的緩存，把H5/CSS/JS/圖片打包，提前拉到客戶端，在客戶端做一個代理服務(wù)器，但是不會讀取數(shù)據(jù)。可以提升用戶體驗(yàn)。緩存的使用在網(wǎng)絡(luò)上還有常用的cdn。進(jìn)到接入層后，如果使用軟負(fù)載，也可以使用內(nèi)存級別的緩存。

消息隊列的應(yīng)用

消息隊列的應(yīng)用，是做服務(wù)解耦的好方法。也要考慮消息失敗和重試的場景，需要來做一些額外補(bǔ)償來防止數(shù)據(jù)丟失。還有一個機(jī)制是數(shù)據(jù)的校驗(yàn)和補(bǔ)償。很多的場景能做到的是最終一致性，大型的電商系統(tǒng)和金融系統(tǒng)場景非常不一樣，在設(shè)計分布式系統(tǒng)時，這是常用的方式。在電商中大多數(shù)情況只要實(shí)現(xiàn)最終一致性就可以了。

高可用的架構(gòu)設(shè)計

高可用的架構(gòu)設(shè)計，對于電商來說，其實(shí)高可用是最基本的要求。如果在促銷時，引來千萬級別的用戶，宕機(jī)會損失很大。

服務(wù)的降級、分組和故障的隔離

基于微服務(wù)架構(gòu)的電商系統(tǒng)，高可用的方案有以下幾個部分，首先要支持服務(wù)的降級。要做降級的開關(guān)，寫在配置中心里面。比如在大促時，先把訂單放在緩存時，再進(jìn)行落庫等操作。同時還要有服務(wù)分組和故障的隔離。比如秒殺時，對秒殺的應(yīng)用單獨(dú)部署服務(wù)，當(dāng)秒殺的應(yīng)用掛了之后，不會影響其他服務(wù)，因?yàn)橛蟹?wù)的隔離。同時要有限流機(jī)制，很多的框架都有支持。

流量治理

在極限的場景下， 對流量的治理要從多層面進(jìn)行。比如在促銷當(dāng)天，會開啟對于爬蟲和機(jī)器人的流量進(jìn)行限流。一般會在大促前進(jìn)行封板，如果出現(xiàn)問題，就進(jìn)行回滾，比如數(shù)據(jù)版本的回滾，在設(shè)置數(shù)據(jù)結(jié)構(gòu)的時候，要做支持帶數(shù)據(jù)版本號的回滾。

業(yè)務(wù)設(shè)計

業(yè)務(wù)設(shè)計方面的思考。從圖中可以看到訂單支付的流程。在設(shè)計的時候要考慮防重設(shè)計，可以采用防重key或者防重表的方案，但是耗費(fèi)和代價很高，會在某些場景使用，比如積分，扣費(fèi)等和金錢相關(guān)的場景下用。










業(yè)務(wù)設(shè)計要考慮狀態(tài)機(jī)。尤其是訂單的流轉(zhuǎn)狀態(tài)里，要做狀態(tài)機(jī)的應(yīng)用，包括正向和逆向流程，及其產(chǎn)生的結(jié)果。










大型移動電商的架構(gòu)

動態(tài)路由

最后來回顧一下大型移動電商的架構(gòu)。下圖是一個移動電商的完整架構(gòu)。從app端，主要做的是靜態(tài)文件的緩存和智能的動態(tài)路由。中國的網(wǎng)絡(luò)環(huán)境很復(fù)雜，需要在app端做智能動態(tài)路由?？梢陨弦恍ヽdn，對動態(tài)的內(nèi)容也做鏈路優(yōu)化。會有一些對網(wǎng)絡(luò)環(huán)境檢測的機(jī)制，可以是cdn，或者是走域名，也可以暴露ip。

埋點(diǎn)和網(wǎng)關(guān)

移動電商里對app來說還有一個很重要的是埋點(diǎn)，指的是全鏈路埋點(diǎn)。從app里用戶的每一個操作，這個操作經(jīng)過網(wǎng)絡(luò)、服務(wù)層、中間件，整個鏈路要可以監(jiān)控。對于快速的定位問題是非常有幫助的，尤其是移動電商性能的優(yōu)化，第一步就是埋點(diǎn)。

在網(wǎng)絡(luò)這一層，還有網(wǎng)關(guān)的接入。比如限流，動態(tài)負(fù)載。在網(wǎng)關(guān)里沒有加太多邏輯，也有不同的做法。對于服務(wù)來說，最復(fù)雜的是服務(wù)的依賴和治理。服務(wù)之間調(diào)用的優(yōu)化要基于業(yè)務(wù)場景，比如說購物車的服務(wù)，調(diào)用到價格、庫存、促銷等。當(dāng)依賴的服務(wù)不可用的時候，比如價格不可用，設(shè)計依賴的時候，要在購物車服務(wù)中做一個緩存，來對緩存調(diào)用，最后再對最終一致性進(jìn)行驗(yàn)證。

全鏈路監(jiān)控的做法，需要做到預(yù)警，這就是一個基礎(chǔ)。通過對數(shù)據(jù)的監(jiān)控請求來后，根據(jù)場景來做預(yù)警方案。