淘寶開放平臺（open.taobao.com）是阿里系統(tǒng)與外部系統(tǒng)通訊的最重要平臺，每天承載百億級的API調(diào)用，百億級的消息推送，十億級的數(shù)據(jù)同步，經(jīng)歷了8年雙11成倍流量增長的洗禮。本文將為您揭開淘寶開放平臺的高性能API網(wǎng)關、高可靠消息服務、零漏單數(shù)據(jù)同步的技術內(nèi)幕。

高性能API網(wǎng)關

阿里巴巴內(nèi)部的數(shù)據(jù)分布在各個獨立的業(yè)務系統(tǒng)中，如：商品中心、交易平臺、用戶中心，各個獨立系統(tǒng)間通過HSF（High-speed Service Framework）進行數(shù)據(jù)交換。如何將這些數(shù)據(jù)安全可控的開放給外部商家和ISV，共建繁榮電商數(shù)據(jù)生態(tài)，在這個背景下API網(wǎng)關誕生。

API網(wǎng)關采用管道設計模式，處理業(yè)務、安全、服務路由和調(diào)用等邏輯。為了滿足雙11高并發(fā)請求（近百萬的峰值QPS）下的應用場景，網(wǎng)關在架構上做了一些針對性的優(yōu)化：

1. 元數(shù)據(jù)讀取采用富客戶端多級緩存架構，并異步刷新緩存過期數(shù)據(jù)，該架構能支持千萬級QPS請求，并能良好的控制機房網(wǎng)絡擁塞。
2. 同步調(diào)用受限于線程數(shù)量，而線程資源寶貴，在API網(wǎng)關這類高并發(fā)應用場景下，一定比例的API超時就會讓所有調(diào)用的RT升高，異步化的引入徹底的隔離API之間的影響。網(wǎng)關在Servlet線程在進行完API調(diào)用前置校驗后，使用HSF或HTTP NIO client發(fā)起遠程服務調(diào)用，并結束和回收到該線程。待HSF或者HTTP請求得到響應后，以事件驅(qū)動的方式將遠程調(diào)用響應結果和API請求上下文信息，提交到TOP工作線程池，由TOP工作線程完成后續(xù)的數(shù)據(jù)處理。最后使用Jetty Continuation特性喚起請求將響應結果輸出給ISV，實現(xiàn)請求的全異步化處理。線程模型如圖所示。

在API調(diào)用鏈路中會依賴對元數(shù)據(jù)的獲取，比如需要獲取API的流控信息、字段等級、類目信息、APP的密鑰、IP白名單、權限包信息，用戶授權信息等等。在雙11場景下，元數(shù)據(jù)獲取QPS高達上千萬，如何優(yōu)化元數(shù)據(jù)獲取的性能是API網(wǎng)關的關鍵點。

千萬級QPS全部打到DB是不可取的，盡管DB有做分庫分表處理，所以我們在DB前面加了一層分布式緩存；然而千萬級QPS需要近百臺緩存服務器，為了節(jié)約緩存服務器開銷以及減少過多的網(wǎng)絡請求，我們在分布式緩存前面加了一層LRU規(guī)則的本地緩存；為了防止緩存被擊穿，我們在本地緩存前面加了一層BloomFilter。一套基于漏斗模型的元數(shù)據(jù)讀取架構產(chǎn)生。緩存控制中心可以動態(tài)推送緩存規(guī)則，如數(shù)據(jù)是否進行緩存、緩存時長、本地緩存大小。為了解決緩存數(shù)據(jù)過期時在極端情況下可能出現(xiàn)的并發(fā)請求問題，網(wǎng)關會容忍拿到過期的元數(shù)據(jù)（多數(shù)情況對數(shù)據(jù)時效性要求不高），并提交異步任務更新數(shù)據(jù)信息。

在雙11高并發(fā)的場景下，對商家和ISV的系統(tǒng)同樣是一個考驗，如何提高ISV請求API的性能，降低請求RT和網(wǎng)絡消耗同樣是一個重要的事情。在ISV開發(fā)的系統(tǒng)中通常存在這樣的邏輯單元，需要調(diào)用多個API才能完成某項業(yè)務，在這種串行調(diào)用模式下RT較長同時多次調(diào)用發(fā)送較多重復的報文導致網(wǎng)絡消耗過多，在弱網(wǎng)環(huán)境下表現(xiàn)更加明顯。

