【轉】惟品會11.11：峯值系統應對實踐

原文地址：http://www.infoq.com/cn/articles/vip-11-11-peak-system-practice

區別於其餘網購品牌惟品會定位是「一家專門作特賣的網站」， 商業模式爲「名牌折扣+限時搶購+正品保險」，即「閃購」（flash sales）模式。天天上新品，以低至1折的深度折扣及充滿樂趣的限時搶購模式，爲消費者提供一站式優質購物體驗，

這種閃購限時特賣業務特色決定了網站隨時都須要處理高併發、大流量的用戶請求。大量買家在每次新的品牌檔期上線後，大量涌入，搶購商品，形成網站承擔大量流量。尤爲碰到熱門商品，網站併發訪問劇增，會形成整個網站負載太重，響應延遲，嚴重時甚至會出現服務宕機的狀況。

另外惟品會有衆多的業務銷售模式，如自營銷售模式、JIT、直髮、海淘、O2O等等，這些業務銷售模式致使系統很是複雜。系統外部須要經過開放平臺對接供應商系統和第三方物流系統。內部系統包括諸多系統，如供應商管理、商品選品、商品交易、支付系統、物流倉儲、客服系統、商品配送等等。這些系統功能模塊之間關聯性很是強，邏輯擴展很是複雜，如何快速知足業務發展的須要，是一個很是迫切的問題。

爲了保證系統在高併發、大流量訪問下工做，而且使系統有較強的擴展性，咱們的設計主要從如下幾個方面展開：

• 系統模塊有效切分
• 服務化解耦，集中服務治理
• 增長異步訪問
• 多階段緩存，下降後端壓力
• 優化數據庫訪問
• 增強系統監控

系統模塊有效切分

惟品會整個業務系統雖然已經拆分紅幾個相對獨立的子系統如交易平臺（B2C）、VIS、WMS、TMS、ODS、CS、EBS等，可是這些業務系統在實際運做中業務耦合嚴重。碰到新業務邏輯加入，就須要每一個模塊作大量修改，各個開發團隊之間爲了業務邏輯放在那裏爭論不休，浪費了大量的時間，致使開發效率比較低。這主要因爲模塊劃分不合理，致使模塊之間邊界不清楚。因此咱們架構團隊從整個系統角度出發，梳理整個流程，從新作系統定位，將不一樣業務子系統作物理分離，減小彼此之間的依賴，使各個子系統獨立部署，出現問題後能快速採起措施，隔離出問題模塊，將故障影響降到最低。

服務化解耦，集中服務治理

服務化設計已經被主流電商系統證實是一個切實可行的方向。經過SOA服務化改造，實現了服務使用者和服務提供者的分離，使系統間的服務解耦和系統內高內聚，大大簡化了系統複雜性，具備更強的伸縮性和擴展性，知足了業務快速發展的須要。

咱們怎麼有效管理這些服務呢？

Venus是惟品會自開發的一款基於Spring的Java開發框架, 以下降開發的複雜度, 提升開發人員的開發效率, 提高代碼質量, 規範開發流程。

Venus框架涵蓋了如下內容：

• 數據庫訪問層封裝，支持分庫、分表，鏈接池優化
• 緩存（Redis/Memcached）接口封裝，鏈接池優化
• CRUD服務代碼自動生成（包含數據庫操做）
• OSP/REST服務調用接口封裝及異步支持
• ValidateInternals
• 單元／集成測試模版代碼自動生成
• 配置中心
• 中央文檔中心

Venus生態體系

其中開放服務平臺（OSP）的主要目標是提供服務化的核心遠程調用機制。契約化的服務接口保證系統間的解耦清晰、乾淨；基於Thrift的通訊和協議層確保系統的高性能；服務能夠自動註冊並被發現，易於部署；配合配置中心，服務配置能夠動態更新；客戶端與治理邏輯的分離使服務接入獲得極大簡化；除此以外，OSP提供了豐富的服務治理能力，如路由、負載均衡、服務保護和優雅降級等，經過OSP，有效的實現了流量控制。

