關于新華社數據交換平臺發展的思考

文/張馳

背景

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

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

1.現狀及痛點

2010年前后，世界大步邁入移動互聯網時代。新聞生產及傳播的業態也發生了巨大變革，與之相關的技術系統必須快速響應，順應潮流。

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

1.1 系統架構繁冗

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

1.2 業務模式相對單一

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

1.3 應用程序功能的健全性及規范化

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

1.4 缺乏統一高效的業務監控及管理手段

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

2.未來調整的方向

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

2.1 系統架構設計

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

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

2.2 服務模式的升級

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

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

2.3 系統應用的健壯性和穩定性

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

2.4 管理監控功能的升級

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

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

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

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

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

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