關(guān)于新華社數(shù)據(jù)交換平臺發(fā)展的思考

文/張馳

背景

目前，新華社總社范圍內(nèi)的技術(shù)系統(tǒng)多達(dá)數(shù)十個，主要包括采編系統(tǒng)、發(fā)布系統(tǒng)、OA、數(shù)據(jù)庫及新華網(wǎng)等，此外還有31家國內(nèi)分社、11家海外總（大）分社。上述系統(tǒng)組成了一個以新華社總社為核心，規(guī)模龐大的分級式業(yè)務(wù)網(wǎng)絡(luò)。隨著新華社全媒體新聞事業(yè)的蓬勃發(fā)展，相關(guān)技術(shù)系統(tǒng)的數(shù)量在增加，隨之而來的各技術(shù)系統(tǒng)內(nèi)部、社內(nèi)各技術(shù)系統(tǒng)間、新華社技術(shù)系統(tǒng)與外部技術(shù)系統(tǒng)間的信息流轉(zhuǎn)越發(fā)頻繁，不同網(wǎng)域、不同系統(tǒng)、不同格式的信息共享、交換需求日益增多。

新華社通信系統(tǒng)始建于20世紀(jì)90年代，20多年來一直作為新華社的核心技術(shù)系統(tǒng)之一，主要承載著總社各系統(tǒng)、總社內(nèi)外網(wǎng)之間、總社與國內(nèi)外分社之間、與社外系統(tǒng)之間的數(shù)據(jù)交換工作。系統(tǒng)內(nèi)部處理的業(yè)務(wù)包括新華社文字、圖片、音頻、視頻、多媒體等成品數(shù)據(jù)，以及外媒新聞、外部接入的異構(gòu)數(shù)據(jù)等。多年來，隨著業(yè)務(wù)發(fā)展，通信系統(tǒng)也在持續(xù)進(jìn)行不同程度的業(yè)務(wù)擴(kuò)展及迭代，逐漸演變?yōu)橐粋€覆蓋面廣、實(shí)用性強(qiáng)的數(shù)據(jù)交換平臺，為全社乃至相關(guān)社外機(jī)提供基礎(chǔ)數(shù)據(jù)傳輸服務(wù)。

1.現(xiàn)狀及痛點(diǎn)

2010年前后，世界大步邁入移動互聯(lián)網(wǎng)時代。新聞生產(chǎn)及傳播的業(yè)態(tài)也發(fā)生了巨大變革，與之相關(guān)的技術(shù)系統(tǒng)必須快速響應(yīng)，順應(yīng)潮流。

對此，數(shù)據(jù)交換平臺作為新華社的基礎(chǔ)服務(wù)提供者，勢必需要做出調(diào)整，找到制約自身發(fā)展轉(zhuǎn)型的短板，對癥下藥。

1.1 系統(tǒng)架構(gòu)繁冗

近十?dāng)?shù)年來，隨著新華社新聞事業(yè)的快速發(fā)展，為了對接采編部門及終端用戶需求，先后涌現(xiàn)出不少技術(shù)系統(tǒng)。這些系統(tǒng)的網(wǎng)絡(luò)架構(gòu)各不相同，同時，各系統(tǒng)間均存在個性化的數(shù)據(jù)交互需求?；诖?，數(shù)據(jù)交換平臺通過部署在新華社內(nèi)網(wǎng)、DMZ區(qū)、外網(wǎng)、綠區(qū)交互區(qū)、綠區(qū)應(yīng)用區(qū)及私網(wǎng)等六個網(wǎng)絡(luò)區(qū)域的節(jié)點(diǎn)機(jī)（每個網(wǎng)域均部署有一到多臺節(jié)點(diǎn)服務(wù)器）完成本網(wǎng)域內(nèi)、跨網(wǎng)域間的數(shù)據(jù)匯聚、格式轉(zhuǎn)換、數(shù)據(jù)分發(fā)等數(shù)據(jù)交換工作。目前，數(shù)據(jù)交換平臺中擔(dān)負(fù)數(shù)據(jù)交換業(yè)務(wù)的節(jié)點(diǎn)服務(wù)器多達(dá)20余臺，各網(wǎng)域的接入交換機(jī)10余臺。硬件數(shù)量多，服務(wù)器主備機(jī)之間采用一對一冷備方式，業(yè)務(wù)布局分散，給系統(tǒng)管理員日常運(yùn)維造成了不小的壓力。