API網(wǎng)關提供批量API調(diào)用模式緩解ISV在調(diào)用RT過高和網(wǎng)絡消耗上的痛點。ISV發(fā)起的批量請求會在TOP SDK進行合并，并發(fā)送到指定的網(wǎng)關；網(wǎng)關接收到請求后在單線程模式下進行公共邏輯計算，計算通過后將調(diào)用安裝API維度拆分，并分別發(fā)起異步化遠程調(diào)用，至此該線程結束并被回收；每個子API的遠程請求結果返回時會拿到一個線程進行私有邏輯處理，處理結束時會將處理結果緩存并將完成計數(shù)器加一；最后完成處理的線程，會將結果進行排序合并和輸出。

TOP API網(wǎng)關暴露在互聯(lián)網(wǎng)環(huán)境，日調(diào)用量達幾百億。特別是在雙11場景中，API調(diào)用基數(shù)大、調(diào)用者眾多以及各個API的服務能力不一致，為了保證各個API能夠穩(wěn)定提供服務，不會被暴漲的請求流量擊垮，那么多維度流量控制是API網(wǎng)關的一個重要環(huán)節(jié)。API網(wǎng)關提供一系列通用的流量控制規(guī)則，如API每秒流控、API單日調(diào)用量控制、APPKEY單日調(diào)用量控制等。

在雙11場景中，也會有一些特殊的流量控制場景，比如單個API提供的能力有限，例如只能提供20萬QPS的能力而實際的調(diào)用需求可能會有40萬QPS。在這種場景下怎么去做好流量分配，保證核心業(yè)務調(diào)用不被限流。

TOP API網(wǎng)關提供了流量分組的策略，比如我們可以把20萬QPS的能力分為3個組別，并可以動態(tài)去配置和調(diào)整每個組別的比例，如：分組1占比50%、如分組2占比40%、分組3占比10%。我們將核心重要的調(diào)用放到分組1，將實時性要求高的調(diào)用放到分組2，將一些實時性要求不高的調(diào)用放到分組3。通過該模式我們能夠讓一些核心或者實時性要求高的調(diào)用能夠較高概率通過流量限制獲取到相應的數(shù)據(jù)。同時TOP API網(wǎng)關是一個插件化的網(wǎng)關，我們可以編寫流控插件并動態(tài)部署到網(wǎng)關，在流控插件中我們可以獲取到調(diào)用上下文信息，通過Groovy腳本或簡單表達式編寫自定義流控規(guī)則，以滿足雙11場景中豐富的流控場景。

使用集群流控還是單機流控？單機流控的優(yōu)勢是系統(tǒng)開銷較小，但是存在如下短板：

1. 集群單機流量分配不均。
2. 單日流控計數(shù)器在某臺服務器掛掉或者重啟時比較難處理。
3. API QPS限制小于網(wǎng)關集群機器數(shù)量時，單機流控無法配置。

基于這些問題，API網(wǎng)關最開始統(tǒng)一使用集群流控方案，但在雙11前壓測中發(fā)現(xiàn)如下一些問題：

1. 單KEY熱點問題，當單KEY QPS超過幾十萬時，單臺緩存服務器RT明顯增加。
2. 緩存集群QPS達到數(shù)百萬時，服務器投入較高。

針對第一個問題的解法是，將緩存KEY進行分片可將請求離散多臺緩存服務器。針對第二個問題，API網(wǎng)關采取了單機+集群流控相結合的解決方案，對于高QPS API流控采取單機流控方案，服務端使用Google ConcurrentLinkedHashMap緩存計數(shù)器，在并發(fā)安全的前提下保持了較高的性能，同時能做到LRU策略淘汰過期數(shù)據(jù)。

高可靠消息服務

有了API網(wǎng)關，服務商可以很方便獲取淘系數(shù)據(jù)，但是如何實時獲取數(shù)據(jù)呢？輪詢 ！數(shù)據(jù)的實時性依賴于應用輪詢間隔時間，這種模式，API調(diào)用效率低且浪費機器資源?；谶@樣的場景，開放平臺推出了消息服務技術，提供一個實時的、可靠的、異步雙向數(shù)據(jù)交換通道，大大提高API調(diào)用效率。目前，整個系統(tǒng)日均處理百億級消息，可支撐百萬級瞬時流量，如絲般順滑。

