IVR Call center cti设计原则

一个呼叫中心的IVR系统，该用什么模式呢？ ivr系统应该是一个状态机模型，里面充斥着各种线路控制的状态和事件（空闲，震铃，挂机，放音，录音，加入会议，离开会议，两通道连接。。。。。）不过总的来说，线路部分的状态和事件不会很多，并且是不会经常变化的，可以看成是固定的就那几个。 然后，做应用的时候，业务逻辑引入的自定义状态就不可预料了。如何进行解耦？如何保证底层线路控制部分的纯洁不被业务逻辑所破坏？IVR系统是一个实时性要求很高的系统，同时也是一个并发量很高的系统（绝对不能用一个通道一个线程的方法，只能用状态机轮询）。IVR系统的底层可以是各个厂家的语音卡，可以是各个厂家的交换机，可以是来自IP的呼叫，甚至是短信，邮件等各种资源。这些应该要和业务逻辑完全分离。 我设想的是用分布式的进程来解耦。外围的线路资源（如语音板卡）做成独立的一个进程，不参与业务逻辑，做成一个只会做事，而不知道为什么做的“傻瓜”。 业务逻辑单独也是一个进程，和数据库打交道的也单独做成一个进程。。。。这样，处理业务逻辑的程序就是一个依照业务逻辑发号命令，但是不知道如何具体实现这些命令的人（COMAND模式？），其他的各类资源网关都和这个业务程序打交道，各资源网关彼此之间不打交道（中介模式？）。 如此思路下，那么一个业务流程的执行就大概如下了： 业务程序执行流程，发现需要对用户放音，就发个包（SOCKET通信）给板卡程序，发现需要执行一个存储过程，就发个包给数据库程序，发现需要发条短信，就发个包给短信程序，发现需要做****,就发个包给&&&&. 这样，板卡程序就只管听命令，对指定的通道放音，录音，加入会议之类。然后把底层线路的变化事件发包给业务程序，数据库程序也是，只管按要求执行存储过程，然后把结果发包给业务程序，短信。。。。等等。这样，整个系统就很容易拓展了，并且外围的程序也很容易编写，用三汇卡，就作个三汇卡函数封装的板卡程序，用AVAYA交换机，就做个对应的交换机程序。要IP应用，就做个IP网关程序等等。 然后，问题就是，这个最核心的业务程序怎么设计啊？该用那些模式来实例化业务流程？如何维护每个实例的状态？等等，期待大家的讨论，谢谢