千萬級到10億 的瘋漲，搜狗商業平台服務化體系實踐之路

【編者按】互聯網從誕生到現在，網站的規模不斷擴大，存儲和處理的數據量也遠遠超出了人們的想像，又隨著對信息實時性、多媒體需求大幅增長的現象，互聯網架構面臨越來越大的挑戰。CSDN致力於解決這一問題，在剛剛結束的 SDCC 2015中國軟體開發者大會上，特舉辦了架構專場，以及《程序員》電子刊10月B開設了架構專題。在接下來也將繼續深耕架構師、服務於開發者，推出更多的大牛訪談、知名互聯網公司架構實踐、技術公開課等，敬請期待。

本文是搜狗商業平台服務化體系實踐之路，作者是搜狗商業平台架構師么剛、搜狗高級開發工程師王宇，給你細細道來，以下為正文：

搜狗商業平台為打造搜狗一站式營銷服務平台提供基礎架構支撐，支持跨平台的廣告主及代理商的接入、廣告投放、效果評估、策略優化以及資金管理等。今年來搜狗業務飛速發展，在線廣告物料實現了千萬級到10億+的增長，天級報文量完成了百萬級到億級的跨越，而一年一度的6.18、11.11互聯網狂歡也更是對搜狗商業平台的基礎架構提出了嚴峻的考驗。

從技術層面，搜狗商業平台涵蓋了前端/後端框架、大數據分析、流式計算、移動研發等多個領域、不一而足。本文聚焦服務化，介紹搜狗商業平台服務化體系如何在業務規模幾何級數增長的情況之下，保證系統的高性能，高可靠性和高可擴展性。

搜狗商業平台根據自身的業務特點，在力求節約成本的前提下，打造了一套完整的服務化體系，如圖1所示。

圖1. 搜狗商業平台服務化體系

1. 源數據層：服務化數據來源，由不同的存儲介質組成，實現基礎性數據的持久化存儲；

2. 數據採集傳輸層：負責數據採集，並把數據由源數據層同步至緩存層。商業數據的特點決定了數據採集傳輸必須保證數據的可靠性和實時性；

3. 分散式緩存層：完成對基礎數據的加工，計算和分散式存儲，為服務層提供高效健壯的查詢服務；

4. 服務層：通過微服務的方式，快速迭代，滿足業務需求。

一、源數據層

商業平台的數據，按類型劃分為：結構化數據和半結構化數據，而存儲介質包括資料庫（MySQL，Oracle），文件和web service介面等。由於數據源的異構性，給我們上層的服務帶來三個問題：

1. 不易維護：針對每一個異構數據源，都必須開發一套相應的訪問組件，造成服務依賴關係複雜；

2. 運維困難：運維需要維護多種存儲介質，同時準備不同的擴容/縮容以及災備預案；

3. 性能不穩定：異構數據源的訪問介面性能存在一定的差異，在某些應用場景下，會導致服務的性能表現不穩定。

為此對源數據層做了兩方面的優化：

1. 數據源統一：針對關係型資料庫，我們採用MySQL作為基礎資料庫，逐步替代Oracle。針對半結構數據源文件和Web Service，我們從中提取出結構化數據，准實時同步到MySQL；

2. 資料庫組件統一：資料庫層面統一開發一套基於mysql的高性能嵌入式分庫分表框架。

二、數據採集傳輸層

「時間就是金錢」這句話在商業平台中體現得淋漓盡致，一個穩定可靠、低延遲的數據採集傳輸系統是整個服務化體系正常運轉的重要保證 (數據採集傳輸系統在內部也稱之為報文交換系統，在後文中也會用報文交換系統來統一標示)。

數據採集實現常用方式有兩種：

1. 應用驅動雙寫：應用程序同時向資料庫和消息系統發起寫操作，這種實現比較靈活，但是不能保證兩個系統同時鎖定操作，帶來不一致風險；

2. 資料庫日誌挖掘：從資料庫日誌（如MySQL的Binlog日誌）解析獲取資料庫變更事務，這個也可以解決一致性問題，同時有較高的同步性能。但是由於現有主流資料庫的日誌私有性，版本升級差異較大，難以保證系統升級可用性。

在評估這兩種方式優劣之後，我們採用了第二種（資料庫日誌挖掘）的方式，穩定可靠、低延遲是我們的首要目標(概要架構如圖2所示)。

1. 客戶端從系統獲取消息數據有兩種方式：全量和增量。客戶端第一次獲取數據時，可以從hdfs上拉取全量數據載入，完成之後再切換到增量服務通道獲取增量日誌，刷新數據。

2. 為了節約存儲空間，只存儲數據，不存儲數據描述（元數據）。

圖2. 報文交換系統概要

主要從三個方面保證報文交換系統的穩定可靠：

1. 序列號機制：報文交換系統並不需要強一致性，而是最終一致性。在日常的報文交換系統中，會產生上億條實時數據流，一旦出現數據亂序的情況，就破壞了系統的最終一致性要求。所以我們引入了序列號機制，為採集的每一條數據都分發一個有序的全局唯一ID，保證實時數據流的有序傳輸；

2. 數據重放機制：除了亂序，生產環境也可能出現數據丟失的情況。我們通過引入實時數據偏移量來解決這個問題。一旦數據出現丟失，可以通過指定任何時間點和一個偏移量，讓系統自動從這個時間點+偏移量開始重放數據；

3. 讀寫分離，跨機房多機部署：讀寫分離降低系統IO，跨機房、跨網段部署避免因網路或者機器故障導致系統不可用。