服務分流

首先OSP Proxy具備軟負載的做用，系統不須要硬件負載均衡，能夠將服務請求均衡地分配到不一樣服務主機上。另外OSP能夠配置服務的路由，服務請求能夠被分配到不一樣版本的服務中處理，這樣很容易實現灰度發佈。

服務限流

在系統流量達到極限時的狀況，有自動熔斷機制。熔斷器是在服務或者周邊環境（如網絡）出現了異常後主動斷開客戶端後續的使用，從而避免服務崩潰沒法恢復。可是在後續時間熔斷將使用小量請求嘗試偵測服務是否已經恢復，若是恢復則將服務再次提供給客戶端調用。熔斷器的機制即保護了服務也減小了人工干預。相關的閥值都在是在配置中心中配置，並支持動態修改生效。限流必定要謹慎使用，要使用恰當的限流策略，區分正常訪問和惡意請求，不能將正常的用戶請求抹殺掉。若是沒法區分是不是惡意請求，須要將應用分級，確保優先級最高的應用能被訪問到，好比全部上線的商品信息。而對於下線的商品信息，能夠根據請求容量做適當的限流。

Nginx Rate Limiter是一個自主開發的防刷工具，經過Nginx上的LUA腳本插件，實如今Nginx上對本機的HTTP訪問進行限流控制的工具，以提升在促銷等高業務量環境下保障系統穩定運行的能力。

Nginx Rate Limiter經過RESTful API接口進行配置以及信息查看，能夠對全局進行開關等配置，也能夠針對指定URL分別添加多個限流配置，包括全局的限流。限流配置能夠選擇如下一種方式：

1. 最大訪問請求速率，超出則丟棄請求
2. 按比例丟棄請求。

服務降級

對於電商系統，爲了保證用戶體驗，在資源有限的條件下，咱們必須保證關鍵系統的穩定性。經過對不一樣業務級別定義不一樣的降級策略，對除核心主流程之外的功能，根據系統壓力狀況進行有策略的關閉，從而達到服務降級的目的，例如在線商品信息，咱們必須保證優先訪問，而對於下線的商品信息，咱們能夠允許在訪問容量受限狀況下，允許關閉下線商品詳情頁面的訪問等。

增長異步訪問

對於系統間實時性要求不高的操做，若是執行時比較耗時，可經過異步處理提升調用者性能，提升響應能力，尤爲經過異步調用通知非主要流程，加快了系統主要業務流程的反應速度和性能，異步處理機制可起到緩衝的做用，被通知的下游系統可依據自身能力控制處理數據量，避免遭受超負荷的衝擊，保證系統穩定運行，增長了系統可用性。

分佈式異步消息隊列服務器可在宕機後確保消息不丟失，異步系統有重試機制，從而提升系統可用性、健壯性和擴展性。

在用戶下單後，其餘系統如物流、供應商系統、配送、財務等系統須要獲取訂單詳情、訂單狀態，訂單系統經過異步消息方式將訂單的變化通知其它系統，異步調用實現系統間隔離解耦，上下游系統業務邏輯分離，下游系統只須要解析異步消息進行處理，不須要依賴上游系統的業務邏輯，從而下降了系統之間的依賴。即便下游系統出現異常，訂單系統仍然能正常處理數據。

多階段緩存，下降後端壓力

一、動靜分離，靜態化

靜態化可下降後端壓力，一方面經過用戶瀏覽器緩存靜態資源，失效時間經過cache-control來控制。另一方面經過CDN緩存，例如商品詳情頁面，爲了提升緩存效率，可將商品詳情頁面僞靜態化，將URL後綴顯示爲HTML，商品描述信息等靜態信息在有用戶訪問狀況下，緩存到靠近用戶的CDN節點，另外爲了提升CDN效率，提早將商品圖片推送到CDN。其它商品動態數據可動態加載，如商品運營信息、商品庫存、尺碼錶等，從而下降了避免沒必要要的後臺訪問。

