本文為系列第三篇，系統梳理 .NET Remoting 在設計選型、激活模式、通道格式化、封送策略、序列化優化等維度的性能調優實踐。
架構選型決策樹
- 同進程跨 AppDomain：首選 Remoting，輕量高效。
- 宿主選擇：IIS (自帶驗證、支援 NLB 負載均衡) vs Windows Service/Console (需自建安全、高性能)。
- 激活模式：
- SingleCall SAO：無狀態、每請求一實例、最佳擴展性、支援負載均衡。
- Singleton SAO：共享狀態、控制生命週期 (重寫
InitializeLifetimeService)、訪問同步資源。
- CAO：僅當客戶端需精確控制實例生命週期時使用。
- 通道與格式化器：
- TcpChannel + BinaryFormatter：內網高性能首選，二進制序列化最緊湊快速。
- HttpChannel + SoapFormatter：跨防火牆、異構互操作，性能較差，建議改用 Web Service/WCF。
- IIS 宿主時關閉 HTTP Keep-Alive (Remoting 短連接特性不適合長連接)。
封送策略：MBR vs MBV 選型矩陣
| 場景 | 推薦策略 | 理由 |
|---|
| 對象狀態綁定服務端資源 (DB連接、文件句柄、網絡連接) | MBR (MarshalByRefObject) | 狀態不可序列化/跨機無效，代理轉發調用 |
| 頻繁更新服務端數據 | MBR | 避免大對象反序列化開銷，僅傳遞調用 |
| 對象體積極大 | MBR | 按需拉取數據，而非整體傳輸 |
| 對象輕量、狀態需傳遞至客戶端、服務端少更新 | MBV (Serializable) | 本地調用無邊界開銷，適合只讀數據傳遞 |
| 頻繁更新但對象可拆分為多個小對象 | 小顆粒 MBV | 權衡序列化 vs 遠程調用開銷，針對非 blittable 類型尤有效 |
序列化與封送優化技巧
- 資料外觀模式：僅暴露客戶端關心的屬性子集，避免整個對象圖序列化。
- 優先基元類型/結構體：跨邊界調用昂貴，能本地計算不遠程調用；基元類型序列化無反射開銷。
[NonSerialized] 屏蔽無關字段：減少傳輸體積。- 鎖定 BinaryFormatter：拒絕 SoapFormatter 的 XML 開銷。
異步通訊與介面設計
- IO 密集型操作 (Remoting、Socket、DB) 必須異步調用，釋放線程池線程。
- 介面設計避免「對話式」細粒度調用，合併為粗粒度批量操作，最小化網絡往返。
- 避免在內存中持久化會話狀態，採用無狀態設計支撐水平擴展。
