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

高性能API網關

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

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

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

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

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

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

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

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

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

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

使用集群流控還是單機流控？單機流控的優勢是系統開銷較小，但是存在如下短板：

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

基于這些問題，API網關最開始統一使用集群流控方案，但在雙11前壓測中發現如下一些問題：

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

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

高可靠消息服務

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

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

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

存儲系統,主要用于削峰填谷，基于BitCask存儲結構和內存映射文件，磁盤完全順序寫入，速度極佳。數據讀取基于FileRegion零拷貝技術，減少內存拷貝消耗，數據讀取速度極快。存儲系統部署在多個機房，有一定容災能力。

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

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

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

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

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

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

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

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

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

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

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

零漏單數據同步

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

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

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

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

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

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

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

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

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

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

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