消息系統(tǒng)從部署上分為三個子系統(tǒng)，路由系統(tǒng)、存儲系統(tǒng)以及推送系統(tǒng)。消息數(shù)據(jù)先存儲再推送，保證每條消息至少推送一次。寫入與推送分離，發(fā)送方不同步等待接收方應答，客戶端的任何異常不會影響發(fā)送方系統(tǒng)的穩(wěn)定性。系統(tǒng)模塊交互如圖所示。

路由系統(tǒng)，各個處理模塊管道化，擴展性強。系統(tǒng)監(jiān)聽主站的交易、商品、物流等變更事件，針對不同業(yè)務進行消息過濾、鑒權、轉(zhuǎn)換、存儲、日志打點等。系統(tǒng)運行過程記錄各個消息的處理狀況，通過日志采集器輸出給JStorm分析集群處理并記錄消息軌跡，做到每條消息有跡可循。

存儲系統(tǒng),主要用于削峰填谷，基于BitCask存儲結構和內(nèi)存映射文件，磁盤完全順序?qū)懭?，速度極佳。數(shù)據(jù)讀取基于FileRegion零拷貝技術，減少內(nèi)存拷貝消耗，數(shù)據(jù)讀取速度極快。存儲系統(tǒng)部署在多個機房，有一定容災能力。

推送系統(tǒng)，基于Disputor構建事件驅(qū)動模型，使用Netty作為網(wǎng)絡層框架，構建海量連接模型，根據(jù)連接吞吐量智能控制流量，降低慢連接對系統(tǒng)的壓力；使用WebSocket構建 長連接通道，延時更低；使用對象池技術，有效降低系統(tǒng)GC頻率；從消息的觸發(fā)，到拉取，到發(fā)送，到確認，整個過程完全異步，性能極佳。

在消息系統(tǒng)中，一般有兩種消費模式：服務端推送和客戶端拉取。本系統(tǒng)主要面向公網(wǎng)的服務器，采用推送模式，有如下優(yōu)點 ：

1. 實時性高。從消息的產(chǎn)生到推送，總體平均延時100毫秒，最大不超過200毫秒。
2. 服務器壓力小。相比于拉取模式，每次推送都有數(shù)據(jù)，避免空輪詢消耗資源。
3. 使用簡便。使用拉取模式，客戶端需要維護消費隊列的位置，以及處理多客戶端同時消費的并發(fā)問題。而在推送模式中，這些事情全部由服務器完成，客戶端僅需要啟動SDK監(jiān)聽消息即可，幾乎沒有使用門檻。

當然，系統(tǒng)也支持客戶端拉取，推送系統(tǒng)會將客戶端的拉取請求轉(zhuǎn)換為推送請求，直接返回。推送服務器會據(jù)此請求推送相應數(shù)據(jù)到客戶端。即拉取異步化，如果客戶端沒有新產(chǎn)生的數(shù)據(jù)，不會返回任何數(shù)據(jù)，減少客戶端的網(wǎng)絡消耗。

在采用推送模式的分布式消息系統(tǒng)中，最核心的指標之一就是推送延時。各個長連接位于不同的推送機器上，那么當消息產(chǎn)生時，該連接所在的機器如何快速感知這個事件？

在本系統(tǒng)中，所有推送機器彼此連接（如圖所示），構成一個通知網(wǎng)，其中任意一臺機器感知到消息產(chǎn)生事件后，會迅速通知此消息歸屬的長連接的推送機器，進而將數(shù)據(jù)快速推送給客戶端。而路由系統(tǒng)每收到一條消息，都會通知下游推送系統(tǒng)。上下游系統(tǒng)協(xié)調(diào)一致，確保消息一觸即達。

評估消息系統(tǒng)另外一個核心指標是消息丟失問題。由于面向廣大開發(fā)者，因此系統(tǒng)必須兼顧各種各樣的網(wǎng)絡環(huán)境問題，開發(fā)者能力問題等。為了保證不丟任何一條消息，針對每條推送的消息，都會開啟一個事務，從推送開始，到確認結束，如果超時未確認就會重發(fā)這條消息，這就是消息確認。