1.2 業(yè)務(wù)模式相對單一

多年來，數(shù)據(jù)交換平臺所提供的數(shù)據(jù)傳輸及數(shù)據(jù)處理等服務(wù)，無論是在內(nèi)部技術(shù)系統(tǒng)之間還是與外部用戶之間，基本均圍繞“文件”這一種數(shù)據(jù)形式展開。但隨著移動互聯(lián)網(wǎng)技術(shù)的蓬勃發(fā)展，新聞信息的傳播方式也相應(yīng)發(fā)生了巨大改變。比如我們看到通過消息驅(qū)動、借由API接口進(jìn)行數(shù)據(jù)交互的技術(shù)路線越來越多的出現(xiàn)在各類應(yīng)用場景中；RSS，數(shù)據(jù)訂閱等數(shù)據(jù)獲取及發(fā)布模式也被廣泛采用。相較之下，數(shù)據(jù)交換平臺沿用多年的僅基于文件及目錄的數(shù)據(jù)傳輸模式已無法很好地滿足業(yè)務(wù)需求，制約了自身的發(fā)展。

1.3 應(yīng)用程序功能的健全性及規(guī)范化

數(shù)據(jù)交換平臺作為傳輸中樞，上下游間交互的技術(shù)系統(tǒng)數(shù)量繁多，各系統(tǒng)在數(shù)據(jù)傳輸?shù)倪^程中或多或少都存在一些個性化的需求，如所采用的傳輸方式不同（socket或FTP），所采用的操作系統(tǒng)類型不統(tǒng)一（windows，linux，solaris），文件落盤的方式要求不盡相同（是否按日期結(jié)構(gòu)落盤，是否按照語種落盤，是否落多個實(shí)體等），甚至當(dāng)涉及國際網(wǎng)域間傳輸時的網(wǎng)絡(luò)條件是否要考慮數(shù)據(jù)校驗(yàn)及斷點(diǎn)續(xù)傳等。為了滿足不同的技術(shù)需求，提供個性化的服務(wù)，數(shù)據(jù)交換平臺內(nèi)的數(shù)據(jù)傳輸處理程序先后衍生出不同的版本，各版本在主要功能上類似，但細(xì)節(jié)上均有差異，不易于維護(hù)，在后續(xù)業(yè)務(wù)部署時容易造成混亂。

1.4 缺乏統(tǒng)一高效的業(yè)務(wù)監(jiān)控及管理手段

如前文所述，數(shù)據(jù)交換平臺目前所轄主要傳輸節(jié)點(diǎn)服務(wù)器逾20臺；平臺內(nèi)大部分應(yīng)用程序均基于C語言編寫，同時搭配一些shell腳本。基于這些原因，當(dāng)遇到日常系統(tǒng)故障排查及業(yè)務(wù)調(diào)整，需要系統(tǒng)管理員根據(jù)業(yè)務(wù)資料在數(shù)據(jù)鏈條中涉及的每臺服務(wù)器上通過命令性的方式進(jìn)行操作，效率較低且容易出錯。

2.未來調(diào)整的方向

以面向服務(wù)體系結(jié)構(gòu)(SOA)為框架，采取松散藕合方式構(gòu)建，提供數(shù)據(jù)接入、格式轉(zhuǎn)換、傳輸、回傳、查詢、檢索等不同的服務(wù)；能夠提供跨平臺數(shù)據(jù)交換服務(wù)，能夠?qū)?shù)據(jù)接入、轉(zhuǎn)換和傳輸過程實(shí)現(xiàn)集中統(tǒng)一控制和規(guī)范管理；針對每一條數(shù)據(jù)從接入系統(tǒng)開始，進(jìn)行全流程的管理和配置。

2.1 系統(tǒng)架構(gòu)設(shè)計

