《一步一步开发呼叫中心系列》
从上一篇《呼叫中心系统架构》发布至今,已经近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位系统注册表》。
这一篇没有什么呼叫中心相关的技术,权当发个博,报个到。
下一篇我们介绍三汇板卡事件模式的选择。
Technorati 标记: C#,呼叫中心,三汇