PS：关于自动外呼的功能我在总体结构篇已经大概说过了，类似数据库设计、以及相关代码实现都不难，我就不多赘述了。这里主要介绍当时遇到的几个经过仔细思考过的设计思路。这几天整理的时候，发现当时还是缺乏很多的知识，考虑也没有很全面。这里仅仅写出来，供大家思考。
- 排队机制的处理
板卡上的电话通道是有限的（公司提供的板卡通道当时是40个），因此难免会遇到需要排队处理的情况。一旦进行排队，势必会有优先级的区分。
当时想当然准备做一个独立的排队模块，后来被自己否决了（图样图深破）。
一个是因为独立的话，不能分布式部署，意义不大；还有一个原因是外呼中的优先级有点特殊，因为即使某个业务需要优先处理，其他正在处理的业务也不能因为它而不给客户电话（没有那种绝对优先的场景）。
既然没有绝对意义上的优先排队需求，当时就换了个思路，将优先排队和板卡通道的数量联系在了一起。为每一个业务分配一个处理队列（每个业务本身肯定是先后优先的），每个处理队列，会分配不等的通道个数，这样就同时保证了任务的重要性分级和排队处理的需求（动态分配的设置方式有很多选择，这里就不多说了）。由于不考虑独立排队，以及跟板卡通道有紧密联系，因此处理队列组就放在了底层的呼叫中心服务。
- 和底层服务端之间通信方式的处理
通信方式使用的是socket。
客户端和服务端分别开启线程去接收监听到的消息。
客户端发送请求，服务端接收消息后，异步处理该请求。处理完成后，服务端将结果发送给客户端。（类似于异步回调）
公司内部使用服务端通信99%都是基于WCF的，这里使用socket的原因，其实还是学艺不精T_T~。
不过当时我这张破嘴居然把leader给忽悠过去了，想想也是牛逼的醉了^_^。
主要当时没研究过WCF（其实就是懒），不清楚有这种双向发送消息的模式。
其实使用WCF双工通信中的订阅发布模式，就能很好的解决这个需求了。（相关介绍网上很多，有兴趣的大家可以自行查阅）
- 任务执行流的设计
当时开发的时候，老大直接扔了一个某公司比较完善的外呼配置流程文档，居然可以使用类似图形控件的东西进行编辑（还特么的支持拖拽），一下子觉得长见识了。
后面老大要求我们也要这么灵活才行，瞬间我差点吓跪了。
后面就开始各种幻想，剔除了不切实际的东西，开始考虑流程这东西存储在计算机中是个什么样子，一下子想到了大学时候学过的数据结构——图（此处应该给我大学的周老师如雷贯耳般的掌声）。
然后想到了有向图这种有起始点、完结点和有向边的模型。（可能和标准的有一些差异）
主要要求时间有点紧，也没时间去仔细研究WorkFlow相关的东西，其实就是——懒~~~~
图片就不放了，网上一大堆，虽然跟原版的有差异，但大致是一样的。
下面是当时对于有向图流转模型的介绍（直接抄过来了，反正也是自己写的0_0）：
对于任务执行流，我们的目的是让任务按照预定的路线运行。
每一个运行都是一个单独的单元，连接运行单元的是一条条的有向线路。
首先会有唯一的一个开始节点和唯一的结束节点，中间按照模板加载成有向图，包含处理节点（顶点）和流转边（有向边）。
流转边中有通行条件，通行条件可以是服务端返回的处理结果，也可以自定义其他的条件（类似循环放音之类的阻塞条件），没有通行条件的为无条件边，可以无条件通行。
在处理时，首先执行开始节点（例如拨号），然后根据接收到返回事件通过边来找到接下来执行的一组节点（对于搜索，类似于广度优先，搜索到该事件能够到达的节点为止，因为设置的通行边中，应该只会有一个能通行才对），然后依次执行节点，直到到达结束节点后结束任务。
后记：当然这里仅仅只是一部分当时思考了比较久的东西。其实开发过程中，不免会遇到很多其他的问题。以大家的聪明才智应该可以很快解决才对，我这里就不献丑了~~~~