數(shù)據(jù)層面引入統(tǒng)一存儲。當(dāng)前，數(shù)據(jù)交換平臺系統(tǒng)架構(gòu)龐雜的一個重要原因在于被傳輸?shù)臄?shù)據(jù)均存放于各系統(tǒng)的本地文件系統(tǒng)中，因此需要在各網(wǎng)域部署傳輸節(jié)點(diǎn)，將同一份數(shù)據(jù)在不同網(wǎng)域間往復(fù)傳輸。統(tǒng)一存儲（如NAS）的引入，可以為此類問題提供一個解決方案。存儲網(wǎng)絡(luò)作為區(qū)別于服務(wù)器業(yè)務(wù)網(wǎng)絡(luò)獨(dú)立存在的一張網(wǎng)，可以滿足位于不同網(wǎng)域的服務(wù)器同時接入同一個存儲網(wǎng)絡(luò)，實(shí)現(xiàn)數(shù)據(jù)共享，在提高數(shù)據(jù)訪問時效性的同時大幅減少數(shù)據(jù)在服務(wù)器業(yè)務(wù)網(wǎng)間傳輸?shù)男枨?，?jié)省網(wǎng)絡(luò)資源。此外，NAS本身自帶訪問權(quán)限控制功能，通過對不同的接入用戶的讀、寫、執(zhí)行權(quán)限進(jìn)行細(xì)粒度的配置，可以確?；诮y(tǒng)一存儲上的數(shù)據(jù)安全性。因此，僅需要為暫時無法接入統(tǒng)一存儲的網(wǎng)域部署節(jié)點(diǎn)機(jī)即可，服務(wù)器的部署數(shù)量上與之前相比可大為減少。

計算資源、服務(wù)層面采用分布式部署，集群模式。依托統(tǒng)一存儲，無論稿件數(shù)據(jù)還是系統(tǒng)應(yīng)用數(shù)據(jù)均可以方便地在服務(wù)器之間實(shí)現(xiàn)共享。因此，數(shù)據(jù)交換平臺的計算資源完全可以按照服務(wù)功能進(jìn)行分布式部署，以集群的方式實(shí)現(xiàn)。這樣做的好處在于:首先，按照不同的服務(wù)功能進(jìn)行分布式部署，可以使不同的應(yīng)用模塊間的耦合度相對松散，在對業(yè)務(wù)進(jìn)行管理時邏輯更加清晰，快速定位問題所在；其次，由于實(shí)現(xiàn)了數(shù)據(jù)庫共享、配置文件共享，服務(wù)器層面可以很容易做到“雙活”乃至“多活”，相比于之前傳統(tǒng)的服務(wù)器一對一冷備，這種集群工作模式使業(yè)務(wù)運(yùn)行的穩(wěn)定性顯著提升，一旦一臺服務(wù)器出現(xiàn)應(yīng)用故障甚至宕機(jī)，集群中的其他服務(wù)器可以立即完成接管，業(yè)務(wù)完全不受影響，保證延續(xù)性。此外，集群模式為實(shí)現(xiàn)業(yè)務(wù)負(fù)載均衡提供了基礎(chǔ)，這對于一些流量集中的核心業(yè)務(wù)節(jié)點(diǎn)來說是十分重要的。

2.2 服務(wù)模式的升級

在過去以“文件”為中心的業(yè)務(wù)模式基礎(chǔ)上，增加并重點(diǎn)發(fā)展以“消息”為核心的業(yè)務(wù)模式。依托成熟的消息中間件，數(shù)據(jù)交換平臺內(nèi)部各應(yīng)用之間、數(shù)據(jù)交換平臺與外部系統(tǒng)之間的數(shù)據(jù)交互和服務(wù)調(diào)度都可以通過消息來實(shí)現(xiàn)。前文提到的“分布式部署”“服務(wù)器集群”就是通過消息驅(qū)動業(yè)務(wù)最直觀的實(shí)例。

