通用報文解析服務的演進之路（基於磁盤目錄的分佈式消息消費者服務）之一

 通用報文解析服務，用C#開發，經歷了三版更新，支撐起了關區內的絕大多數數據交換業務，截止至今，每日收發報文約20萬，數據量約5G，平均延遲在1分鐘內。

回想起那些半夜處理積壓報文的場景，不勝唏噓，決定把這個演進過程向你們講述一下。回顧歷史，展望將來，若是能給你們一些啓發，是再好不過的了。

 

因爲某些歷史和非歷史緣由，咱們的數據交換在已經有IBMMQ等中間件作支撐的狀況下，還須要將報文落地到磁盤目錄下再作下一步解析、入庫。所以就有了這麼一個需求，基於磁盤目錄的報文解析服務。

初步計劃，按照演進過程當中的幾個版本分紅幾篇，咱們先從初版開始提及吧。

1、通用報文解析服務V1.0——可配置解析器類

在我來以前，最先的一版是大約兩千零幾年作的，當時的設計是這樣的：

這個程序最大的亮點就是解析器類ParserHandler是能夠經過配置自動加載的，原理很簡單就是反射Reflection。當因業務須要，有新的報文種類時，只要開發對應的解析器類，編譯成類庫，再將報文後綴和解析類添加到程序配置文件中便可。

解析器的基類是這樣定義的：

///<summary>
///解析器基類
///</summary>
public abstract class BaseHandler
{
    public abstract ParseResult Parse(FileReceiveInfo fileInfo);
}

其中ParseResult是枚舉，表明解析的結果。

public enum ParseResult
{
    Success,
    Warning,
    Error
}

FileReceiveInfo是接收到的文件信息，包括文件名、文件內容、接收時間等等，在此不一一列舉。

具體的解析器只要繼承BaseHandler，實現Parse方法。而後在配置文件中配置某一種擴展名，和這個解析器子類的全名，程序就會自動調用了。

 

起初報文數量較小時，系統運行仍是不錯的。它實現了預訂數據實時入庫的需求，支撐起了關區內的關鍵業務，並且它的高靈活性，可擴展性也給咱們留下了很深的印象。

可是缺點也是很突出的，主要以下：

1) 隨着業務量、報文種類的增多，出現了報文長時間積壓的問題，高峯時接收目錄中幾千上萬個報文，處理效率卻比平時還低。

2) 更要命的時，有時候一個報文解析出錯了，查他出錯的日誌成了很麻煩的事情，由於日誌文件相對單一的緣由，日誌文件變得很大，查起來很不方便。

3) 另外，解析過的歷史報文留存也是問題，想往後備查就要存不少文件在磁盤上，佔本地磁盤空間，還很差找。

因而決定打造第二代，旨在解決上述三個問題。

欲知後事如何，請聽下回分解。