千萬級到10億+的瘋漲，搜狗商業平臺服務化體系實踐之路
【編者按】互聯網從誕生到現在，網站的規模不斷擴大，存儲和處理的數據量也遠遠超出了人們的想象，又隨著對信息實時性、多媒體需求大幅增長的現象，互聯網架構面臨越來越大的挑戰。CSDN致力于解決這一問題，在剛剛結束的 SDCC 2015中國軟件開發者大會 上，特舉辦了架構專場（上午報報道、下午報道），以及《程序員》電子刊10月B開設了架構專題。在接下來也將繼續深耕架構師、服務于開發者，推出更多的大牛訪談、知名互聯網公司架構實踐、技術公開課等，敬請期待。
本文是搜狗商業平臺服務化體系實踐之路，作者是搜狗商業平臺架構師么剛、搜狗高級開發工程師王宇，給你細細道來，以下為正文：
聲明：本文為《程序員》電子刊11月B技術板塊文章，未經允許禁止轉載。
</div>挑戰
搜狗商業平臺為打造搜狗一站式營銷服務平臺提供基礎架構支撐，支持跨平臺的廣告主及代理商的接入、廣告投放、效果評估、策略優化以及資金管理等。 近年來搜狗業務飛速發展，在線廣告物料實現了千萬級到10億+的增長，天級報文量完成了百萬級到億級的跨越，而一年一度的6.18、11.11互聯網狂歡 也更是對搜狗商業平臺的基礎架構提出了嚴峻的考驗。
從技術層面，搜狗商業平臺涵蓋了前端/后端框架、大數據分析、流式計算、移動研發等多個領域、不一而足。本文聚焦服務化，介紹搜狗商業平臺服務化體系如何在業務規模幾何級數增長的情況之下，保證系統的高性能，高可靠性和高可擴展性。
搜狗商業平臺根據自身的業務特點，在力求節約成本的前提下，打造了一套完整的服務化體系，如圖1所示。
圖1. 搜狗商業平臺服務化體系
- 源數據層：服務化數據來源，由不同的存儲介質組成，實現基礎性數據的持久化存儲；
- 數據采集傳輸層：負責數據采集，并把數據由源數據層同步至緩存層。商業數據的特點決定了數據采集傳輸必須保證數據的可靠性和實時性；
- 分布式緩存層：完成對基礎數據的加工，計算和分布式存儲，為服務層提供高效健壯的查詢服務；
- 服務層：通過微服務的方式，快速迭代，滿足業務需求。 </ol>
- 不易維護：針對每一個異構數據源，都必須開發一套相應的訪問組件，造成服務依賴關系復雜；
- 運維困難：運維需要維護多種存儲介質，同時準備不同的擴容/縮容以及災備預案；
- 性能不穩定：異構數據源的訪問接口性能存在一定的差異，在某些應用場景下，會導致服務的性能表現不穩定。 </ol>
- 數據源統一：針對關系型數據庫，我們采用MySQL作為基礎數據庫，逐步替代Oracle。針對半結構數據源文件和Web Service，我們從中提取出結構化數據，準實時同步到MySQL；
- 數據庫組件統一：數據庫層面統一開發一套基于mysql的高性能嵌入式分庫分表框架。 </ol>
- 系統介紹：
- 應用驅動雙寫：應用程序同時向數據庫和消息系統發起寫操作，這種實現比較靈活，但是不能保證兩個系統同時鎖定操作，帶來不一致風險；
- 數據庫日志挖掘：從數據庫日志（如MySQL的Binlog日志）解析獲取數據庫變更事務，這個也可以解決一致性問題，同時有較高的同步性能。但是由于現有主流數據庫的日志私有性，版本升級差異較大，難以保證系統升級可用性。
- 客戶端從系統獲取消息數據有兩種方式：全量和增量。客戶端第一次獲取數據時，可以從hdfs上拉取全量數據加載，完成之后再切換到增量服務通道獲取增量日志，刷新數據。
- 為了節約存儲空間，只存儲數據，不存儲數據描述（元數據）。
- 穩定可靠：
- 序列號機制：報文交換系統并不需要強一致性，而是最終一致性。在日常的報文交換系統中，會產生上億條實時數據流，一旦出現數據亂序的情況，就 破壞了系統的最終一致性要求。所以我們引入了序列號機制，為采集的每一條數據都分發一個有序的全局唯一ID，保證實時數據流的有序傳輸；
- 數據重放機制：除了亂序，生產環境也可能出現數據丟失的情況。我們通過引入實時數據偏移量來解決這個問題。一旦數據出現丟失，可以通過指定任何時間點和一個偏移量，讓系統自動從這個時間點+偏移量開始重放數據；
- 讀寫分離，跨機房多機部署：讀寫分離降低系統IO，跨機房、跨網段部署避免因網絡或者機器故障導致系統不可用。
- 低延遲：
- 數據庫采取分庫分表策略存儲，按用戶ID水平拆分，數據并行采集；
- 按照報文重要級，劃分為多個物理通道，通道之間不會互相干擾。一些對延遲容忍度低的可以走高速通道，一些對延遲容忍度高的可以走低速通道；
- 異步處理：在報文交換系統中，存在不同類型的報文，有些也需要額外二次加工處理，如果使用同步式處理的話，那這種block式的功能會非常影 響系統性能。為了提高系統的吞吐量，我們把這些同步式優化成異步式，不會堵塞其他重要報文，保證重要報文的通過性，降低延遲。具體應用如圖3。
- 性能下降：主要出現在一些查詢在線物料量比較大的全屬性交叉運算上，運算涉及到過濾、聯表、業務邏輯計算、排序等步驟。即使是內存+索引，在非常大的數據量下，也會出現秒級別的超時；
- 內存膨脹過快：分布式緩存是作為底層源數據的全鏡像，所以隨著在線物料量的快速增長，內存資源非常緊張；
- 運維困難：由于架構涉及組件多，相互之間依賴復雜，耦合性高，給運維人員管理運維也帶來一定困難。
- 內存置換
- 內存置換算法：系統默認的內存置換算法是標準的LRU算法，可以很好的支持目前絕大多數的業務場景。為擴展性考慮，也可以通過配置選項，方便的支持LRU+LFU，LRU+對象大小等復雜置換算法
- 置換策略：通過監測內存使用的上下水位線，采用異步置換的策略，將內存使用率始終維持在安全水平。
- 數據預加載：對于節點冷啟動的情況，為了防止初始化時大量訪問未命中，穿透緩存到底層系統，可以采用預加載機制，提前把指定客戶數據加載到緩存。
- failover和可擴展性
- 主從雙集群架構：分布式緩存采用主從雙集群架構，集群中采用多分片方式存儲。提供多路訪問通道，降低單機故障的影響范圍；
- Failover訪問中間件：分布式訪問中間件引入自動探測機制，當一次訪問調用探測到某路訪問通道存在異常時，會自動切換到備選通道中。
- 自動sharding：在水平擴展存儲容量時，通過熱緩存更新機制，將新分配的請求路由新節點上，就可以做到在不停服務下數據自動遷移。
- 耦合性低：首先我們可以根據業務類型（讀多還是寫多等）、數據量來決定使用哪種類型的存儲方案，這樣可以減小內存緩存和單個數據庫的負載，同時也可以避免升級單個服務而影響全局的問題。
- 存儲和計算隔離：計算和存儲服務化隔離，避免存儲節點嵌入過多的業務邏輯計算，提高存儲節點的存儲能力和吞吐量。同時避免了計算節點有狀態，有利于提高計算節點的計算能力和高可用性。
- 快速迭代：優化核心功能，遷移邊緣功能，降低整個系統的復雜度和開發成本。實現方案是將每個大任務/系統拆解成一個個的較小任務/系統，使每個任務/系統做到足夠輕量級和友好，每個任務/系統之間松耦合，能夠快速迭代。
- 敢于做減法：大道至簡，在一個臃腫的系統上繼續加功能只會加重這個系統的負擔，更不利于系統的升級維護。要敢于做減法，提取出每個系統的核心 功能，減掉旁枝末節的功能。比如我們會實時監控每個系統功能的運行狀況，包括響應時間，調用次數等。并定期去清理一些低pv或者重要性偏低的系統功能，保 持系統輕量級；
- 微服務化：傳統服務架構上面搭建了非常多的應用，就像是一塊鐵板，笨重且不可拆分，系統中任何程序的改變都需要整個應用重新構建和部署新版 本。另外傳統的整體風格的架構在進行水平擴展時也只能整個系統擴展，而不能針對某一個功能模塊進行擴展。而微服務架構可以完美的解決統一風格架構所遇到的 種種問題。微服務架構將系統以組件化的方式分解為多個服務，服務之間相對獨立且松耦合，單一功能的改變只需要重新構建部署相應的服務即可；
- 不放過每一個細節：細節決定成敗。在對系統進行優化時，要仔細評估任何一個微小的細節。比如細粒度鎖的選取，數據結構的選型，內存池、連接池設計等，這些細節處理的好，會帶來意想不到的收獲。另外，在升級過程中，時時刻刻保留有計劃B，確保系統最終結果在可控的范圍。
- 么剛，搜狗商業平臺架構師，主要負責海量數據的分布式存儲和計算，解決分布式、高并發、強一致性等帶來的技術難題及挑戰，保障系統的健壯性，高性能和高可用性。
- 王宇，搜狗高級開發工程師，主要負責商業平臺報文系統和分布式緩存系統設計開發工作，目前主要關注分布式系統，大數據計算等相關技術。
一、 源數據層
商業平臺的數據，按類型劃分為：結構化數據和半結構化數據，而存儲介質包括數據庫（MySQL，Oracle），文件和web service接口等。由于數據源的異構性，給我們上層的服務帶來三個問題：
為此對源數據層做了兩方面的優化：
二、 數據采集傳輸層
“時間就是金錢”這句話在商業平臺中體現得淋漓盡致，一個穩定可靠、低延遲的數據采集傳輸系統是整個服務化體系正常運轉的重要保證 (數據采集傳輸系統在內部也稱之為報文交換系統，在后文中也會用報文交換系統來統一標示)。
數據采集實現常用方式有兩種：
在評估這兩種方式優劣之后，我們采用了第二種（數據庫日志挖掘）的方式，穩定可靠、低延遲是我們的首要目標(概要架構如圖2所示)。
圖2. 報文交換系統概要
主要從三個方面保證報文交換系統的穩定可靠：
隨著廣告物料快速增長，系統容量也越來越大，瞬間產生的大流量往往會造成報文交換系統的同步延遲，而一個分鐘級以上的延遲都會對線上系統帶來較大的收益損失。所以我們采取以下三點優化來保證系統的低延遲：
三、 分布式緩存
相對于K-V查詢以及正排倒排檢索系統而言，商業平臺的查詢邏輯要復雜的多，經常涉及到多表聯合查詢，全表掃描等復雜查詢，傳統的RDBMS方案 無法滿足查詢的性能要求，另外，底層數據源的異構也是RDBMS難以克服的問題。為此搜狗商業平臺搭建了分布式緩存系統，作用有三：1. 降低物理數據庫 壓力，提高查詢性能；2. 向上屏蔽底層數據的異構存儲；3. 向上提供類sql的查詢接口，支持微服務架構的快速迭代。隨著業務規模的飛速發展，分布式 緩存系統也遇到了性能下降，內存膨脹過快，運維困難等問題。
相對于數據庫，分布式緩存的查詢性能已經有了非常明顯的提升，但對于百萬量級的復雜查詢，性能仍不能滿足業務需求。為此在標準SQL查詢接口的基 礎上，對于海量數據的復雜查詢，采取了預處理的方式，把結果預先計算出來并存儲在分布式緩存中。這樣查詢時可以節省SQL語句的執行時間，從而大大提升查 詢性能。但是預處理方式也帶來了SQL結果狀態延遲的問題，為了保證基礎數據的變化能夠實時反映到SQL結果中，我們借鑒了流式計算的思想，當基礎數據發 生變化時，觸發SQL語句的執行。示意圖4所示。
數據冷熱不均的現象在商業平臺也表現得十分明顯。通過監控我們發現90%
左右的查詢請求集中于10%的熱數據。從節約硬件成本的角度出發，我們在分布式緩存系統中增加了內存置換的設計。通過極小的查詢性能的損耗，節約50%以上硬件成本。
內存置換示意圖如下圖5 所示。
四、 服務層：
在搭建分布式緩存的同時，我們也注意到服務層存在較復雜的耦合關系，這也給服務化體系正常運轉帶來一些潛在風險。我們更需要一個松耦合的服務層。所以我們提出了微服務化。
微服務化：主要對分布式緩存上游服務進行解耦。目的是將一些功能模塊單獨做成一個個服務。我們可以為每個服務選擇一個新的適合業務邏輯的，業內比較成熟的存儲方案，比如Redis、MongoDB等，最終形成一個松耦合服務生態系統。這樣做的好處是顯而易見的：
總結
搜狗商業平臺服務化體系承擔了物料存儲、廣告展現、數據分析到效果反饋等重要功能。在業務快速發展背景下，如何保證系統的高性能、高可靠、高可運維、高靈活性成為我們面臨的挑戰。
通過源數據層統一，搭建穩定可靠、低延遲的報文交換系統和高性能的分布式內存，以及微服務化的打造，初步完成商業平臺服務化體系的建設，并成功支撐了在線物料量日增長上千萬級的業務發展規模。經歷了整個搜狗商業平臺服務化體系實踐過程后，有以下幾個經驗心得：
作者介紹：