編輯：Cynthia

吳瑞誠：斗魚數(shù)據(jù)平臺部總監(jiān)

曾先后就職于淘寶、一號店,。

從0到1搭建公司大數(shù)據(jù)平臺,、平臺規(guī)劃和團隊建設(shè)。

目前負責(zé)斗魚實時/離線數(shù)據(jù)處理、個性推薦系統(tǒng),、BI&DW和搜索引擎,。

背靠開源生態(tài)，應(yīng)用短平快的方式,，支撐起一個億級用戶的在線直播平臺,。

致力于數(shù)據(jù)平臺產(chǎn)品化、智能化,、云化,。

對高可用高并發(fā)的大數(shù)據(jù)平臺架構(gòu)和SOA架構(gòu)有深入的理解和實踐。

導(dǎo)讀：2016年是直播行業(yè)的元年,，斗魚在兩年內(nèi)發(fā)展成為擁有億級用戶和百萬級主播的直播平臺,，快速增長的同時也為技術(shù)帶來了高并發(fā)請求和海量數(shù)據(jù)的挑戰(zhàn)。同時公司系統(tǒng)技術(shù)棧多,、項目迭代周期快,、系統(tǒng)規(guī)模呈爆炸式增長。在這種背景下,，斗魚網(wǎng)站的架構(gòu)平臺該如何進行優(yōu)化,，才能支撐起如此迅猛的業(yè)務(wù)發(fā)展？斗魚的平臺技術(shù)會在哪些方面持續(xù)革新,？

本文詳解斗魚技術(shù)團隊通過對斗魚基礎(chǔ)架構(gòu)平臺的不斷改造與優(yōu)化,，形成當前能支撐千萬級用戶同時在線觀看的架構(gòu)平臺。適用于希望了解直播平臺基礎(chǔ)架構(gòu),、單體應(yīng)用的服務(wù)化改造,、直播平臺在支撐大型賽事活動所做的準備,。

一,、問題的提出

斗魚網(wǎng)站2014年上線至今，順應(yīng)直播行業(yè)趨勢的發(fā)展,，完成對交易系統(tǒng),、會員系統(tǒng)、統(tǒng)一登錄系統(tǒng),、彈幕系統(tǒng),、任務(wù)系統(tǒng)的重構(gòu)，并持續(xù)對架構(gòu)進行優(yōu)化,，針對客戶使用體驗拆分系統(tǒng),、提高研發(fā)效率、強化系統(tǒng)穩(wěn)定性和擴展性,。優(yōu)化主要針對以下三個方向：

●償還技術(shù)債--多語言技術(shù)棧交互,，臨時方案導(dǎo)致版本過多、邏輯錯綜復(fù)雜；

●系統(tǒng)可擴展性--服務(wù)與服務(wù),、服務(wù)與資源之間解耦,；

●服務(wù)化--微服務(wù)、服務(wù)治理,、容器化,。

二、實踐過程

2.1斗魚架構(gòu)平臺整體介紹

2015年初,，斗魚網(wǎng)站系統(tǒng)架構(gòu)主要分為兩大功能模塊：Web站和移動端,，這兩大模塊最初是從網(wǎng)站的單個工程中拆分出來的，是一個典型意義上的單體應(yīng)用,，也就是MartinFowler指的monolithic application,，這樣的系統(tǒng)主要有以下問題：

●各個業(yè)務(wù)模塊錯綜復(fù)雜，代碼復(fù)用率低,，臨時方案和功能開關(guān)多,，導(dǎo)致代碼可維護性較差；

●功能開發(fā)效率較低,，容易踩坑,，容易傷士氣；

●網(wǎng)站健壯性較差,。

斗魚去年（2015年）系統(tǒng)架構(gòu)如圖1所示：

圖1：斗魚2015年系統(tǒng)架構(gòu)

這個階段的系統(tǒng)會存在諸多瓶頸,，隨著網(wǎng)站用戶量的激增，斗魚全站的DAU超過2000萬,，整體架構(gòu)的服務(wù)化改造刻不容緩,。

在原應(yīng)用層中，剝離業(yè)務(wù)邏輯,，只負責(zé)應(yīng)用的流量接入,，具體的業(yè)務(wù)邏輯將由服務(wù)層承擔(dān)；在服務(wù)層中,，按照業(yè)務(wù)功能,，完成會員系統(tǒng)、房間系統(tǒng),、交易系統(tǒng),、個性推薦服務(wù)、彈幕系統(tǒng),、禮物系統(tǒng)等多個功能單元服務(wù)改造,。

這樣就形成了當前的系統(tǒng)架構(gòu)（圖2）：

圖二：斗魚當前（2016.12）系統(tǒng)架構(gòu)

