從上一篇《呼叫中心系統架構》發布至今，已經近3個月過去了，這3個月經歷了很多事情，一直沒有閑暇提筆繼續我的博客編寫，今天終於有了點時間，先來總結下這幾個月經歷的大事件。
1.可愛的寶寶終於出生了，雖然沒有如願以償地生個小公主，還是很激動很幸福。突然感覺人生的奮斗目標都變了。再也不一心想着自己要如何如何，做什么事情都首先想着如何能給寶寶提供更快樂的童年。在這里也感謝付出那么多辛勞的老婆大人，感謝在這段時間辛辛苦苦給我帶寶寶的老媽，沒有你們的支持，我的生活不會這么幸福。
2.呼叫中心系統賣出第一份之后，陸續賣出第二份、第三份……第N份，規模從10個坐席到200個坐席不等，從數字中繼線到模擬中繼線，期間遇到過各種問題，搞了N個通宵N個36H+的連續奮戰。
好了，廢話不多說，本篇繼續對呼叫中心相關技術進行總結。
在上一篇《呼叫中心系統架構》中，講到了呼叫中心的各個模塊以及相互之間的關聯，在本系統中，坐席軟件與坐席服務之間采用了純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.TryGetValue<string>("CtiAddress"); config.CtiPort = key.TryGetValue<int>("CtiPort"); config.IsTape = key.TryGetValue<int>("IsTape") == 1; config.TapePath = key.TryGetValue<string>("TapePath"); config.IsPlayJobNo = key.TryGetValue<int>("IsPlayJobNo") == 1; config.VoicePath = key.TryGetValue<string>("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位服務中不可讀取的問題。
關於注冊表32位與64的訪問問題，請參考園友的博客《C# 32位程序訪問64位系統注冊表》。
這一篇沒有什么呼叫中心相關的技術，權當發個博，報個到。
下一篇我們介紹三匯板卡事件模式的選擇。