准備從以下幾個方面簡單的談談短彩信模塊的實現：
[短彩信]C#短彩信模塊開發設計（1）——架構（http://www.cnblogs.com/QLJ1314/archive/2012/12/17/2821965.html）
[短彩信]C#短彩信模塊開發設計（2）——配置（http://www.cnblogs.com/QLJ1314/archive/2012/12/17/2821978.html）
[短彩信]C#短彩信模塊開發設計（3）——協議（http://www.cnblogs.com/QLJ1314/archive/2012/12/17/2821988.html）
[短彩信]C#短彩信模塊開發設計（4）——其他（http://www.cnblogs.com/QLJ1314/archive/2012/12/17/2821993.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的方式寫入數據庫，才實際的過程中，往往采用批量入庫的方式，寫入數據庫花費的時間比接收 這一批消息本身時間還少）；