由于公網(wǎng)環(huán)境復雜，消息超時時間注定不能太短，如果是內(nèi)網(wǎng)環(huán)境，5秒足矣，消息事務在內(nèi)存就能完成。然后在公網(wǎng)環(huán)境中，5秒遠遠不夠，因此需要持久化消息事務。在推送量不大的時候，可以使用數(shù)據(jù)庫記錄每條消息的發(fā)送記錄，使用起來也簡單方便。但是當每秒推送量在百萬級的時候，使用數(shù)據(jù)庫記錄的方式就顯得捉襟見肘，即便是分庫分表也難以承受如此大的流量。

對于消息推送事務數(shù)據(jù)，有一個明顯特征，99%的數(shù)據(jù)會在幾秒內(nèi)讀寫各一次，兩次操作完成這條數(shù)據(jù)就失去了意義。在這種場景，使用數(shù)據(jù)庫本身就不合理，就像是在數(shù)據(jù)庫中插入一條幾乎不會去讀的數(shù)據(jù)。這樣沒意義的數(shù)據(jù)放在數(shù)據(jù)庫中，不僅資源浪費，也造成數(shù)據(jù)庫成為系統(tǒng)瓶頸。

如上圖所示，針對這種場景，本系統(tǒng)在存儲子系統(tǒng)使用HeapMemory、DirectMemory、FileSystem三級存儲結構。為了保護存儲系統(tǒng)內(nèi)存使用情況，HeapMemory存儲最近10秒發(fā)送記錄，其余的數(shù)據(jù)會異步寫入內(nèi)存映射文件中，并寫入磁盤。HeapMemory基于時間維度劃分成三個HashMap，隨著時鐘滴答可無鎖切換，DirectMemory基于消息隊列和時間維度劃分成多個鏈表，形成鏈表環(huán)，最新數(shù)據(jù)寫入指針頭鏈表，末端指針指向的是已經(jīng)超時的事務所在鏈表。這里，基于消息隊列維護，可以有效隔離各個隊列之間的影響；基于時間分片不僅能控制鏈表長度，也便于掃描超時的事務。

在這種模式下，95%的消息事務會在HeapMemory內(nèi)完成，5%的消息會在DirectMemory完成，極少的消息會涉及磁盤讀寫，絕大部分消息事務均在內(nèi)存完成，節(jié)省大量服務器資源。

零漏單數(shù)據(jù)同步

我們已經(jīng)有了API網(wǎng)關以及可靠的消息服務，但是對外提供服務時，用戶在訂單數(shù)據(jù)獲取中常常因為經(jīng)驗不足和代碼缺陷導致延遲和漏單的現(xiàn)象，于是我們對外提供數(shù)據(jù)同步的服務。

傳統(tǒng)的數(shù)據(jù)同步技術一般是基于數(shù)據(jù)庫的主備復制完成的。在簡單的業(yè)務場景下這種方法是可行的，并且已經(jīng)很多數(shù)據(jù)庫都自帶了同步工具。 但是在業(yè)務復雜度較高或者數(shù)據(jù)是對外同步的場景下，傳統(tǒng)的數(shù)據(jù)同步工具就很難滿足靈活性、安全性的要求了，基于數(shù)據(jù)的同步技術無法契合復雜的業(yè)務場景。

雙11場景下，數(shù)據(jù)同步的流量是平常的數(shù)十倍，在峰值期間是百倍，而數(shù)據(jù)同步機器資源不可能逐年成倍增加。保證數(shù)據(jù)同步寫入的平穩(wěn)的關鍵在于流量調(diào)控及變更合并。

在數(shù)據(jù)同步服務中，我們使用了消息 + 對賬任務雙重保障機制，消息保障數(shù)據(jù)同步的實時性，對賬任務保障數(shù)據(jù)同步一致性。以訂單數(shù)據(jù)同步為例，訂單在創(chuàng)建及變更過程中都會產(chǎn)生該訂單的消息，消息中夾帶著訂單號。接受到該消息后，對短時間內(nèi)同一訂單的消息做合并，數(shù)據(jù)同步客戶端會拿消息中的訂單號請求訂單詳情，然后寫入DB。消息處理過程保證了訂單在創(chuàng)建或者發(fā)生了任意變更之后都能在極短的延遲下更新到用戶的DB中。