在大型活動賽事時，每個功能單元的邏輯復(fù)雜度,、承擔(dān)的訪問量差別巨大,，為了能扛住活動期間的峰值,，需要對各個功能單元進行容量預(yù)估和擴容，這樣會直接驗證服務(wù)化改造的效果,。

2.2斗魚配置中心

整個服務(wù)化進程中,，會需要多個核心的基礎(chǔ)組件，先介紹一個核心組件——我們最先啟動的配置中心,。

在沒有配置中心時的狀態(tài)是這樣：

●配置散落在各工程中,，盤根錯節(jié)，配置改動成本大,；

●Dev,、Test、Stg,、Prod多套配置,；

●資源環(huán)境安全隱患；

●無法進行服務(wù)降級,。

梳理出配置中心的痛點,，列出配置中心的基本目標是：

●統(tǒng)一維護配置，方便新增及更改配置,；

●多套環(huán)境配置隔離,。

圍繞這個目標，通過兩個版本的迭代,，實現(xiàn)了以下特性：

●動態(tài)配置 ——自動拉取,、手動更新、對象動態(tài)重構(gòu)

●高可用——MySQL主從,、本地加密Snapshot

●數(shù)據(jù)源——MySQL,、Redis、MongoDB等

●集群配置——Kafka,、HBase,、Zookeeper、ES等

●配置項可繼承

此外,，對于中小公司,，安全隱患不容樂觀,，所以出于安全策略的考量,，還實現(xiàn)了：

●配置中心秘鑰安全認證

●配置服務(wù)添加IP白名單

●配置服務(wù)訪問頻率

在設(shè)計階段，針對已開源的Diamond（淘寶）和Disconf（百度）,，主要從配置存儲,、推拉模型、配置讀寫,、容災(zāi)模式,、安全性、配置、數(shù)據(jù)模型,、集群數(shù)據(jù)同步方面做了詳細對比,，對比發(fā)現(xiàn)兩套開源系統(tǒng)涉及技術(shù)棧較多、二次開發(fā)成本較大,，與現(xiàn)有系統(tǒng)集成的風(fēng)險較大,。

加之，配置中心并不復(fù)雜,，風(fēng)險可控,，并且自研的優(yōu)勢還有人員培養(yǎng)，自身對系統(tǒng)全貌能做到足夠熟悉,，后續(xù)新增功能特性和日常維護比較得心應(yīng)手,。事實證明，自研的選擇完全符合設(shè)計階段的預(yù)期,。

配置中心架構(gòu)如圖3：

圖3：配置中心系統(tǒng)架構(gòu)

整個配置中心主要分為四大部分：

●配置中心UI：配置項內(nèi)容維護,、配置項權(quán)限管理、配置項邏輯關(guān)系（繼承）,；

●服務(wù)層：配置服務(wù)接口,、安全認證、配置項持久化,；

●存儲層：配置內(nèi)存通過MySQL主從存儲,，中間有通過Redis實現(xiàn)緩存；

●客戶端：應(yīng)用本地保存配置snapshot加密文件,，提升安全性和可用性,，通過配置項MD5比對判斷是否更新，拉取配置后動態(tài)更新本地對象實例,。

在應(yīng)用代碼中,，只需以下代碼即可集成配置中心：

PropertiesConfigClient configClient = new

PropertiesConfigClient(

live/prod, //配置組

project, //配置所屬工程

config-file, //配置文件

refresh-interval); //更新頻率

configClient.getRequiredInt('data.query.page.size');//需使用配置項

當前，配置中心迭代中的版本主要是抽象資源類型,，這樣可以通過配置中心識別出服務(wù)依賴的資源,，包括接口、緩存,、存儲等,，并在此基礎(chǔ)上做服務(wù)依賴的全監(jiān)控。

對于配置項修改后的實時推送特性,，拉取模式現(xiàn)階段夠用,，暫時還沒有改造需求。如果需要新增,，可以集成Zookeeper,，通過Zookeeper的事件推送機制,，并配合改造配置中心客戶端的接收模式即可實現(xiàn)。

2.3斗魚統(tǒng)一日志監(jiān)控系統(tǒng)

有了配置中心,，可以以此實現(xiàn)服務(wù)的開關(guān)和降級,。但是在賽事活動期間，除了配置中心,，還需要監(jiān)控系統(tǒng)來識別系統(tǒng)狀態(tài),。

為什么需要做統(tǒng)一日志監(jiān)控系統(tǒng)？初衷包括：

●技術(shù)語言多樣,、臨時方案導(dǎo)致版本過多,、邏輯錯綜復(fù)雜；

●服務(wù)層級不多,，但是量大,，接口失敗后如何快速定位；

●開源組件二次開發(fā)能力弱,；

