高并發高可用的分布式電商平臺架構研究

耿曉利，張 芒，尹永宏

(廣州大學華軟軟件學院，廣東 廣州 510990)

0 引 言

微服務[1]具有模塊化開發、分布式部署的特性，各個模塊獨立部署、運行更新，有著靈活的擴展性，適用于海量數據單體應用的解耦[2]。Dubbo[3]是阿里巴巴公司開源的一個高性能和透明化的PRC遠程調用框架,搭配Zookeeper[4]作為分布式服務的注冊中心，在如今高可用解決方案的技術選型中被廣泛使用[5]。

基于分布式的架構技術正在不斷發展，各大互聯網廠商的分布式框架不斷迭代，分布式架構在電商行業應用中蓬勃發展，較多文獻對分布式架構下電商平臺的構建進行了研究[6-8]，同時也向金融、政務、社交等領域逐步滲透。

該文以電商業務為切入點，以SpringBoot[4]和MyBatis作為實現基礎服務單元的企業級基礎框架，綜合集成分布式開源框架Dubbo、注冊中心Zookeeper、百度開源統一配置中心Disconf、消息中間件RabbitMq、Spring安全認證授權框架Spring Security[9]、緩存數據庫Redis[10]等，采用前后分離的Restful Api[11]架構風格和Docker[12-13]容器化部署方法，設計并實現了基于B2C的新零售購物平臺。系統通過服務化的手段，按照功能維度劃分，使各功能服務中心最大限度地解耦，各服務通過注冊中心自動完成服務的注冊與發現，互相隔離，使用消息中間件技術進行消息訂閱、異步處理、流量削峰等。

1 系統架構

本系統有用戶中心、商品中心、營銷中心、庫存中心、物流中心、客服中心以及數據統計中心,各服務中心之間以RPC(遠程調用)的方式進行通信，統一在Disconf配置中心下載各自指定的配置文件，同時以服務提供者的角色注冊在注冊中心Zookeeper上。控制器層作為服務消費者角色向注冊中心Zookeeper訂閱其需消費的服務，通過Nginx反向代理分發至不同客戶端。系統采用Spring Security和Jwt作為安全認證授權框架，客戶端登錄到用戶中心，用戶中心將通過此框架向客戶端發布帶有加密用戶信息的授權令牌(token)，并在此后用戶訪問中攔截其請求，校驗令牌信息和驗證用戶身份是否正確，正確則放行，否則將拒絕此用戶訪問。

系統架構如圖1所示。

圖1 系統架構

1.1 應用層

系統架構應用層主要有移動端APP、微信小程序和WEB端后臺管理系統。各不同客戶端調用Nginx提供的統一接口訪問地址，再通過Nginx將請求反向代理至服務層，在應用層中，Nginx將擔負著負載均衡和限流的任務，在系統流量突然爆發的時間段，將流量按照調度算法均衡地分發至不同服務器，同時狙擊惡意請求流量和惡意攻擊；是洪峰流量進入后臺服務的一道重要的安檢口，也是保護系統平穩運行的重要關卡之一。在該系統設計中，應用層還有一個重要的功能：在高并發處理中使用Nginx降級策略，將犧牲一部分請求來保證系統的穩定，從而保證了系統的高可用性。

1.2 接口層

接口層在系統架構中扮演著服務消費者的角色，是應用層通過Nginx將請求分發的目的地。在接口層中，設計了基于Spring Security和Jwt安全授權訪問過濾器，其主要作用是通過解析令牌(token)校驗請求的合法性以及是否擁有所訪問接口權限，保證接口安全。由于Jwt的認證方式是無狀態的，可以在多個服務之間共享，加上生命周期的設置，實現了系統的SSO單點登錄功能。

接口層通過訂閱注冊中心上的已發布的服務，完成應用層的請求和回應。該層提供Restful Api架構風格的調用地址，通過遠程調用的方式完成與服務層之間的數據交互。

1.3 服務層

服務隔離是指將系統服務分割開，是為了在系統發生故障時，能限定傳播范圍和影響范圍，即發生故障時不會出現像單體架構一樣的滾雪球效應。在該系統架構中，注冊中心的一個節點出現故障后，注冊中心通過HTTP心跳檢測會將該節點排除出服務提供者名單，自動切換其他可用節點，從而保證只有出現故障的節點不可用，其他節點仍然是可用的。該系統服務層是系統功能的具體實現，扮演著服務提供者的角色。按照系統功能維度劃分不同的服務中心，各服務相互隔離、獨立部署，擁有自己獨立的數據庫，是系統完成特定功能領域的集合；通過服務化的設計，將單體架構中捆在一起的服務抽離，大大地降低了系統功能耦合度，為系統功能的不斷擴展和維護奠定了基調。在秒殺業務場景下，隨著接口調用次數不斷增高，此時的秒殺服務單節點的負荷率將直線上升，由于服務器資源的有限性，將直接影響到其他非秒殺業務的穩定性。如圖2所示，該系統在設計中，將在商品服務中劃分出以秒殺業務為核心的單獨服務集群，從而解決了在秒殺業務洪峰流量到來之時，保證其他業務的穩定運行，不受其影響。