二、分佈式緩存

引入分佈式緩存，對緩存數據服務節點作統一集中管理，可支持緩存集羣彈性擴展，經過動態增長或減小節點應對變化的數據訪問負載，經過冗餘機制實現高可用性，無單點失效，不會因服務器故障而致使緩存服務中斷或數據丟失。應用端使用統一的API接口訪問緩存服務器。

經過分佈式緩存，可作應用對象緩存、數據庫緩存、會話狀態及應用橫向擴展時的狀態數據緩存。

三、巧用應用服務器本地緩存

分佈式緩存雖然有效解決了訪問壓力，但因爲緩存服務器分佈在不一樣網絡端、不一樣數據中心中部署，隨着訪問量增大將致使I/O和帶寬瓶頸。爲此可將那些基本不修改的配置數據、全局數據能夠在應用服務器本地緩存，減小對後端緩存服務器實例的峯值衝擊。本地緩存須要謹慎使用，若是大量使用本地緩存，可能會致使相同的數據被不一樣的節點存儲多份，對內存資源形成較大的浪費。

使用緩存對提升系統性能有不少好處，可是不合理使用緩存非但不能提升系統的性能，反而成爲系統的累贅，甚至影響系統運做，產生很大的風險。對於頻繁修改的數據、沒有熱點的訪問數據、數據一致性要求很是高的數據，不建議使用緩存。

優化數據庫訪問

在高併發大數據量的訪問狀況下，數據庫存取瓶頸一直是個使人頭疼的問題。若是數據庫訪問出現性能問題，整個系統將受到影響。

爲此須要優化數據庫訪問，從如下幾個方面解決高併發問題：

• 優化複雜查詢，提升數據庫查詢效率，找出關鍵模塊的數據庫慢查詢進行優化。例如減小數據庫表之間的Join、重構數據庫表相關索引、對where子句進行優化等。
• 保證在實現功能的基礎上，儘可能減小對數據庫的訪問次數；經過查詢參數，儘可能減小對錶的訪問行數，最小化結果集，從而減輕網絡負擔；可以分開的操做盡可能分開處理，提升每次的響應速度，查詢時用到幾列就選擇幾列，下降數據庫訪問IO負載壓力。
• 基於電商系統讀寫比很大的特性，採用讀寫分離技術，經過一主多從，寫操做只發生在主表，多操做發生在從表上，能夠大大緩解對主數據庫的訪問壓力。
• 對業務和系統的細分，對數據庫表進行垂直拆分。將數據庫想象成由不少個"數據塊"（表）組成，垂直地將這些"數據塊"切開，而後把它們分散到多臺數據庫主機上面，從而能夠分散單位時間內數據庫訪問壓力。垂直切分的依據原則是：將業務緊密，表間關聯密切的表劃分在一塊兒。
• 垂直切分後，須要對分區後表的數據量和增速進一步分析，以肯定是否須要進行水平切分。對於核心數據如訂單，採起水平分區的方式，經過一致性哈希算法，利用用戶Id把訂單數據均勻的分配在各個數據庫分區上，在應用系統查詢時，以用戶ID調用哈希算法找到對應數據庫分區，從而將高峯時期的數據庫訪問壓力分散到不一樣數據庫分區上，從而實現數據庫的線性伸縮，極大提高數據庫的承載能力。
• 藉助於分佈式緩存，緩存提供了遠大於數據庫訪問的性能。當某一應用要讀取數據時，會首先從緩存中查找須要的數據，若是找到了則直接執行，找不到的話則從數據庫中找。在設計時，須要防止緩存失效帶來的緩存穿透壓力。
• 允許必定程度的數據冗餘，對於關鍵模塊，爲了防止對其它模塊的依賴而影響當前模塊的性能和可靠性，可適度保存其它模塊的關鍵數據，減小因爲訪問其它模塊服務帶來的系統損耗和可靠性壓力。
• 使用NoSQL數據庫對海量大數據進行存儲和處理。