●需要短平快的實現(xiàn)方式,。

梳理出了最關(guān)心的監(jiān)控指標，主要包括：

●接口訪問量監(jiān)控

●HTTP 500監(jiān)控

●接口響應(yīng)時間監(jiān)控

●視頻流監(jiān)控

●系統(tǒng)錯誤日志監(jiān)控

●資源層監(jiān)控

●服務(wù)器性能監(jiān)控

梳理過程中,，我們發(fā)現(xiàn)：

●接口訪問量監(jiān)控,、HTTP 500監(jiān)控、接口響應(yīng)時間監(jiān)控,、視頻流監(jiān)控可以通過Nginx或者Web Server的log取到,；

●系統(tǒng)錯誤日志監(jiān)控能通過應(yīng)用日志取到；

●資源層監(jiān)控和服務(wù)器性能監(jiān)控可以通過Zabbix監(jiān)控實現(xiàn),。

方案設(shè)計階段,，主要對比了以下兩個方案：

●日志分段處理方案：在日志本地按時間區(qū)間分段切分日志文件，通過rsync將分段日志匯總,，解析并做聚合計算,，結(jié)果導(dǎo)入MySQL或者Redis，日志內(nèi)容導(dǎo)入HBase,，供查詢定位,。

●ELK（Elastic Search Logstash Kibana）方案：通過Logstash（日志收集Agent）tail抽取方式收集日志，寫到ES（Elastic Search,，以下簡稱ES）集群,，然后通過Kibana來查詢?nèi)罩尽?/p>

參與方案設(shè)計的同事傾向日志分段處理方案，主要是對各個組件都較熟悉,，每一步都可控,。但是考慮到實時性得不到保證，并且開發(fā)成本高,，所以決定搭測試環(huán)境小范圍試用,，最后發(fā)現(xiàn)ELK絕對神器。

當前監(jiān)控系統(tǒng)架構(gòu)圖如圖4：

圖4：監(jiān)控系統(tǒng)架構(gòu)圖

從架構(gòu)圖中可以看到關(guān)于統(tǒng)一日志監(jiān)控系統(tǒng)相關(guān)的數(shù)據(jù)流,，對于CPU敏感的日志宿主機,，使用Rsyslog作為Agent來實現(xiàn)日志收集。并且,，在Agent中精簡任務(wù),，只做最簡單的日志抽取?？焖賹懭氲終afka集群中,。日志數(shù)據(jù)從Kafka出來后有兩路去向：一路是經(jīng)由日志內(nèi)容解析，按照ES的index mapping解析日志,，然后寫入ES集群,；一路經(jīng)過實時計算系統(tǒng)（基于Storm實現(xiàn)），做聚合計算,，得到指定粒度Metric的值,，同樣寫入ES，需要在Dashboard中展示的指標會寫入Redis,。

基于ELK,，通過在基礎(chǔ)中間件中改造AOP日志的格式，還實現(xiàn)了滿足基本功能的全調(diào)用鏈監(jiān)控,，具體的AOP日志格式如圖5：

圖5 AOP日志格式

這套日志格式主要是參考Google 的Dapper論文,，關(guān)鍵是trace_id（全局唯一的方法調(diào)用ID，通常特定規(guī)則生成的UUID）和span_id（方法調(diào)用的層級ID）,，通過這兩個ID串聯(lián)起整個RPC調(diào)用鏈,。在日志中記錄RPC相關(guān)的所有方法調(diào)用信息，包括服務(wù)名,；方法開始時間和結(jié)束時間,，用以計算方法耗時；方便定位服務(wù)進程的host,、pid和服務(wù)端口,；定位問題時需要的入?yún)ⅰ]有記錄出參的主要原因是出參過大,，并且通過入?yún)⒅械臉I(yè)務(wù)字段,，能定位是在哪一級出的問題，現(xiàn)階段夠用,。

關(guān)于ELK的一些使用經(jīng)驗主要有：

●ELK vs. TSDB

日志系統(tǒng)最初Metric存儲是使用的基于OpenTSDB實現(xiàn)的一套存儲展現(xiàn)系統(tǒng),，后來在OpenTSDB的使用中碰到一些問題，例如HBase資源沖突,、數(shù)據(jù)壓縮,、區(qū)間查詢精度等問題,，另一方面ES的使用足夠省心，后來Metric存儲也逐漸以ES為主,。

●日志內(nèi)容的解析

最開始是在Agent中實現(xiàn),，tail抽取后逐條解析，這樣會大大降低日志的抽取效率,。接入Kafka中間層后,，改由使用Logstash從Kafka中讀取并解析，Logstash內(nèi)部存在CPU效率低的問題,，再改用Hangout（攜程開源的Java版Logstash,，主要是因為Logstash的CPU效率較低）。當前發(fā)現(xiàn)吞吐量仍然不理想,，正在改用原生Java多線程和Spark Streaming兩種方式來完成日志解析,。