圖2 服務集群分組

2 平臺功能實現

2.1 系統基礎服務層實現

系統中設計的公共類為基礎服務層，在此層中集成了基礎工具類、接口統一返回格式、各枚舉類、各配置類等，作為系統底層服務提供給各業務服務中心使用。基礎服務層最重要的一個功能是與統一配置中心Disconf交互，在項目啟動時，將各配置文件從配置中心拉取到配置文件夾中，供各個服務中心使用；在此層中通過.xml文件配置掃描包所在位置以及使用托管方式的Disconf配置，其中包含配置文件名稱等。如圖3所示，在初始化Disconf項目后通過瀏覽器WEB界面錄入配置文件名，所屬模塊，版本號，開發環境。此設計將系統繁雜的配置信息從系統內部抽離出，由配置中心統一管理，一旦配置信息如數據庫地址改變，在配置中心修改即可，配置中心發生修改會立即通知程序重新拉取配置文件，而不必通過停止程序的運行去一個個地修改配置，從而大大提高了系統的執行效率和維護成本。

圖3 統一配置中心Disconf配置錄入

2.2 系統服務層實現

系統服務層在系統整體架構中扮演著服務提供者的角色，是系統各功能模塊具體實現的匯集地，也是整個系統中業務處理能力要求最高的核心區域。該層使用了分布式搜索引擎ElasticSearch作為商品中心的商品搜索服務快速搜索框架，使用緩存數據庫Redis完成商品詳情信息、商品維度和用戶維度存儲等，使用開源中間件RabbitMq作為秒殺業務的通訊組件。

2.2.1 用戶中心

在功能模塊劃分中，用戶中心具有用戶基礎信息管理、用戶行為管理、用戶角色權限管理、用戶地址管理、用戶購物車管理、用戶登錄授權管理等功能。用戶通過注冊頁面錄入基礎信息，系統根據普通用戶和管理員設置不同權限，用戶行為管理記錄用戶每次登錄信息、搜索行為等。

2.2.2 商品中心

商品中心在整個服務層占據業務核心地位，根據業務細粒度劃分有商品詳情服務、購物車服務、訂單服務、支付服務，評價服務，秒殺服務和庫存服務等，業務詳細流程如圖4所示。用戶瀏覽商品列表，選擇商品查看詳情，選擇購買或者加入購物車后系統判斷登錄狀態，未登錄則完成用戶登錄流程后選擇收貨地址以及完成訂單支付，訂單支付后進入物流服務和評價服務。其中，當訂單支付后以消息隊列的方式通知庫存服務進行庫存調整操作。選擇消息隊列方式進行庫存操作，是因為消息隊列方式可以保證庫存操作的原子性，避免訂單數量超過及時庫存數，造成負庫存情況出現。其中秒殺服務獨立于其他商品服務，劃分為獨立的服務分組，如圖5所示，當秒殺業務開始時，用戶訂單支付后進入消息隊列排隊，消息隊列根據及時庫存數的3倍作為進入消息隊列的請求數，將排隊數量限制在一定的范圍內，超過這個范圍內的數量將直接返回秒殺結束的狀態，成功進入消息隊列的請求按照隊列先進先出的原理，同時運用分布式事務機制[14]，將訂單支付和庫存服務作為事務管理，訂單支付和庫存數的遞減同時完成，否則執行回滾操作。這樣既減輕了隊列的負擔，又能保證庫存服務的準確性和系統的穩定性。

圖4 系統業務流程

圖5 秒殺業務流程

2.2.3 營銷中心

營銷中心主要是為了完成商品優惠券發放、商品預熱等功能。后臺管理員通過優惠券面額、發放對象、使用期限等信息的填寫，將優惠券存入系統表中，系統將以兩種方式向用戶發放優惠券，一種是以系統通知的方式向用戶推送領取通知，用戶點擊通知跳轉至領券頁面完成優惠券領取，另一種方式是以用戶查看商品詳情的方式在商品詳情頁面放置優惠券領取欄，在用戶查看商品的同時就可以領取相應的優惠券完成購買流程。商品預熱功能主要是為了向添加在用戶購物車里的商品推送商品降價信息，為了刺激商品交易額的增加，商品預熱服務還將根據用戶中心的用戶行為服務獲取到用戶個人喜好，將通過個人喜好匹配相對應類型的商品，通過首頁商品列表展示的方式向不同的用戶推送。