隨著廣告物料快速增長，系統容量也越來越大，瞬間產生的大流量往往會造成報文交換系統的同步延遲，而一個分鐘級以上的延遲都會對線上系統帶來較大的收益損失。所以我們採取以下三點優化來保證系統的低延遲：

1. 資料庫採取分庫分表策略存儲，按用戶ID水平拆分，數據並行採集；

2. 按照報文重要級，劃分為多個物理通道，通道之間不會互相干擾。一些對延遲容忍度低的可以走高速通道，一些對延遲容忍度高的可以走低速通道；

3. 非同步處理：在報文交換系統中，存在不同類型的報文，有些也需要額外二次加工處理，如果使用同步式處理的話，那這種block式的功能會非常影響系統性能。為了提高系統的吞吐量，我們把這些同步式優化成非同步式，不會堵塞其他重要報文，保證重要報文的通過性，降低延遲。具體應用如圖3。

三、分散式緩存

相對於K-V查詢以及正排倒排檢索系統而言，商業平台的查詢邏輯要複雜的多，經常涉及到多表聯合查詢，全表掃描等複雜查詢，傳統的RDBMS方案無法滿足查詢的性能要求，另外，底層數據源的異構也是RDBMS難以克服的問題。為此搜狗商業平台搭建了分散式緩存系統，作用有三：1. 降低物理資料庫壓力，提高查詢性能；2. 向上屏蔽底層數據的異構存儲；3. 向上提供類sql的查詢介面，支持微服務架構的快速迭代。隨著業務規模的飛速發展，分散式緩存系統也遇到了性能下降，內存膨脹過快，運維困難等問題。

1. 性能下降：主要出現在一些查詢在線物料量比較大的全屬性交叉運算上，運算涉及到過濾、聯表、業務邏輯計算、排序等步驟。即使是內存+索引，在非常大的數據量下，也會出現秒級別的超時；

2. 內存膨脹過快：分散式緩存是作為底層源數據的全鏡像，所以隨著在線物料量的快速增長，內存資源非常緊張；

3. 運維困難：由於架構涉及組件多，相互之間依賴複雜，耦合性高，給運維人員管理運維也帶來一定困難。

相對於資料庫，分散式緩存的查詢性能已經有了非常明顯的提升，但對於百萬量級的複雜查詢，性能仍不能滿足業務需求。為此在標準SQL查詢介面的基礎上，對於海量數據的複雜查詢，採取了預處理的方式，把結果預先計算出來並存儲在分散式緩存中。這樣查詢時可以節省SQL語句的執行時間，從而大大提升查詢性能。但是預處理方式也帶來了SQL結果狀態延遲的問題，為了保證基礎數據的變化能夠實時反映到SQL結果中，我們借鑒了流式計算的思想，當基礎數據發生變化時，觸發SQL語句的執行。示意圖4所示。

內存置換

數據冷熱不均的現象在商業平台也表現得十分明顯。通過監控我們發現90%。

左右的查詢請求集中於10%的熱數據。從節約硬體成本的角度出發，我們在分散式緩存系統中增加了內存置換的設計。通過極小的查詢性能的損耗，節約50%以上硬體成本。

1. 內存置換演算法：系統默認的內存置換演算法是標準的LRU演算法，可以很好的支持目前絕大多數的業務場景。為擴展性考慮，也可以通過配置選項，方便的支持LRU+LFU，LRU+對象大小等複雜置換演算法

2. 置換策略：通過監測內存使用的上下水位線，採用非同步置換的策略，將內存使用率始終維持在安全水平。

3. 數據預載入：對於節點冷啟動的情況，為了防止初始化時大量訪問未命中，穿透緩存到底層系統，可以採用預載入機制，提前把指定客戶數據載入到緩存。

內存置換示意圖如下圖5所示。

failover和可擴展性

1. 主從雙集群架構：分散式緩存採用主從雙集群架構，集群中採用多分片方式存儲。提供多路訪問通道，降低單機故障的影響範圍；

2. Failover訪問中間件：分散式訪問中間件引入自動探測機制，當一次訪問調用探測到某路訪問通道存在異常時，會自動切換到備選通道中。

3. 自動sharding：在水平擴展存儲容量時，通過熱緩存更新機制，將新分配的請求路由新節點上，就可以做到在不停服務下數據自動遷移。

四、服務層：

在搭建分散式緩存的同時，我們也注意到服務層存在較複雜的耦合關係，這也給服務化體系正常運轉帶來一些潛在風險。我們更需要一個松耦合的服務層。所以我們提出了微服務化。

微服務化：主要對分散式緩存上游服務進行解耦。目的是將一些功能模塊單獨做成一個個服務。我們可以為每個服務選擇一個新的適合業務邏輯的，業內比較成熟的存儲方案，比如Redis、MongoDB等，最終形成一個松耦合服務生態系統。這樣做的好處是顯而易見的：

總結

搜狗商業平台服務化體系承擔了物料存儲、廣告展現、數據分析到效果反饋等重要功能。在業務快速發展背景下，如何保證系統的高性能、高可靠、高可運維、高靈活性成為我們面臨的挑戰。

通過源數據層統一，搭建穩定可靠、低延遲的報文交換系統和高性能的分散式內存，以及微服務化的打造，初步完成商業平台服務化體系的建設，並成功支撐了在線物料量日增長上千萬級的業務發展規模。經歷了整個搜狗商業平台服務化體系實踐過程後，有以下幾個經驗心得：

作者介紹：

推薦閱讀：