文/張馳

背景

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

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

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

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

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

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

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

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

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

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

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

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

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

2.未來調整的方向

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

2.1 系統(tǒng)架構設計

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

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

2.2 服務模式的升級

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

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

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

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

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

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

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

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

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

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

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