●Elastic Search日志集群使用

斗魚現(xiàn)有6個ES集群、120個實例,，物理機配置32C/128G/6T*12,日均日志量約10T,，使用CMS的GC策略；堆大小使用官方推薦的32G,，適當增加-Xmn大?。粚τ诖笪锢頇C采用3實例同機部署,；為提升寫入吞吐量,，讀寫分離（配置ES截取呢拓撲）；盡量設(shè)置成不分詞,，即設(shè)置成not_analyzed,；設(shè)置合理refresh時間間隔，index_refresh_interval,；多集群通過搭建Proxy層來實現(xiàn)統(tǒng)一入口和權(quán)限控制,。

2.4大型賽事活動的運維保障

每次大型賽事活動的運維保障，就是一次平臺架構(gòu)的大考,。斗魚是怎樣做賽事運維保障的呢,？

首先，識別出最核心的服務(wù),。換言之就是要挑出那些不接受不可用的核心功能,，主要包括：

●直播視頻——斗魚內(nèi)容輸出的最核心功能；

●直播間列表——進入直播視頻的關(guān)鍵入口,；

●超管功能——保障內(nèi)容監(jiān)管的有效執(zhí)行,；

●彈幕服務(wù)——其他行業(yè)不常見，但是是直播中主要互動形式。本質(zhì)是消息推動,，但不同點是需要將用戶發(fā)布的彈幕內(nèi)容廣播給當前同一直播間的所有觀眾,，量級放大N級，需要將流量分發(fā),，減輕機房網(wǎng)絡(luò)帶寬壓力,；

●交易——這個無需解釋,。

其次,，針對各個核心功能進行容量評估，評估出需要預(yù)留的資源規(guī)模,，主要包括：

●CDN——下文會單獨列出,；

●緩存——業(yè)務(wù)功能依賴的各級緩存，包括Nginx緩存,、OpenResty的ngx.share.DICT,、Redis/Memcached、進程內(nèi)緩存,，盡可能兜住用戶請求,，不穿透到MySQL；

●資源隔離——盡量從物理上隔離,；

●降級——主要是各類開關(guān),，基于配置中心的網(wǎng)關(guān)開關(guān)、Web Server開關(guān),、接口開關(guān),、緩存開關(guān)等；

●監(jiān)控——監(jiān)控賽事期間線上全站和賽事直播間的水位狀態(tài),；

●機房——機房網(wǎng)絡(luò)狀態(tài),、主從災(zāi)備機房網(wǎng)絡(luò)狀態(tài)；

●HTTPS——直播行業(yè)第一家實現(xiàn)全站HTTPS,，保證終端用戶體驗,。

第三，CDN是保障的關(guān)鍵支撐,，主要包括靜態(tài)文件CDN和視頻流CDN,，視頻流是本文討論的主要內(nèi)容。主要包括以下準備內(nèi)容：

●接入多家CDN廠商,，通過統(tǒng)一入口調(diào)度,，可以針對不同網(wǎng)絡(luò)狀況實現(xiàn)流量切換；

●需要預(yù)備多條推拉流線路,，保障主播推流和用戶拉流可用,；

●建立CDN-SLA，建立包括視頻卡頓率,、首屏?xí)r間,、視頻延遲等監(jiān)控指標的CDN質(zhì)量評估體系,；

●與CDN廠商同步所有賽事信息，開通賽事熱線,，做好相應(yīng)值班安排,。

三、效果評價和總結(jié)

●經(jīng)過一年多架構(gòu)改造,，斗魚擁有能支撐起千萬級用戶同時在線觀看的能力,；

●ELK的版本更新快，需要及時跟進官方大版本,，并根據(jù)業(yè)務(wù)特點,，不斷進行優(yōu)化和調(diào)整。隨著熟悉程度的不斷加深,，會考慮更多的二次開發(fā)方案,，提升日志系統(tǒng)的整體吞吐能力和性能；

●持續(xù)跟進開源社區(qū)優(yōu)秀組件的發(fā)展,，例如Flink,、Spark Streaming、Elastic Stack等,，因地制宜引入合適技術(shù)框架提升系統(tǒng)承載能力,；

●現(xiàn)階段系統(tǒng)服務(wù)化的能力仍不健全，在服務(wù)治理,、服務(wù)容量預(yù)估,、服務(wù)擴容方向還有很長的路要走，服務(wù)化會持續(xù)推進,，朝著控制技術(shù)債雪球,、提升系統(tǒng)可擴展性、系統(tǒng)服務(wù)化的方向,，持續(xù)發(fā)力,。