對賬任務調(diào)度體系會同步運行。初始化時每個用戶都會生成一個或同步任務，每個任務具有自己的唯一ID。數(shù)據(jù)同步客戶端存活時每30秒發(fā)出一次心跳數(shù)據(jù)，針對同一分組任務的機器的心跳信息將會進行匯總排序，排序結果一般使用IP順序。每臺客戶端在獲取需執(zhí)行的同步任務列表時，將會根據(jù)自身機器在存活機器總和x中的順序y，取得任務ID % x = y – 1的任務列表作為當前客戶端的執(zhí)行任務。執(zhí)行同步任務時，會從訂單中心取出在過去一段時間內(nèi)發(fā)生過變更的訂單列表及變更時間，并與用戶DB中的訂單進行一一對比，如果發(fā)現(xiàn)訂單不存在或者與存儲的訂單變更時間不一致，則對DB中的數(shù)據(jù)進行更新。

在雙11場景下如何保證數(shù)據(jù)同步的高可用，資源調(diào)配是重點。最先面臨的問題是，如果每臺機器都是冪等的對應全體用戶，那么光是這些用戶身后的DB連接數(shù)消耗就是很大問題；其次，在淘寶的生態(tài)下，賣家用戶存在熱點，一個熱點賣家的訂單量可能會是一個普通賣家的數(shù)萬倍，如果用戶之間直接共享機器資源，那么大流量用戶將會占用幾乎全部的機器資源，小流量用戶的數(shù)據(jù)同步實效會受到很大的影響。

為了解決以上問題，我們引入了分組隔離。數(shù)據(jù)同步機器自身是一個超大集群，在此之上，我們將機器和用戶進行了邏輯集群的劃分，同一邏輯集群的機器只服務同一個邏輯集群的用戶。在劃分邏輯集群時，我們將熱點用戶從用戶池中取出，劃分到一批熱點用戶專屬集群中。分組隔離解決了DB連接數(shù)的問題，在此場景下固定的用戶只會有固定的一批機器為他服務，只需要對這批機器分配連接數(shù)即可，而另一個好處是，我們可以進行指定邏輯集群的資源傾斜保障大促場景下重點用戶的數(shù)據(jù)同步體驗。

數(shù)據(jù)同步服務大集群的機器來源于三個機房， 在劃分邏輯集群時，每個邏輯分組集群都是至少由兩個以上機房的機器組成，在單個機房宕機的場景下，邏輯集群還會有存活機器，此時消息和任務都會向存活的機器列表進行重新分配，保證該邏輯集群所服務的用戶不受影響。 在機器發(fā)生宕機或者單個邏輯集群的壓力增大時，調(diào)度程序?qū)z測到這一情況并且對冗余及空閑機器再次進行邏輯集群劃分，以保證數(shù)據(jù)同步的正常運行。在集群壓力降低或宕機機器恢復一段時間后，調(diào)度程序會自動將二次劃分的機器回收，或用于其他壓力較大的集群。

訂單上存儲的數(shù)據(jù)結構隨著業(yè)務的發(fā)展也在頻繁的發(fā)生的變化，進行訂單數(shù)據(jù)的同步，需要在上游結構發(fā)生變化時，避免對數(shù)據(jù)同步服務產(chǎn)生影響，同時兼顧用戶的讀取需求。對此我們設計了應對結構易變數(shù)據(jù)的大字段存儲模型。在訂單數(shù)據(jù)的存儲模型中，我們將訂單號、賣家昵稱、更新時間等需要被當做查詢/索引條件的字段抽出獨立字段存儲，將整個的訂單數(shù)據(jù)結構當成json串存入一個大字段中。

這樣的好處是通過大字段存儲做到對上游業(yè)務的變化無感知，同時，為了在進行增量數(shù)據(jù)同步時避免對大字段中的訂單詳情進行對比，在進行數(shù)據(jù)同步寫入的同時將當前數(shù)據(jù)的hashcode記錄存儲，這樣就將訂單數(shù)據(jù)對比轉(zhuǎn)換成了hashcode與modified時間對比，提高了更新效率。

在雙11場景下，數(shù)據(jù)同步的瓶頸一般不在淘寶內(nèi)部服務，而在外部用戶的DB性能上。數(shù)據(jù)同步是以消息的方式保證實時性。在處理非創(chuàng)建消息的時候，我們會使用直接update + modified時間判斷的更新方式，替換傳統(tǒng)的先select進行判斷之后再進行update的做法。這一優(yōu)化降低了90%的DB訪問量。