《呼叫中心系统架构》中，讲到了呼叫中心的各个模块以及相互之间的关联，在本系统中，坐席软件与坐席服务之间采用了纯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位服务中不可读取的问题。
　　
　　大坝云呼叫中心全渠道客服系统