《呼叫中心系統架構》中，講到了呼叫中心的各個模塊以及相互之間的關聯，在本系統中，坐席軟件與坐席服務之間采用了純TCP以及WCF兩種通信機制，其他模塊之間通信全部基于WCF，所以會存在A模塊需要知道B模塊、C模塊等提供的WCF服務地址，那么誕生了一個問題：如何配置這么多的凌亂的WCF或者TCP關聯地址信息？
　　
　　通常，我們的系統配置都是維護在數據庫或者配置文件中，我們來分析一下優劣勢（觀點僅限本系統架構，各個系統有各個系統的業務背景，不能一概而論）。
　　
　　1.采用配置文件來維護配置信息。
　　
　　這種方式是使用最廣的，開發成本最低的方式。但是明顯缺點比較多：維護以及修改的成本較高，如果其中一個節點提供的地址發生變更，很難將修改覆蓋到所有地方，經常會造成遺漏，從而影響系統穩定性。并且效率也比較低下，在緊急情況下，這種方式會帶來大量的時間消耗。很明顯，我們將這種方式排除在外。
　　
　　2.采用數據庫來維護配置信息。
　　
　　這種方式是普遍大家比較認可的好辦法：既做到了修改一個地方，所有地方都覆蓋了，又降低了時間消耗成本提高了效率，并且還可以做數據庫緩存服務，統一對外提供服務，提高系統運行效率。但是缺點也比較明顯：在系統部署好之前，數據庫訪問配置本身就是需要配置的，那如果數據庫地址或賬號信息發生變更，仍然脫離不了第一個方式引起的配置信息散亂分布問題。
　　
　　考慮到呼叫中心系統中，各個模塊消耗的資源并不是特別居高不下，從硬件層面，系統部署結構可能如下圖所示：
　　 　　
　　那么我們可以采用注冊表的方式，在同一臺服務器中，只維護一次配置信息，所有服務都共享此信息。
　　
　　在C#中，讀寫注冊表核心代碼：
　　
　　復制代碼
　　
　　/// summary>
　　
　　/// 從注冊表中讀取配置
　　
　　/// /summary>
　　
　　/// param name="key">/param>
　　
　　/// returns>/returns>
　　
　　internal static CtiServerConfig Load(Microsoft.Win32.RegistryKey key)
　　
　　{
　　
　　CtiServerConfig config = new CtiServerConfig();
　　
　　if (key != null)
　　
　　{
　　
　　config.CtiAddress = key.TryGetValuestring>("CtiAddress");
　　
　　config.CtiPort = key.TryGetValueint>("CtiPort");
　　
　　config.IsTape = key.TryGetValueint>("IsTape") == 1;
　　
　　config.TapePath = key.TryGetValuestring>("TapePath");
　　
　　config.IsPlayJobNo = key.TryGetValueint>("IsPlayJobNo") == 1;
　　
　　config.VoicePath = key.TryGetValuestring>("VoicePath");
　　
　　}
　　
　　return config;
　　
　　}
　　
　　/// summary>
　　
　　/// 將配置保存到注冊表
　　
　　/// /summary>
　　
　　/// param name="key">/param>
　　
　　public void Save(Microsoft.Win32.RegistryKey key)
　　
　　{
　　
　　key.SetValue("CtiAddress", this.CtiAddress);
　　
　　key.SetValue("CtiPort", this.CtiPort);
　　
　　key.SetValue("IsTape", System.Convert.ToInt32(this.IsTape));
　　
　　key.SetValue("TapePath", this.TapePath);
　　
　　key.SetValue("IsPlayJobNo", System.Convert.ToInt32(this.IsPlayJobNo));
　　
　　key.SetValue("VoicePath", this.VoicePath);
　　
　　}
　　
　　復制代碼
　　
　　注意：C#的注冊表讀寫操作，會有32位和64位的區別，由于本系統CTI采用的是64位編碼，所以出現了配置好的信息，在32位服務中不可讀取的問題。
　　
　　大壩云呼叫中心全渠道客服系統