分布式消息队列在客服系统中的应用
引言：
企业的目标是：通过客服系统的建设，实现企业的服务品牌增值、运营成本领先、信息全面及时、营销准确高效等战略目标。企业首先是以为客户提供优质差异化客户服务为目标，以提升服务能力为重点，为客户提供分层的差异化、个性化的专业优质服务，提高客户忠诚度，树立客服的服务品牌；其次是通过客服应用进行客户交互信息收集分析，对客户交互信息进行整理、分析，包括客户信息、需求信息、使用信息等；最后是开展低成本、高效率、高收益营销活动，实现根据系统服务能力合理调配资源的目标，这里包括以下几个方面：
(1) 保证高端客户的优质服务，实现低端客户的成本控制；
(2)通过高频度的客户接触，减轻其他营销服务渠道的压力；
(3)利用客户呼入、主动呼出等机会积极开展营销；
(4)针对客户需求进行产品推广和主动营销；
(5)针对目标客户实施主动有效的营销及客户关系维护；
(6)针对有离网倾向的客户开展客户挽留；
(7)通过与客户的接触，挖掘潜在客户，配合其他渠道开展无缝隙的营销服务，为客户提供高效率的服务，降低企业整体的营销成本，实现客服的高效益的运作。
客服系统作为企业7×24h运行的系统，对系统的稳定性和性能要求非常高，需要在系统设计以及重构时重点考虑。
客服系统业务流程现状分析
现有客服系统业务流程如下。
(1)语音坐席登录客服系统，访问系统提供的浮动地址（例如URL地址为：http://192.168.101.10/tfcc10000/index.aspx）。
(2)通过F5负载均衡进行解析，从集群中具体分配一台服务器（如19）为坐席服务。
(3)外部客户通过IVR语音系统排队进入语音坐席。
(4)语音坐席需要查询该客户的客户资料、费用资料以及业务受理资料；通过服务能力平台访问外部系统服务（如CRM、计费）。
(5)语音坐席如能直接解决客户的问题，则直接办结；如不能解决，则需要留单，由后台工单处理人员进行处理。
(6)在服务过程中，系统记录业务的访问日志。具体流程如图1所示。
针对上述系统流程，对可以异步交互的如下节点引入分布式消息队列来提升系统的性能和系统的稳定性：
(1)现有话务数据在每一通电话后，实时入库，对数据库依赖大，对系统性能有影响，为摆脱对数据库的依赖，可以将话务数据写入分布式消息队列和本地文件；
(2)前台坐席门户和后台工单之间需要解耦，如果后台工单存在问题，无法为前台门户生成工单服务，则通过引入分布式消息队列，对系统进行解耦；
(3)后台工单功能点的复杂的判断逻辑，造成后端处理人员操作响应慢，通过引入分布式消息队列提升系统性能；
(4)在系统运维的日志记录中，通过引入分布式消息队列，写入系统埋点，为运维分析提供数据支撑。
客服系统中分布式消息队列场景使用剖析
3.1 话务数据入库使用场景说明
3.1.1 改进点
(1)现有系统每一通电话结束后，都要进行话务数据入库，要根据烦琐的业务规则进行判断，速度有很大提升空间。
(2)坐席门户和数据库依赖大，需要解耦坐席门户和数据库的关联。
(3)提升坐席门户的易用性、易维护性以及服务的轻量化。
3.1.2 解决方法
(1)为加快响应速度，可以在每一通电话结束后，产生话务数据，传递数据给MQ。 (2)由后端服务对分布式消息队列Rabbit MQ消费读取话务数据入库。
3.1.3 改正后的受理服务处理时序
每一通电话结束后，客服门户系统通过话务数据服务进行数据记录，写入MQ后，马上返回给前后门户应用，提升客服人员的感知。后续入库操作由MQ消费服务负责。具体流程如图所示。
3.1.4 改造前后性能对比
对话务数据入库使用场景引入分 布式消息队列后，通过对坐席前端操作数据和日志数据进行分析，前台页面操作响应时间提升2s；系统可靠性更高，数据发往分布式消息队列，与数据库解耦；服务轻量化，各对象职责明确，功能界面划分清晰。具体性能对比见表1。
3.2 坐席门户系统和工单系统分布式消息队列使用场景说明
3.2.1 改进点
(1)坐席门户生成工单时，需要访问工单系统，如果工单系统响应慢，影响前台坐席的服务，则需要重点考虑如何加快响应速度。
(2)坐席门户应用系统与工单系统解耦，两个系统不强关联，提升系统的可用性。
(3)提高接口通用性，提升易维护性。
3.2.2 解决方法
(1)在话务中心生成工单时，传递数据给工单中心的验证服务，确定数据合法，返回给前台话务。
(2)工单验证服务把数据传递给MQ。
(3)MQ消费读取数据，生成工单。
3.2.3 改正后的受理服务处理时序
调用方生成工单时，调用验证服务，验证正确后，返 回给调用方，提升反应速度。验证服务把生成工单数据发给 MQ，由MQ消费对数据进行处理。具体时序交互如图所示。
3.2.4 改造前后性能对比 对坐席门户系统调用后台工单系统的使用场景引入分布 式消息队列后，通过坐席前端操作数据和日志数据分析，前台页面操作响应时间提升4s；系统可靠性更高，前台门户和后台工单解耦；工单系统中生成工单的接口服务形成了共享服务，为整个企业提供生成工单接口的共享服务，可以服务 网上营业厅、微信公众号、短信客服等渠道。具体性能对比如图所示。
企业的目标是：通过客服系统的建设，实现企业的服务品牌增值、运营成本领先、信息全面及时、营销准确高效等战略目标。企业首先是以为客户提供优质差异化客户服务为目标，以提升服务能力为重点，为客户提供分层的差异化、个性化的专业优质服务，提高客户忠诚度，树立客服的服务品牌；其次是通过客服应用进行客户交互信息收集分析，对客户交互信息进行整理、分析，包括客户信息、需求信息、使用信息等；最后是开展低成本、高效率、高收益营销活动，实现根据系统服务能力合理调配资源的目标，这里包括以下几个方面：
(1) 保证高端客户的优质服务，实现低端客户的成本控制；
(2)通过高频度的客户接触，减轻其他营销服务渠道的压力；
(3)利用客户呼入、主动呼出等机会积极开展营销；
(4)针对客户需求进行产品推广和主动营销；
(5)针对目标客户实施主动有效的营销及客户关系维护；
(6)针对有离网倾向的客户开展客户挽留；
(7)通过与客户的接触，挖掘潜在客户，配合其他渠道开展无缝隙的营销服务，为客户提供高效率的服务，降低企业整体的营销成本，实现客服的高效益的运作。
客服系统作为企业7×24h运行的系统，对系统的稳定性和性能要求非常高，需要在系统设计以及重构时重点考虑。
客服系统业务流程现状分析
现有客服系统业务流程如下。
(1)语音坐席登录客服系统，访问系统提供的浮动地址（例如URL地址为：http://192.168.101.10/tfcc10000/index.aspx）。
(2)通过F5负载均衡进行解析，从集群中具体分配一台服务器（如19）为坐席服务。
(3)外部客户通过IVR语音系统排队进入语音坐席。
(4)语音坐席需要查询该客户的客户资料、费用资料以及业务受理资料；通过服务能力平台访问外部系统服务（如CRM、计费）。
(5)语音坐席如能直接解决客户的问题，则直接办结；如不能解决，则需要留单，由后台工单处理人员进行处理。
(6)在服务过程中，系统记录业务的访问日志。具体流程如图1所示。
针对上述系统流程，对可以异步交互的如下节点引入分布式消息队列来提升系统的性能和系统的稳定性：
(1)现有话务数据在每一通电话后，实时入库，对数据库依赖大，对系统性能有影响，为摆脱对数据库的依赖，可以将话务数据写入分布式消息队列和本地文件；
(2)前台坐席门户和后台工单之间需要解耦，如果后台工单存在问题，无法为前台门户生成工单服务，则通过引入分布式消息队列，对系统进行解耦；
(3)后台工单功能点的复杂的判断逻辑，造成后端处理人员操作响应慢，通过引入分布式消息队列提升系统性能；
(4)在系统运维的日志记录中，通过引入分布式消息队列，写入系统埋点，为运维分析提供数据支撑。
客服系统中分布式消息队列场景使用剖析
3.1 话务数据入库使用场景说明
3.1.1 改进点
(1)现有系统每一通电话结束后，都要进行话务数据入库，要根据烦琐的业务规则进行判断，速度有很大提升空间。
(2)坐席门户和数据库依赖大，需要解耦坐席门户和数据库的关联。
(3)提升坐席门户的易用性、易维护性以及服务的轻量化。
3.1.2 解决方法
(1)为加快响应速度，可以在每一通电话结束后，产生话务数据，传递数据给MQ。 (2)由后端服务对分布式消息队列Rabbit MQ消费读取话务数据入库。
3.1.3 改正后的受理服务处理时序
每一通电话结束后，客服门户系统通过话务数据服务进行数据记录，写入MQ后，马上返回给前后门户应用，提升客服人员的感知。后续入库操作由MQ消费服务负责。具体流程如图所示。
3.1.4 改造前后性能对比
对话务数据入库使用场景引入分 布式消息队列后，通过对坐席前端操作数据和日志数据进行分析，前台页面操作响应时间提升2s；系统可靠性更高，数据发往分布式消息队列，与数据库解耦；服务轻量化，各对象职责明确，功能界面划分清晰。具体性能对比见表1。
3.2 坐席门户系统和工单系统分布式消息队列使用场景说明
3.2.1 改进点
(1)坐席门户生成工单时，需要访问工单系统，如果工单系统响应慢，影响前台坐席的服务，则需要重点考虑如何加快响应速度。
(2)坐席门户应用系统与工单系统解耦，两个系统不强关联，提升系统的可用性。
(3)提高接口通用性，提升易维护性。
3.2.2 解决方法
(1)在话务中心生成工单时，传递数据给工单中心的验证服务，确定数据合法，返回给前台话务。
(2)工单验证服务把数据传递给MQ。
(3)MQ消费读取数据，生成工单。
3.2.3 改正后的受理服务处理时序
调用方生成工单时，调用验证服务，验证正确后，返 回给调用方，提升反应速度。验证服务把生成工单数据发给 MQ，由MQ消费对数据进行处理。具体时序交互如图所示。
3.2.4 改造前后性能对比 对坐席门户系统调用后台工单系统的使用场景引入分布 式消息队列后，通过坐席前端操作数据和日志数据分析，前台页面操作响应时间提升4s；系统可靠性更高，前台门户和后台工单解耦；工单系统中生成工单的接口服务形成了共享服务，为整个企业提供生成工单接口的共享服务，可以服务 网上营业厅、微信公众号、短信客服等渠道。具体性能对比如图所示。
分享到