將數(shù)據(jù)交換平臺常用的功能模塊，如格式轉(zhuǎn)換、數(shù)據(jù)分發(fā)甚至數(shù)據(jù)傳輸?shù)?，封裝成服務(wù)，通過發(fā)布的API接口供各相關(guān)系統(tǒng)調(diào)用。從關(guān)聯(lián)系統(tǒng)的角度看，通過調(diào)用數(shù)據(jù)交換平臺的服務(wù)接口拿數(shù)據(jù)，在拿到數(shù)據(jù)的同時也可以根據(jù)自身需求開發(fā)或部署相關(guān)的應(yīng)用對數(shù)據(jù)進(jìn)行靈活處理；對數(shù)據(jù)交換平臺來說，僅需要維護(hù)平臺內(nèi)的基礎(chǔ)功能模塊并確保接口的穩(wěn)定即可，不需過多考慮關(guān)聯(lián)系統(tǒng)的個性化需求。這樣使得系統(tǒng)間的邊界更加清晰明確。

2.3 系統(tǒng)應(yīng)用的健壯性和穩(wěn)定性

將程序進(jìn)行重構(gòu)，基于java和標(biāo)準(zhǔn)的J2EE規(guī)范實(shí)現(xiàn)，能夠保證應(yīng)用跨平臺平滑部署和實(shí)施，不再受操作系統(tǒng)平臺的局限；同時，在對有關(guān)數(shù)據(jù)傳輸程序的重構(gòu)過程中，將個性化的功能通過豐富配置文件內(nèi)容項(xiàng)進(jìn)行設(shè)置，主程序中對應(yīng)預(yù)留好相關(guān)功能入口即可。這樣可以基本確保系統(tǒng)管理員在對業(yè)務(wù)調(diào)整時不需要對主程序進(jìn)行太多修改，只需要重點(diǎn)對配置文件進(jìn)行操作即可。這樣可以保證應(yīng)用程序功能及版本的相對穩(wěn)定統(tǒng)一，同時也易于將應(yīng)用模塊打包，或以agent的方式部署在相關(guān)系統(tǒng)的接口機(jī)上。

2.4 管理監(jiān)控功能的升級

接入ELK實(shí)時日志分析查詢平臺，可以使日常業(yè)務(wù)監(jiān)控更便捷高效。

ELK是三個開源軟件的縮寫，分別表示Elasticsearch、Logstash、Kibana，它們都是開源軟件。新增了一個FileBeat，它是一個輕量級的日志收集處理工具，以Agent的方式裝在需要收集日志信息的服務(wù)器上，在各個服務(wù)器上搜集日志后傳輸給Logstash。

所有的日志數(shù)據(jù)采集并存儲后，Kibana可以為Logstash 和 ElasticSearch 提供日志分析友好的 Web 界面，可以幫助匯總、分析和搜索重要數(shù)據(jù)日志。

為了讓接入ELK日志平臺的數(shù)據(jù)使用起來更加高效，查詢及定位問題更加準(zhǔn)確，系統(tǒng)內(nèi)各應(yīng)用的日志輸出均必須遵循統(tǒng)一的標(biāo)準(zhǔn)。

系統(tǒng)硬件監(jiān)控:對系統(tǒng)內(nèi)所轄服務(wù)器的硬件情況進(jìn)行監(jiān)控，主要包括但不限于硬盤使用空間、內(nèi)存使用率等。這部分信息都可以通過提取操作系統(tǒng)的message信息及執(zhí)行簡單的shell命令獲得，并生成日志文件。

業(yè)務(wù)監(jiān)控:在重構(gòu)系統(tǒng)內(nèi)部各模塊的程序時，要按照統(tǒng)一的格式標(biāo)準(zhǔn)輸出日志。通過對日志內(nèi)與業(yè)務(wù)故障相關(guān)的字段進(jìn)行直、簡潔的設(shè)定，以求在接入ELK平臺后，能夠精確快速地檢索出故障信息。由于每臺服務(wù)器的日志信息都匯集到一起，因此，在日志平臺查詢時能夠做到集中展示，甚至通過一條數(shù)據(jù)在不同服務(wù)器上的日志留痕，將業(yè)務(wù)鏈條串起來，幫助系統(tǒng)管理員快速定位問題所在，并及時進(jìn)行處理。