增強系統監控

業務系統一般由衆多分佈式組件構成，這些組件由web類型組件，RPC服務化類型組件，緩存組件，消息組件和數據庫組件。一個經過瀏覽器或移動客戶端的前端請求到達後臺系統後，會通過不少個業務組件和系統組件，而且留下足跡和相關日誌信息。但這些分散在每一個業務組件和主機下的日誌信息不利於問題排查和定位問題的根本緣由。這種監控場景正是應用性能監控系統的用武之地，應用性能監控系統收集，彙總並分析日誌信息達到有效監控系統性能和問題的效果。經過監控信息，能夠清晰地定位問題發生緣由，讓開發人員及時修復問題。

惟品會有三級監控，系統/網絡層面監控、應用層面監控和業務層面監控。

系統/網絡層面監控，主要是對下列指標進行監控：服務器指標，如CPU、內存、磁盤、流量、TCP鏈接數等；數據庫指標，如QPS、主從複製延時、進程、慢查詢等。

業務層面監控，經過兩種方法，第一種在指定頁面作埋點，第二種方法從業務系統的數據庫中，將須要監控的數據抽取出來，作必要的分析處理，存入運維本身維護的數據庫中；而後經過瀏覽器頁面，展現監控數據，頁面同時提供各類時間維度上的篩選、彙總。對一些業務的關鍵指標如PV、UV、商品展現、登陸/註冊、轉化率、購物車、訂單數量、支付量、發貨量和各倉訂單數據。可自定義告警範圍，通知相關人以便作出響應。

應用層面監控系統Mercury，是惟品會獨立研發的應用性能監控平臺。經過在應用程序中植入探針邏輯來實現對應用代碼、關係數據庫、緩存系統的實時監控。Mercury經過收集日誌、上報日誌的方式即時獲取相關性能指標並進行智能分析，及時發現分佈式應用系統的性能問題以及異常和錯誤，爲系統解決性能和程序問題提供方即可靠的依據。同時經過Mercury數據展示平臺，用戶可輕鬆便捷的獲取應用360度監控信息。

在惟品會體系中，Mercury提供的主要功能包括：

• 定位慢調用：包括慢Web服務（包括Restful Web服務），慢OSP服務，慢SQL
• 定位錯誤：包括4XX，5XX，OSP Error
• 定位異常：包括Error Exception，Fatal Exception
• 展示依賴和拓撲：域拓撲，服務拓撲，trace拓撲
• Trace調用鏈：將端到端的調用，以及附加在此次調用的上下文信息，異常日誌信息，每個調用點的耗時都呈現給用戶
• 應用告警：根據運維設定的告警規則，掃描指標數據，如違反告警規則，則將告警信息上報到惟品會中央告警平臺

Mercury架構主要分如下幾大模塊：

日誌由客戶端傳輸到服務端後，分二條路徑。第一條路徑，裸日誌（Trace log / Exception log ）經過kafka，再經過flume直接落地到HBase。這些裸日誌用來查詢trace調用鏈信息和異常日誌。另外一條路徑，日誌信息經過kafka直接送到spark stream，經過spark分析後計算後，產生data points性能指標數據，再經過flume寫入OpenTSDB。整個傳輸過程最重要的就是保證數據消費不要丟失和積壓。

一旦知足經過運維人員事先配置的告警規則，告警模塊可觸發告警動做。告警信息可在第一時間將故障上報給中央告警平臺。

結束語

以上幾點是咱們對高併發系統的一些體會，咱們在不斷改進系統，爲將惟品會作大作強持續努力，也但願經過本次分享給你們帶來必定收穫。