當前位置：首頁 > 编程语言 > C# >内容正文

C#

[短彩信]C#短彩信模块开发设计（2）——配置

發布時間：2023/12/9 C# 37 豆豆

生活随笔收集整理的這篇文章主要介紹了 [短彩信]C#短彩信模块开发设计（2）——配置小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

準備從以下幾個方面簡單的談談短彩信模塊的實現：

[短彩信]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）

????? 現在來說說配置，其實短彩信服務，拋開協議和通訊方式的差異外，整個處理過程是相似的，或者說基本一樣（當時在寫彩信服務的時候一度想把二者通過接口抽象寫到一個服務里去，不過從服務應職責單一原則和維護的角度來講，最終還是分開為好）。所以，這里以我在一個項目中短信模塊的配置來作為示例。本文的目的僅僅是希望大家通過配置的角度去看短彩信服務應該包括那些功能，另外一點就是跟前一次Blog去做一些具體的呼應。大家不用去一一關注我這里示范的所有配置（畢竟有些特定業務相關），可以根據自己實際情況參考和取舍，當然大家對于遺漏進行補充。

???? 下面現先看看配置（為了不依賴數據庫，索性全部基于xml，從多套服務共同部署運行的角度來講，一些配置節點集合寫入一個全局數據庫其實更合理；至于程序中如何將xml和相應對象的互相轉化，做法太多，第三方的、根據一定規則反射的……，這里不介紹了）：

SysConfigItem?

ServiceCode：服務代碼，日志分類、監控信息等需要用到；
RemotingServerPort：Remoting監聽端口；《[短彩信]C#短彩信模塊開發設計（1）——架構》里說過，如果分省接入，然后配置又不是每套服務都能處理所有網關，就需要消息跨機跳轉；這里用的的.net remoting，當然了比較老氣，改為RPC的方式更好；
MachineID：當前服務部署機器的ID，在跨機的時候也需要用到；
ResendTimeout：超時重發時間；
ResendCount：最大重發次數；
ActiveTestPeriod：與網關的心跳間隔（單位：秒）
DefaultIsmgID：默認網關ID；如果分省接入的時候，如果某個消息對應不到網關，則發給某認網關，一般配置為一級網關；
MoToAmqThreadCount：上行寫入Amq隊列線程數；《[短彩信]C#短彩信模塊開發設計（1）——架構》里說過Amq的收發原則；
MtRespToAmqThreadCount：下行寫入Amq隊列線程數；
MtReplyToAmqThreadCount：狀態報告寫入Amq隊列線程數；
AmqRetrySecond：Amq失敗重連間隔（當某個連接壞了的時候，自動重連時間間隔）
MobileSplitString：短信群發，手機號分隔符號（實際從cmpp2.1之后兼容了短信群發，協議中接收手機號碼是支持數組的，不過我們在項目中沒有使用，即使上層應用傳過來的群發手機號，實際的處理也是split成了N條消息給網關的）；
ServiceIntervalSecond：服務定時間隔（主要是配合監控系統使用，一到這個配置時間，服務會給監控服務發送心跳）；

AmqConnectionConfigItems?（Amq連接配置）

主要來配置Amq隊列的連接信息，從上面大家應該能看出：
1）我們使用了需要用戶名/密碼的方式去連接；
2）采用同步方式收發消息；
SleepSecond：如果隊列消息收空了，休眠時間；

AmqQueueConfigItems（Amq隊列配置集）

代碼中定義了一個QueueType的枚舉，根據此枚舉確定將回執/狀態報告/上行發送到Amq的哪個隊列之中；
QueueType：隊列類型；
QueueName：Amq隊列名稱；

ApplicationConfigItems（下行應用配置集）

業務中需要將某些消息在某些時間段內不發送，AmqLisenter如果發現某個隊列的配置不在規定時間之前，則停止接收消息，通過這樣的方式控制，不向網關發送消息；
AppCode：應用名稱；
AppQueueName：應用Amq隊列名稱；
BeginReceiveTime：開始接受時間；
EndRecevieTime：結束接收時間；

IsmgServerConfigItems（網關配置集）

ID：網關ID（本地MSMQ隊列會根據此命名和自動創建）
IpAddress：網關IP；
Port：網關端口；
SpCode：連接鑒權用戶名（網關用SpCode來區分接入的Sp，一般在連接鑒權時的用戶名字/密碼，用戶名都用spcode，所以配置名稱干脆做成了SpCode）；
SharedSecret：連接鑒權密碼；
MoConnectionCount：上行連接數；
MtConnectionCount：下行連接數；
CanWappush：是否支持Wappush；（wappush實際就是一種特殊短信）
ComputerWorker：這里其實就是配置是否所有服務能跑所有網關了；逗號切分；
MaxSendCount：單連接的最大發送速度；
IntelligentSlowing：是否智能降速（如果配置為true，則不根據MaxSendCount進行流控；）；

備注：

1）之所以要流控，就是因為如果發送過快，會把網關“壓跨”，往往的結果就是網關表現越差，發送約慢，而且這個慢一般非線性，是種激增；但是有時候高于網關給的流控閥值，網關也沒有表現出差，所以如何充分利用網關性能提高發送速度呢？智能降速就是一種方法。所謂智能降速就是，只要網關表現好，我就發；一旦網關表現不好（其實就是看下行延遲），我就降低速度；關于流控和智能降速，打算在第4次來說（[短彩信]C#短彩信模塊開發設計（4）——其他）；之前大家很關心的如何提高短彩信發送速度，這就是一種優化方案。

2）如果分省接的話，可能會遇到有些省同一個端口不同時支持上行和下行（現在華為，東軟，亞信，深訊啥的都做個一些省的網關；像深訊就是這樣用端口區分上下行）；所以在配置網關的時候，有些省可能需要配置2條信息；處理上行的把MtConnectionCount配成0(一般是7910) ，只處理下行的把MoConnectionCount配成0就可以了(一般是7890)。ID可以配置成CN.xx.1.\CN.xx.2.

MachineConfigItems

就是配置機器ID、IP、端口了沒啥好說（跨機的時候需要使用此配置）

RegionIsmgMappingConfigItems/RegionConfigItems

這兩個配置集，主要是我們項目中，上層應用傳過來的省代碼是數字（RegionID），短信服務需要配置本地MSMQ使用，程序會自動創建和使用各個隊列，那么用數字顯然可讀性不高，所以用RegionCode比較直觀（RegionCode也是本地MSMQ隊列名稱的一部分）；RegionIsmgMappingConfigItems則是把省和網關對應起來；

轉載于:https://www.cnblogs.com/CopyPaster/archive/2012/12/10/2811626.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的[短彩信]C#短彩信模块开发设计（2）——配置的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：（10.1）Python学习笔记二
下一篇：数论逆元