微服务架构在客服系统中的应用
摘要：
随着5G、物联网以及云计算等技术的迅猛发展，以及中国电信自身业务的快速发展，对客服系统的交付与迭代速度和效率有了明确要求，必须为业务创新和业务持续提供一个良好的基础平台。微服务架构凭借其简单清晰、灵活可扩展、独立部署等优势，越来越成为分布式架构中的主流，成为传统客服系统重构的优先项。微服务架构通过服务的小型化、原子化以及分布式架构的弹性伸缩和高可用性，可以实现业务之间的松耦合、业务的灵活调整组合以及系统的高可用性。
一、客服系统现状分析
1、传统客服系统的问题
存在“烟囱式系统建设模式”，即每个系统单独建设,包括IVR系统、坐席门户系统、工单系统、运营管理系统，每个系统之间架构完全独立，独立开发和运维，其实系统之间都是有公共和通用功能的。对于烟囱式建设有三大弊端:每次新业务都需要重新造轮子，在功能建设和维护过程中带来投资浪费;打通烟囱式”系统间信息孤岛的成本高昂;不利于业务的创新、经验沉淀和业务持续发展。
2、客服系统单体化架构
传统客服坐席门户系统存在单体化架构，不利于企业的业务快速发展。存在如下弊端:不灵活，无法使用Spring Cloud等多种技术构建一体化应用;不可靠，例如客服系统CRM接口出现问题，也会造成整个系统不工作;不可扩展，应用无法轻易地被扩展，例如能力平台中计费的欠费能力发生变动时，都必须重新构建整个客服系统;阻塞持续集成，客服应用中的很多功能如计费专区、增值专区、宽带专区无法同时被构建和部署;迭代速度慢，客服门户系统- -个EAR包，代码需要很长时间来构建，例如智慧诊断、客户全视图、各专区等模块都无法并行构建，因此系统中任何程序的改变，都需要对整个系统进行重新编译部署，升级后需要大量人员留守测试验证，发现问题时需要反复部署测试验证，系统的水
平扩展也只能基于整个系统进行，无法针对某一个功能模块按需扩展。
3、传统客服系统设计缺陷
传统客服系统设计存在缺陷或者使用的框架本身存在一些不足 ，出现故障时不能快速地定位问题，甚至很长时间无法分析出问题原因,在没有分析到问题原因的情况下，只能规避问题的重现。针对上述系统之间存在的信息孤岛、单体化架构、 故障点多、新业务 需求满足慢等问题，亟需对传统客服系统进行微服务架构重构。
二、客服系统重构设计方案
鉴于以上的问题，客服系统重构解决方案按领域驱动设计(Domain-Driven Design,DDD)方法进行设计，DDD是一套 综合软件系统分析和设计的面向对象的建模方法，该方法要求接触到需求的第一步 就是考虑客服系统的领域模型，而不是将其切割成数据和行为，然后数据用数据库实现，行为用服务实现，最后造成需求的首肢分离。DDD首先考虑的是客服的业务语言，而不是数据，从客服的业务流程开始分析，形成业务架构。
1、客服业务流程分析
客户服务的顶层业务流程主要分为主动服务业务流程、被动服务业务流程两类。其中被动服务主要是客户发起的投诉、故障申告、咨询、业务处理、查询等流程，客服代表是被动服务;其中主动服务由客服代表发起，通过回访、客户关怀、维系挽留、营销、通知缴费等主动服务流程。客户服务顶层流程如图所示。
客户服务顶层流程
2、客户服务中被动服务典型流程分析
对客户服务中的被动服务流程，选取客户支撑的流程进行说明，如图所示。
客户服务被动服务的典型流程
(1)智能预检处理
客户通过服务请求单进入系统，首先进行智能预检处理,能在线处理的就在线处理并将工单办结，不能在线处理的则受理一张销单工单。
(2)全流程检测
如不能在线处理，则对受理工单进行端到端全流程检测，根据工单智能处理的检测结果，如不是线路问题，生成故障单，派往工单处理。
客服支撑部门联系用户，如能在线处理好的工单则直接办结，收集客户的反馈与归档;如不能在线处理则将工单派发到装维部门进一步处理。
(3)上门处理
如是线路问题,派往装维部门;装维部门通过接单、转派及联系用户进行上门处理，处理完以后进行回访，收集客户的反馈并归档。
3、客服系统主动服务营销流程分析
主动服务选取营销流程进行分析，如图所示。
客户服务主动服务的典型流程
(1)客户服务中心可通过10000号语音、短信、微信渠道主动对目标客户进行节假日关怀、回访、营销、维系挽留、催缴等业务。
(2)渠道人员先将目标用户导入到门户系统，再进行精准外呼,对有意向的用户受理商机工单。
(3)受理商机工单后，在内部进行工单流转及商机处理。订单受理成功后，安排装维人员上门服务，安装完成后，进行回访，收集客户的反馈并归档。
4、运营流程分析
运营流程包含录音质检、工单质检、运营监控、培训、考试、排班等，只对重点运营业务流程进行说明，其他流程不进行一一阐述，录音质检包含实时质检和事后质检。
(1)实时质检:后台支撑人员通过旁听、内部求助等功能实时支撑前台话务代表通话过程中的疑难问题。
(2)事后质检:制定质检计划，有计划地对中心客户录音进行质检，并通过质检报告分析中心话务服务质量;与智能语音引擎对接实现全中心录音准实时转写，进-步对客户意图进行分析、挖掘，提升中心业务服务水平。
运营支撑顶层流程
工单质检流程:
对工单处理及时率、工单回复及时率、工单内容填写规范性等内容进行质检。
工单监控流程:
(1 )提供现场监控、坐席监控、技能队列监控等话务实时监控功能，使后台支撑能快速掌握中心话务情况;
(2)提供接口调用监控、工单监控、热点话务监控等监控功能，实时监控中心热点事件以及周边系统调用情况。
培训考试流程:
(1 )提供员工在线培训功能，完成员工技能赋能，通常与考试功能配合使用，完成学习与技能检验的闭环;
(2)提供员工在线考试功能，并提供报表支撑。
排班流程:
通过运用科学合理的预测算法，结合呼叫中心现有运营的特征，精准地进行话务预测后实现自动排班，从而达到“在准确的时间，将有准确技
能的人，安排到准确的坐席上，上准确的班次， 同时达到合理的接通率"的目的。
3.2吝服系统业务架构
通过.上述业务流程分析，客户服务中心根据不同的业务拆分为:话务服务中心、运营服务中心、工单服务中心、公共服务中心4个客户服务能
力中心。
各服务中心功能
3.3客服系统应用架构
根据上述业务架构的结论，客服应用架构以统一应用服务平台(SaaS) 、统一平台服务(PaaS) 、统-基础服务(IaaS) 、统-接口平台进行构建。应用服务平台(SaaS) 为多媒体智能客服应用系统的坐席门户前台、IVR、 天翼客服、QQ客服、短厅、微博、微信客服等互联网客服提供统-服务。 应用服务平台按业务模块进行划分，各模块之间进行松耦合,为客服系统提供业务服务,分别为话务服务中心、工单服务中心、运营服务中心、公共服务中心提供共享服务。统-平台服务为整个客服系统提供公共的组件管理，方便系统扩展。统-基础服务为平台服务和应用服务提供公共的基础服务，例如引入集团提供的分布式缓存(Redis)、 分布式消 息队列、分布式数据库等基础服务。
客服系统整体应用架构
3.4客服系统数据架构
10000号业务模型的实体主要包括5个部分:客户、客户接触、交互事件、任务及工单。
(1)客户:客户是有能力成为电信产品的所有者、支付者，或者电信产品的使用者的个人或组织。现阶段中国电信的客户是指以产权关系界定
的、在同一登记证件名下的中国电信产品的所有者(人或组织)，是中国电信营销工作的对象和基本单元。
(2)客户接触:客户与中国电信产生的一次业务处理过程，都会产生一次或多次交互记录，一次客户交互可能产生一次或多次服务受理或业务办理，当中国电信向客户发起主动服务时也会产生一次或多次交互记录。
(3)交互事件:交互事件是指中国电信客户向中国电信所发起的咨询、查询、故障申告、投诉建议、业务申请等服务要求或中国电信主动向客户发起的客户挽留、客户关怀等主动服务。
(4)任务(内部发起) :任务是处理回访、客户关怀、营销计划时产生的需要分派给相关人员处理的工作事务。-个营销计划可以分解成多项任务派发给相关的人员。
(5)工单(客户发起) :工单是指客户代表不能对客户提出的问题直接答复，而进行留单，也就是为了完成某个交互事件或任务而派发的工作协同单。
客服系统E-R图示意
客服系统主要实体描述
(1)客户客户接触:一对多关系。
(2)客户接触客户交互事件:多对多关系。
(3)客户交互事件-事件类型:一个客户交互事件对应一个事件类型，一个事件类型对应一个到多个客户交互事件。
(4)工单客户交互事件:多对多关系。
(5)工单-工单类型:根据具体业务需求，派生出催办类工单、督办类工单、管理类工单、施工类工单、资源分配类工单、写作类工单等。
(6)任务-主动服务:多对多关系。
(7)任务根据人物，派生出客户关怀、客户回访、话费催缴、客户挽留、客户调查等任务单。
3.5客服系统技术架构
客服系统重构，技术架构采用Spring Cloud体系的微服务架构，Spring Cloud基于Spring Boot,为解决微服务体系开发中的架构问题，提供了一整套解决方案，专注微服务架构生态，通信协议采用Restful HTTP ,通过Spring Cloud分布式架构服务建设客户服务能力中心，对外提供客服的服务能力，输出智慧诊断、账务专区、流量专区服务、宽带专区服务、iTV专区服务、预判展示服务、投诉保障服务、业务查询服务、客服智能机器人等能力。
客服系统技术架构
本次重构采用中国电信集团提供的IaaS服务,缓存采用中国电信集团统一提供的分布式缓存服务，分布式消息中间件采用中国电信集团统提供的ROCKETMQ服务，数据库采用中国电信集团统-提供的My SQL分布式数据库服务。
通过Spring Cloud微服务体系提供PASS服务，即服务注册中心、配置管理中心、服务监控中心、服务跟踪分析、服务网关、服务保障中心等平台服务。
通过对不同的业务梳理形成不同的客户服务能力，如业务查询能力、流量专区服务、-键诊断等应用服务能力，通过这些共享服务，完成话务服务中心、工单服务中心、运营管理中心、公共服务中心的构建。
4客服接口管理微服务化过程
在客服人员服务客户的过程中，需要把企业中所有IT系统牵涉到该客户的信息汇聚到客服系统中，方便客服人员全面了解客户信息，所以在客服系统中对其他系统接口的管理非常重要。通过接口管理微服务化这个实例来阐述微服务架构重构过程。
4.1接口管理前端(前端SaaS)
接口管理前台界面功能包括查询、修改等服务。
接口管理前端界面
4.2接口服务(PaaS)
通过对接口管理服务进行封装，再通过Service层实现该服务，为前台界面服务。
4.3服务治理
在接口服务的Spring Boot工程的启动application类上加上注解@EnableEurekaServer,同时配置好配置文件，该接口服务启动后会自动注册到Spring Cloud的套件注册中心Erureka Server中。
4.4数据服务
通过封装数据访问接口服务访问集团分布式数据库，为借口服务提供数据服务。接口管理的微服务过程整体如下:通过数据服务访问分布式数据库，该数据服务作为数据微服务单独部署;接口服务通过访问数据服务来服务前台界面，该接口服务作为一个服务单独部署;服务治理通过Spring Cloud提供的服务注册中心、配置管理中心、服务监控中心、服务跟踪分析、服务网关、服务保障中心来实现。前台界面调用接口微服务完成接口管理。
总结：
通过按领域驱动设计方法的重构,把客户服务中心分为话务服务中心、工单服务中心、运营服务中心以及公共服务,打造了客服系统的共享服务体系,性能显著提升，方便业务创新，能快速适应业务需求，解决信息孤岛，为企业的数据中台发挥大数据威力提供客服的数据储备。本次重构虽带来很多好处，但因业务的微服务化，造成平台出现错误时很难定位问题，在实施阶段企业为业务中台统-打造了数字化运营能力来解决该问题，该解决方案已经上线，可以解决微服务定位难的问题。
随着5G、物联网以及云计算等技术的迅猛发展，以及中国电信自身业务的快速发展，对客服系统的交付与迭代速度和效率有了明确要求，必须为业务创新和业务持续提供一个良好的基础平台。微服务架构凭借其简单清晰、灵活可扩展、独立部署等优势，越来越成为分布式架构中的主流，成为传统客服系统重构的优先项。微服务架构通过服务的小型化、原子化以及分布式架构的弹性伸缩和高可用性，可以实现业务之间的松耦合、业务的灵活调整组合以及系统的高可用性。
一、客服系统现状分析
1、传统客服系统的问题
存在“烟囱式系统建设模式”，即每个系统单独建设,包括IVR系统、坐席门户系统、工单系统、运营管理系统，每个系统之间架构完全独立，独立开发和运维，其实系统之间都是有公共和通用功能的。对于烟囱式建设有三大弊端:每次新业务都需要重新造轮子，在功能建设和维护过程中带来投资浪费;打通烟囱式”系统间信息孤岛的成本高昂;不利于业务的创新、经验沉淀和业务持续发展。
2、客服系统单体化架构
传统客服坐席门户系统存在单体化架构，不利于企业的业务快速发展。存在如下弊端:不灵活，无法使用Spring Cloud等多种技术构建一体化应用;不可靠，例如客服系统CRM接口出现问题，也会造成整个系统不工作;不可扩展，应用无法轻易地被扩展，例如能力平台中计费的欠费能力发生变动时，都必须重新构建整个客服系统;阻塞持续集成，客服应用中的很多功能如计费专区、增值专区、宽带专区无法同时被构建和部署;迭代速度慢，客服门户系统- -个EAR包，代码需要很长时间来构建，例如智慧诊断、客户全视图、各专区等模块都无法并行构建，因此系统中任何程序的改变，都需要对整个系统进行重新编译部署，升级后需要大量人员留守测试验证，发现问题时需要反复部署测试验证，系统的水
平扩展也只能基于整个系统进行，无法针对某一个功能模块按需扩展。
3、传统客服系统设计缺陷
传统客服系统设计存在缺陷或者使用的框架本身存在一些不足 ，出现故障时不能快速地定位问题，甚至很长时间无法分析出问题原因,在没有分析到问题原因的情况下，只能规避问题的重现。针对上述系统之间存在的信息孤岛、单体化架构、 故障点多、新业务 需求满足慢等问题，亟需对传统客服系统进行微服务架构重构。
二、客服系统重构设计方案
鉴于以上的问题，客服系统重构解决方案按领域驱动设计(Domain-Driven Design,DDD)方法进行设计，DDD是一套 综合软件系统分析和设计的面向对象的建模方法，该方法要求接触到需求的第一步 就是考虑客服系统的领域模型，而不是将其切割成数据和行为，然后数据用数据库实现，行为用服务实现，最后造成需求的首肢分离。DDD首先考虑的是客服的业务语言，而不是数据，从客服的业务流程开始分析，形成业务架构。
1、客服业务流程分析
客户服务的顶层业务流程主要分为主动服务业务流程、被动服务业务流程两类。其中被动服务主要是客户发起的投诉、故障申告、咨询、业务处理、查询等流程，客服代表是被动服务;其中主动服务由客服代表发起，通过回访、客户关怀、维系挽留、营销、通知缴费等主动服务流程。客户服务顶层流程如图所示。
客户服务顶层流程
对客户服务中的被动服务流程，选取客户支撑的流程进行说明，如图所示。
客户服务被动服务的典型流程
客户通过服务请求单进入系统，首先进行智能预检处理,能在线处理的就在线处理并将工单办结，不能在线处理的则受理一张销单工单。
(2)全流程检测
如不能在线处理，则对受理工单进行端到端全流程检测，根据工单智能处理的检测结果，如不是线路问题，生成故障单，派往工单处理。
客服支撑部门联系用户，如能在线处理好的工单则直接办结，收集客户的反馈与归档;如不能在线处理则将工单派发到装维部门进一步处理。
(3)上门处理
如是线路问题,派往装维部门;装维部门通过接单、转派及联系用户进行上门处理，处理完以后进行回访，收集客户的反馈并归档。
3、客服系统主动服务营销流程分析
主动服务选取营销流程进行分析，如图所示。
客户服务主动服务的典型流程
(2)渠道人员先将目标用户导入到门户系统，再进行精准外呼,对有意向的用户受理商机工单。
(3)受理商机工单后，在内部进行工单流转及商机处理。订单受理成功后，安排装维人员上门服务，安装完成后，进行回访，收集客户的反馈并归档。
4、运营流程分析
运营流程包含录音质检、工单质检、运营监控、培训、考试、排班等，只对重点运营业务流程进行说明，其他流程不进行一一阐述，录音质检包含实时质检和事后质检。
(1)实时质检:后台支撑人员通过旁听、内部求助等功能实时支撑前台话务代表通话过程中的疑难问题。
(2)事后质检:制定质检计划，有计划地对中心客户录音进行质检，并通过质检报告分析中心话务服务质量;与智能语音引擎对接实现全中心录音准实时转写，进-步对客户意图进行分析、挖掘，提升中心业务服务水平。
运营支撑顶层流程
对工单处理及时率、工单回复及时率、工单内容填写规范性等内容进行质检。
工单监控流程:
(1 )提供现场监控、坐席监控、技能队列监控等话务实时监控功能，使后台支撑能快速掌握中心话务情况;
(2)提供接口调用监控、工单监控、热点话务监控等监控功能，实时监控中心热点事件以及周边系统调用情况。
培训考试流程:
(1 )提供员工在线培训功能，完成员工技能赋能，通常与考试功能配合使用，完成学习与技能检验的闭环;
(2)提供员工在线考试功能，并提供报表支撑。
排班流程:
通过运用科学合理的预测算法，结合呼叫中心现有运营的特征，精准地进行话务预测后实现自动排班，从而达到“在准确的时间，将有准确技
能的人，安排到准确的坐席上，上准确的班次， 同时达到合理的接通率"的目的。
3.2吝服系统业务架构
通过.上述业务流程分析，客户服务中心根据不同的业务拆分为:话务服务中心、运营服务中心、工单服务中心、公共服务中心4个客户服务能
力中心。
各服务中心功能
根据上述业务架构的结论，客服应用架构以统一应用服务平台(SaaS) 、统一平台服务(PaaS) 、统-基础服务(IaaS) 、统-接口平台进行构建。应用服务平台(SaaS) 为多媒体智能客服应用系统的坐席门户前台、IVR、 天翼客服、QQ客服、短厅、微博、微信客服等互联网客服提供统-服务。 应用服务平台按业务模块进行划分，各模块之间进行松耦合,为客服系统提供业务服务,分别为话务服务中心、工单服务中心、运营服务中心、公共服务中心提供共享服务。统-平台服务为整个客服系统提供公共的组件管理，方便系统扩展。统-基础服务为平台服务和应用服务提供公共的基础服务，例如引入集团提供的分布式缓存(Redis)、 分布式消 息队列、分布式数据库等基础服务。
客服系统整体应用架构
10000号业务模型的实体主要包括5个部分:客户、客户接触、交互事件、任务及工单。
(1)客户:客户是有能力成为电信产品的所有者、支付者，或者电信产品的使用者的个人或组织。现阶段中国电信的客户是指以产权关系界定
的、在同一登记证件名下的中国电信产品的所有者(人或组织)，是中国电信营销工作的对象和基本单元。
(2)客户接触:客户与中国电信产生的一次业务处理过程，都会产生一次或多次交互记录，一次客户交互可能产生一次或多次服务受理或业务办理，当中国电信向客户发起主动服务时也会产生一次或多次交互记录。
(3)交互事件:交互事件是指中国电信客户向中国电信所发起的咨询、查询、故障申告、投诉建议、业务申请等服务要求或中国电信主动向客户发起的客户挽留、客户关怀等主动服务。
(4)任务(内部发起) :任务是处理回访、客户关怀、营销计划时产生的需要分派给相关人员处理的工作事务。-个营销计划可以分解成多项任务派发给相关的人员。
(5)工单(客户发起) :工单是指客户代表不能对客户提出的问题直接答复，而进行留单，也就是为了完成某个交互事件或任务而派发的工作协同单。
客服系统E-R图示意
(1)客户客户接触:一对多关系。
(2)客户接触客户交互事件:多对多关系。
(3)客户交互事件-事件类型:一个客户交互事件对应一个事件类型，一个事件类型对应一个到多个客户交互事件。
(4)工单客户交互事件:多对多关系。
(5)工单-工单类型:根据具体业务需求，派生出催办类工单、督办类工单、管理类工单、施工类工单、资源分配类工单、写作类工单等。
(6)任务-主动服务:多对多关系。
(7)任务根据人物，派生出客户关怀、客户回访、话费催缴、客户挽留、客户调查等任务单。
3.5客服系统技术架构
客服系统重构，技术架构采用Spring Cloud体系的微服务架构，Spring Cloud基于Spring Boot,为解决微服务体系开发中的架构问题，提供了一整套解决方案，专注微服务架构生态，通信协议采用Restful HTTP ,通过Spring Cloud分布式架构服务建设客户服务能力中心，对外提供客服的服务能力，输出智慧诊断、账务专区、流量专区服务、宽带专区服务、iTV专区服务、预判展示服务、投诉保障服务、业务查询服务、客服智能机器人等能力。
客服系统技术架构
通过Spring Cloud微服务体系提供PASS服务，即服务注册中心、配置管理中心、服务监控中心、服务跟踪分析、服务网关、服务保障中心等平台服务。
通过对不同的业务梳理形成不同的客户服务能力，如业务查询能力、流量专区服务、-键诊断等应用服务能力，通过这些共享服务，完成话务服务中心、工单服务中心、运营管理中心、公共服务中心的构建。
4客服接口管理微服务化过程
在客服人员服务客户的过程中，需要把企业中所有IT系统牵涉到该客户的信息汇聚到客服系统中，方便客服人员全面了解客户信息，所以在客服系统中对其他系统接口的管理非常重要。通过接口管理微服务化这个实例来阐述微服务架构重构过程。
4.1接口管理前端(前端SaaS)
接口管理前台界面功能包括查询、修改等服务。
接口管理前端界面
通过对接口管理服务进行封装，再通过Service层实现该服务，为前台界面服务。
4.3服务治理
在接口服务的Spring Boot工程的启动application类上加上注解@EnableEurekaServer,同时配置好配置文件，该接口服务启动后会自动注册到Spring Cloud的套件注册中心Erureka Server中。
4.4数据服务
通过封装数据访问接口服务访问集团分布式数据库，为借口服务提供数据服务。接口管理的微服务过程整体如下:通过数据服务访问分布式数据库，该数据服务作为数据微服务单独部署;接口服务通过访问数据服务来服务前台界面，该接口服务作为一个服务单独部署;服务治理通过Spring Cloud提供的服务注册中心、配置管理中心、服务监控中心、服务跟踪分析、服务网关、服务保障中心来实现。前台界面调用接口微服务完成接口管理。
总结：
通过按领域驱动设计方法的重构,把客户服务中心分为话务服务中心、工单服务中心、运营服务中心以及公共服务,打造了客服系统的共享服务体系,性能显著提升，方便业务创新，能快速适应业务需求，解决信息孤岛，为企业的数据中台发挥大数据威力提供客服的数据储备。本次重构虽带来很多好处，但因业务的微服务化，造成平台出现错误时很难定位问题，在实施阶段企业为业务中台统-打造了数字化运营能力来解决该问题，该解决方案已经上线，可以解决微服务定位难的问题。
分享到
