[短多媒體訊息]C#短多媒體訊息模組開發設計（1）——架構

準備從以下幾個方面簡單的談談短多媒體訊息模組的實現：

[短多媒體訊息]C#短多媒體訊息模組開發設計（1）——架構（http://www.cnblogs.com/CopyPaster/archive/2012/12/07/2806776.html）
[短多媒體訊息]C#短多媒體訊息模組開發設計（2）——配置（http://www.cnblogs.com/CopyPaster/archive/2012/12/10/2811626.html）
[短多媒體訊息]C#短多媒體訊息模組開發設計（3）——協議（http://www.cnblogs.com/CopyPaster/archive/2012/12/12/2814918.html）
[短多媒體訊息]C#短多媒體訊息模組開發設計（4）——其他（http://www.cnblogs.com/CopyPaster/archive/2012/12/17/2821715.html）

      之前寫過一個多媒體訊息報文的博文（http://www.cnblogs.com/CopyPaster/archive/2012/04/28/2475240.html），其實主要的意思就是想把多媒體訊息報文貼出來給大家看看。因為根據當時我的所知，移動提供了Java版的API，但是卻沒有.Net版的，所以如果需要使用.Net開發多媒體訊息網關適配器服務，勢必需要自行構造多媒體訊息報文，所以把一個簡單的多媒體訊息報文貼出來給大家做個參考。不過我看評論，更多的大家是關注發送效率的問題。其實，從我開發短多媒體訊息的過程來看，短多媒體訊息協議本身其實只是研究和學習的一部分，其實更多的精力放在了如何在大資料量下系統互動、銜接能更快，更好，更安全上，那麼這裡把我對短多媒體訊息模組的一些認識談一下，我打算從幾個點來談，以後看時間會逐篇介紹，第一篇先來談整體架構。其實本文將的整體結構以及一些處理方法，不單適用短多媒體訊息應用，對於大資料量下，各模組互動、處理同樣很適用。

     先上一個張簡圖吧：

說明：

上層應用

    上層應用指的是：所有要下行簡訊的子系統，當然一般對於簡訊而言，看業務要求是否需要處理上行（對於多媒體訊息，協議上是支援上行的，不過一般很難碰到這樣的實際應用吧？我想可能只有做電視台的業務，可能會遇到多媒體訊息上行，比如使用者上行一個圖片多媒體訊息，然後主持人把圖片顯示給各位觀眾）；

     在上面的圖上，直接表達的意思是，所有需要發送短多媒體訊息的模組，如果要發短多媒體訊息，只要往Amq訊息佇列裡仍一條訊息即可，不過在我某個項目中的實際應用是：在中間檔了一層服務（短多媒體訊息平台），上層應用如果要發短多媒體訊息只要給短多媒體訊息平台發一條訊息，短多媒體訊息會給對應的Amq訊息佇列發送訊息。至於這個短多媒體訊息平台，我覺得一些做法和思想對於大資料量的處理和互動有協助，這裡把要點點一下，給大家參考參考。1）上層應用和短多媒體訊息平台訊息通訊採用RPC方式；對外提供dll介面給上層應用直接使用（我們實際中由於下行資料量比較大，短多媒體訊息平台是一組服務，並且有增加新平台的機制（我把這種處理方式稱之為分Pool，加新平台其實就是加Pool； 關於分Pool，簡單來講就是每個Pool是一組應用和資料庫的集合；Pool之上有一個Global，Global中包含全域服務和資料（比如Pool劃分規則）），每個平台只處理特定尾號的下行，為了隔離這種變化，所以對外提供dll介面，給上層應用直接使用，上層應用不需要關注某個下行最後會到那個短多媒體訊息平台處理）；2）短多媒體訊息平台除了需要考慮如何給Amq訊息佇列發送訊息外（後面的Amq訊息佇列從安全和效率上考慮，也是一組叢集，所以發送/接收訊息都需要額外考慮一些其他問題，這裡其實也是對於上層應用隔離這種變化），本身還有一些其他邏輯（黑名單過濾；去重驗證（去重很耗資源，每個平台自己維護一個B+樹處理）等）； 

 

Amq訊息佇列叢集

      Amq指的是ActiveMQ，我們為什麼用ActiveMQ？因為1）免費；2）MSMQ在處理跨機訊息首發不方便；關於ActiveMQ的一些配置、效能調優我之前有過博文說明，如果不瞭解ActiveMQ的可以去參考（http://www.cnblogs.com/CopyPaster/archive/2012/04/27/2473179.html）；關於對這個Amq隊列叢集的訊息收發原則需要說明一下：

1）訊息收發均採用長串連；收發方均需要自我維護一個串連池，如果收發一旦出現失敗，則將該串連狀態修改為不可用；自我維護的串連池需要另起線程定時檢查是否有不可用串連，並嘗試重連，如果串連成功，修改串連狀態為可用；（注意：使用Amq訊息佇列，其實有一個要注意的要點：快速消費訊息，避免訊息大量積壓。當然如果佇列服務器叢集多，自身記憶體大，這個積壓閥值可逐步增大；對於Amq隊列而言，Amq在短串連的情況之下其實沒有任何效率可言，所以一般均使用長串連方式處理；）

2）訊息發送方，每次發送訊息的時候，隨機播放一個可用的串連進行發送；

3）訊息接收方，監聽所有的串連（如果沒有訊息sleep一個較短時間；如果串連壞了sleep一個較長的時間）；

按照上面的規則其實即能達到負載的效果，也能起到熱主備的效果；

 

短多媒體訊息服務叢集

處理方式要點：

1）每個短多媒體訊息服務需要配合一套本機MSMQ訊息佇列來工作；短多媒體訊息服務在收到1條Amq隊列訊息之後，首先將訊息緩衝至本機MSMQ，這樣進一步做到對於Amq的快速消費；

2）對於收到的回執/狀態報表/上行資訊，服務首先將訊息緩衝至記憶體隊列；（一般來講，如果再某個應用情境下如果下行量很大，而且要求一定的發送速度，短多媒體訊息服務一般都是分省接入的，這樣對於接收這些資訊而言，其實是1個短多媒體訊息服務對接多個網關；當然了有些時候資料量不很大，只接一級網關的做法也有）；

3）對於短多媒體訊息服務而言，一般需要考慮流控、滑動視窗（多媒體訊息協議中沒有關於滑動視窗的描述，為了提高多媒體訊息發送速度，可以借鑒這個方法，另外多媒體訊息由於是http post，一般非同步處理，否則流控不好控制）、串連數（簡訊基於socket方式，協議中通過CMPP_ACTIVE_TEST進行鏈路檢測；多媒體訊息是無串連httpPost，此點不用考慮）

4）對於簡訊服務而言，如果是分身接入的，而且不是每個服務都能處理所有網關，需要考慮訊息的跳轉問題（在分省接入的情況下，一方面各省網關能力不同，一方面實際業務量各省也不同，或者因為串連數量不夠等因素，有時候並不需要某些“小省”所有簡訊服務都去跑，可能會出現這樣的問題）；

 

上下行曆史/回執/狀態報表匯入服務

一般來說如果下行量很大，那麼回執/狀態報表的量也很大，匯入服務的職責是將訊息佇列中的訊息，匯入資料庫持久；一般資料量大情況，可以採用大量匯入的方式（比如接收1萬條訊息之後，才用BatchInsert的方式寫入資料庫，才實際的過程中，往往採用批量入庫的方式，寫入資料庫花費的時間比接收這一批訊息本身時間還少）；