2.2.4 物流中心

物流中心對接商品中心中的訂單服務，完成用戶訂單支付后的物流信息跟蹤、收貨提醒等功能。物流中心對接阿里云物流接口，通過物流訂單號以及快遞公司名稱的輸入，獲取到阿里云物流信息，將物流信息返回格式轉換成系統顯示格式以步驟條的形式顯示在客戶端，當物流信息更新至即將配送的狀態，以系統通知的形式向用戶推送收貨提醒。

2.2.5 客服中心

客服中心使用WebSocket[15]實現，主要完成的功能是用戶購買前的客服咨詢功能以及購買后的售后功能。分為客服端和用戶端，在聊天中支持商品鏈接發送、商品圖片發送等功能。

2.2.6 數據統計中心

數據統計中心體現數據中臺思想，主要統計周銷量、月銷量、季節銷量、地區購買力、年齡段購買力等，完成不同維度銷量對比，輸出對應對比結果，以echart圖表顯示在后臺WEB端，在搶購時間段，還將實時顯示各商品銷量，供商家進行實時庫存調整。數據統計中心還將完成各類報表制作與查詢，具體輸出報表有銷售報表、庫存報表、財務報表等。

3 系統部署

為了適用分布式架構高并發高可用原則，系統部署采用Docker容器化部署方法，運行系統統一采用Linux發行版CentOS7.6,選用服務器16臺，每臺主機為8核3.0 GHz CPU,8 GB內存，阿里云OSS存儲對象主要用來存儲用戶頭像、商品圖片等系統靜態資源。在運行系統CentOS上通過Docker鏡像分別配置分布式框架開發環境和上線環境，如圖6所示，相應配置集成Tomcat、Nginx、Disconf、Zookeeper、Dubbo、Redis、MySql、RabbitMq等，各服務中心代碼打成war包后將放置在對應的Tomcat實例里，保證各服務之間相互隔離，互不影響。

圖6為CentOS集成示例。

圖6 CentOS集成示例

4 性能測試

接口響應速率、CPU占有率和磁盤I/O是系統高可用性的重要性能指標，系統從這三個方面展開進行測試驗證。

4.1 接口響應速率

接口響應速率測試是從同一并發量下不同數量節點接口響應速率和不同并發量下多節點接口響應速率兩方面展開。同一并發量不同數量節點請求的商品列表顯示效率，主要測試點是商品中心模塊的商品詳情服務，測試用例為并發量500，通過Jmeter腳本分別向不同節點的商品中心接口同時發起并發請求，結果如圖7(a)所示，隨著節點數的不斷增多，接口平均響應時間不斷遞減，在節點數為16的時候，接口響應時間達到0.56 s，完全達到了測試要求。在不同并發量下多節點的接口平均響應時間，將測試點選在單個商品詳情請求接口，測試用例為并發量500、1 000、2 000，測試接口在這三種并發量下的平均響應時間。結果如圖7(b)所示，在節點數為16的相同條件下，接口的平均響應時間隨著并發量的增多而不斷增多，在測試2 000個并發量的時候，接口平均響應時間達到0.91 s，符合測試高并發原則要求。

(a)同一并發量不同數量節點接口響應速率

4.2 不同并發量下單節點CPU占有率和磁盤I/O

隨機抽取一臺主機，以商品搜索為測試點，“棉服”為搜索關鍵字，并發量設置為1 000和2 000，測試分布式架構下CPU占有率和磁盤I/O占有率情況，結果如圖8所示。在并發數為1 000的條件下，CPU占有率達到57%，屬于中等水平，磁盤I/O占有率低于40%，符合高并發下系統平穩運行的標準。

圖8 不同并發量下單節點CPU占有率和磁盤I/O

5 結束語

系統使用分布式軟件架構設計并實現了基于B2C的新零售購物平臺。開發過程中充分考慮了不同業務流程的高并發處理能力，在威脅系統穩定的節點運用了消息隊列、緩存數據庫、分布式事務等技術，為系統的平穩運行提供了可靠的保障。通過高可用性的幾個重要性能指標，測試并驗證了在高并發場景下的功能可用性和性能可靠性，為百萬級流量系統的軟件架構技術選型提供了一種可行的服務化治理方案。