基于SAAS模式的客服云平台落地实践

1、项目背景

业界的客服系统经过这些年的发展，已经成为客户服务、辅助销售、线索挖掘等不可缺少的工具；客服平台除了具备实时的聊天功能，还发展出结合微信、QQ、电话等第三方工具，提供文字、图片、文件、语音等多种媒体信息，方便客服人员联系在线访客，“变流量为销量，抓住每一个潜在的客户”。此外作为一款实时的客服工具，不同的厂家都针对性的开发出各自特点的功能，来更好的为客户提供服务，未来客服系统的发展方向应该是更好的结合客户渠道入口，结合客户管理系统，结合在线销售系统，为企业开辟一条发展之路，营销之路。

市场上现有的客服平台一般都是基于网站实现接客能力，提供客服服务，接客渠道单一、服务大众化，在数据安全、使用成本、行业理解、业务整合等方面都会存在足多问题。微保的获客渠道主要有微信、小程序、H５、WEB等，针对不同的产品有不同的保司提供相关承保服务，体现在客服平台就是有不同的客服团队提供针对不同产品的各种售前、售中、售后服务。结合保险行业对数据安全性、隔离性等方面的场景要求，以及更好地打通公司内外部的业务联通，我们立项基于SAAS模式来实现系统功能，立争打造一款专属于保险行业的客服云平台，解决保险行业客服服务的业务诉求和痛点。

打造保险行业面向TOB的客服云平台，在微服务化技术框架下，会涉及到前端、业务网关、租户管理、坐席平台、质检服务、业务监控、客户信息、保单订单、统计报表、工单系统、数据挖掘、运营管理、服务治理等足多方面，无论那块业务都希望在满足业务需求的前提下实现DevOps，达到开发维运一体化，实现敏捷开发持续交付。

本篇仅从以下几个方面探讨微保客服云平台搭建过程中的一些选型和实践

一、SAAS模式下分层方案和技术选型 

二、业务网关PB文件依赖问题及重构改造

三、图解客服云平台的架构设计与部署

四、AOP拦截实现多租户数据源自动切换

五、IM会话状态的解耦， 实现无状态服务

六、质检服务的实现过程及数据精细发展

七、客户信息分库分表，数据脱敏实现

八、服务治理的方法，全链路跟踪的实现

九、关键业务监控及准实时数据刷新

2、SAAS模式下分层方案和技术选型 

基于SAAS模式的多租户客服平台，需要从接入层、业务层、数据层等几个不同的层次，实现租户信息的区分，最终保证数据的安全和高度隔离，满足保险行业的使用场景。

2.1 接入层

接入层主要是通过技术手段实现用户的鉴权识别，区分不同的租户不同的用户，满足业务层针对不同的租户提供不同的业务处理逻辑，通常业界有帐号区分、URL区分、域名区分等几种不同的方式。帐号区分就需要根据规则，制定不同的帐号规则，比如加入前缀或后缀，这种方式在多租户模式下，很满足用户的使用需求，用户体验非常差，而且暴露帐号规则，容易被人为破解和攻击，不符合实际的使用场景；URL区分，就需要在网关层做好重定向，根据不同的租户转换为用户实际的请求URL，管理比较复杂，配置维护成本也比较高。

域名区分相对比较简捷，开通新租户时，只需要绑定好域名与租户的标识，做好映射关系，在请求经过网关时自动的根据域名来区分识别租户即可，针对不同的域名也比较容易实现链路跟踪、请求限流、服务熔断等服务管控；系统升级维护时，也比较容易做灰度发布，是比较适合SAAS模式的多租户接入方案，微保客服平台最终也选择通过域名实现接入层的租户区分。

2.2 业务层

业务层主要依据接入层传入的租户标识来实现业务逻辑的处理，微保客服平台内部服务统一使用GRPC实现微服务之间的调用，结合此框架的特性，网关把HTTP转GRPC请求时，我们把租户标识设置于请求的header里，当服务端接收到请求后，读取header里的租户标识，即可做相关业务逻辑的判断处理。

2.2 数据层

数据层一般有独立数据库实现全隔离架构、共享数据库的隔离数据架构、共享数据库的共享数据架构几种方式，结合保险行业的场景要求，如果选型共享模式，一般就是通过租户ID进行区分，这就要求开发人员一定要有非常严谨的开发规范，稍有不慎就有可能造成数据的异常暴露，这在保险行业里是绝对不能容忍的。结合我们框架的特点以及实际业务场景需求，我们选型了独立数据库实现全隔离架构方案，此方案的优点就是底层数据每个租户独立成库，绝对隔离；而且在框架上我们可以通过AOP拦截，直接实现数据源切换，可以让一线开发人员，不再关注下层的数据切换存储问题，就好像操作同一个库同一张表一样简单明了，有效地提升开发效率，降低研发的复杂度，减少人员失误引发的数据异常。当然不好的地方可能就是各租户库因为业务量大小不同而造成数据的不均衡，这个真要是达到此地步时，也是可以单独分库分表解决的。

3、图解客服云平台的架构设计与部署

下面分别从时序、架构、部署几个方面，通过画图解析一下整体的架构设计与部署。

3.1 时序图

3.2 架构图

3.3 部署图

4、业务网关PB文件依赖问题及重构改造

微保坐席平台网关首先起到用户登录鉴权、HTTP转GRPC协议转换的作用，还兼具链路跟踪、服务限流、请求统计等服务监控功能，其中协议转换是最主要的功能之一，起到把外部的HTTP请求，转换为内部微服务的GRPC调用。其实现原理为把请求URL与服务API构造为一张Map映射表，每次请求进来时，查询映射关系表，找到对应的服务API并转换数据结构，发起调用请求，收到响应后再转换为HTTP格式数据返回前端。

HTTP转GRPC协议需要提前生成映射表，业界通常使用的办法是加载PB架包，通过Class反射分析文件，读取URL与对应的服务API，微保客服平台第一版网关也是如此实现的，这种依赖架包的协议转换方式，如果是在单体应用上问题不大；但是在微服务体系下，会存在很多问题，任意一个服务接口发生变更，都需要重新发布网关，才能读取加载识别新的API服务，造成网关不断的重新发布，影响服务的持续性和稳定性，而且也缺少主动寻址实时发现新服务API的能力。

通过研究GRPC的底层代码，发现可以在服务端启动时开启反射功能addService(ProtoReflectionService.newInstance())，客户端通过反射机制就是在运行时动态的异步调用服务端对象的方法和属性，采集到服务端的类名、方法名、方法参数等信息，从而完成URL请求到服务API之间的关系映射，解决之前实现方案中对PB架包的依赖问题；使用此技术重构后，我们在网关启动时可以初始化全量加载一次映射关系，然后在定时获取，比如五分获取一次映射关系，最后当访问的URL没有时再主动尝试获取一次映射关系，结合这几种措施从而实现网关一次发布、持续服务、实时寻址、主动发现的功能。

5、AOP拦截实现多租户数据源自动切换

微保客服平台是在Springboot框架下实现的微服务，可以方便地通过AOP拦截GRPC请求，读取租户标识，结合ThreadLocal实现自动的数据源切换，这样一线开发人员在实现微服务的API时，基本可以不关心实际租户的数据库，只关心实际的业务场景和业务逻辑，保证数据的完整性即可，自动化的数据源切换实现自动的数据库切换。

6、IM会话状态的解耦， 实现无状态服务

客服平台在坐席侧是通过websocket长连接实现消息互通的，其实就是一款在线的IM，在集群部署的情况下，客户的会话消息可能会调用任意一服务结点，而坐席登录时也有可能连接任意一台服务结点，客户与坐席是有状态的消息互通，那我们就需要把有状态的服务，改造成无状态的服务，通过中间件实现状态的解耦；实现中我们采用了腾讯云的消息队列CMQ，实现状态的解耦，具体方式是如下：

客户通过服务A，接收消息到一条消息，系统首先存储消息；
然后判断坐席是否连接在本服务器A中；
如果在本服务中，则直接推送新消息提醒给坐席端；
否则，把新消息提醒推送到CMQ；
服务A消息处理结束；

同时，所有的服务A、B、C都在接收CMQ消息；
当收到一条CMQ消息后，就继续判断坐席是否在本服务中；
如果是在本服务，则直接推送新消息提醒给坐席端；
否则，丢弃此消息；
本机的消息处理结束；

7、质检服务的实现过程及数据精细发展

质检服务是一种非常重要的质量管控手段，既可以起到监管客服人员的服务质量、知识的专业程度，也可以及时地发现产品的市场言论热点，及时跟进服务、响应客户。通过对会话内容的语义分析，根据质检规则，可以针对会话内容进行质量打分，也可以针对敏感词汇、话题进行业务告警，甚至接合Flink实现数据精细化分析聚合，为数据挖掘、线索发现提供服务。

8、客户信息分库分表，数据脱敏实现

客户信息会涉及到客户资料、保单信息、订单信息，以及其它附加的如亲属信息等，这个一般根据业务量做好分库分表就可以下沉为基础服务了；当然，在做分库分表时，比如针对用户ID进行hash分库分表时，一定要hash两次，也就是针对数据库一次，针对数据表一次，才能做到真正的均衡存储；由于微保客服平台是针对保险行业的，需要非常注重隐私保护，虽然平台做了层层的权限管控，但是在实际的运营中并不能绝对的保证权限是严格分配的，所以一定要有数据脱敏措施，并且针对敏感数据的一切操作做好操作日志，甚至可以结合告警系统，针对异常、大量、频繁的客户信息操作，触发告警通知给相关管理人员；当然最好能够把脱敏处理技术下沉，做成公司级统一的脱敏服务，否则无论是监管要求，还是从信息安全方面，不进行脱敏处理都是不能容忍的，这也是微保客服云平台踩坑的经验教训。

9、服务治理的方法，全链路跟踪的实现

微服务下的服务治理非常重要，服务依赖具有扇面的结构，如果下游服务出现异常，极易引发雪崩；服务治理涉及全链路跟踪、服务熔断、服务降级、服务限流等方面。因为微保客服平台内部是通过GRPC实现微服务通信，所以只需要把requestId、traceId等信息设置到请求的header，在依赖的下游服务中透穿，即可实现全链路跟踪定位需求；防范雪崩的方案主要有熔断模式、隔离模式、限流模式，其中熔断设计上微保客服平台主要参考了Hystrix的做法，通过熔断请求判断算法、熔断恢复机制、熔断报警相结合，实现服务熔断；当然这是框架层面的处理，实际基础运维层也有相关的熔断处理手段，这里就不再展示讨论；隔离模式的实现一般都采用仓壁原则，具体实现上有线程池隔离模式、信号量隔离模式，原理就是给调用依赖服务的通道一定的空间，占满则直接返回错误或异常告警；限流模式，实际上并不能真正地解决雪崩问题，只能起到保护延缓的作用，常见的限流算法有：漏桶、令牌桶，当然计数器也可以进行粗暴限流实现；漏桶算法在于控制流出的速度，令牌桶算法在于控制流入速度，而且可以承受一定量的流量增长；算法都各有所长，具体还要看实际的业务场景来选择方案，毕竟脱离业务场景的系统设计，都是在耍流氓嘛。

10、关键业务监控及准实时数据刷新

业务监控主要是针对业务层面的监控告警通知，提升业务的服务质量；针对重要的业务接口，结合Prometheus来上报我们的业务状态，根据告警规则，实时监控业务接口；在应用方面的业务监控，分别实现了租户视角、系统视角的监控，根据不同的租户，不同的产品，可以实时的查看客服的服务状态、当前的会话量、排队的会话量、超时离开量等，支持最短5秒一次的刷新，准实时地投到大屏，全面了解客服人员的服务状态，以及业务量。

11、运行现状

11.1 接入流程

开通新租户非常简单，只需要在运营平台，一键创建新租户，新的租户即完成了开通，只需要管理人员设置相关权限，创建相关使用人员帐号，即可上线使用功能，完成线上服务。

11.2 服务监控

服务监控主要是利用Prometheus，把我们的请求统计上报到运维系统，实现对重要业务请求的异常监控和报警处理。

12、未来展望

12.1 意向识别，线索挖掘

客服平台作为公司与客户之间沟通交流的桥梁，可以说是全场景的服务于客户的售前、售中、售后，无论是客户信息、保单信息、订单信息，还是沟通交流的会话信息，通过数据分析在客户意向识别、线索挖掘等方面有很多提升空间。我们可以通过对客服大数据的分析和挖掘，有效地分析、识别客户需求，挖掘商业机会和金融服务的潜力。例如客户关注的业务热点、客户对产品的反馈、客户未被满足的需求等，这些都蕴含着新的产品机会和销售机会。同时也能与企业内部系统的深度集成后，建立用户的反馈记录、购买记录、兴趣链等，结合现有UP平台中的用户画像系统，实现更为精准营销和用户运营。

12.2 智能质检，数据赋能

客户服务已经越来越成为体现竞争差异、提升公司形象、增加客户满意度的必争质地，对客服体系服务质量的管理和控制已经变成了企业经营管理者日常的重要工作，而质检就是其中的主要组成部分。人工质检存在覆盖率低、漏检率高、延时长、成本高等问题，而且带有个人主观意识，难一达到客观统一的标准；未来利用云计算、人工智能等技术，结合智能语音识别（ASR）、自然语言处理（NLP）、大数据挖掘，实现人工质检到智能质检的升级变革，通过设定标准作业流程、标准话术、服务禁语等，判断客服人员是否存在不符合规定流程、违规用语、泄露公司机密等行为；通过判断上下文，理解用户的意愿是否得到合理的满足；通过匹配标准知识库，判断用户的问题是否得到正确的解答。

智能质检系统还能通过对服务合规数据的统计，了解在不同周期内整体服务品质的变化情况；通过对客户行为数据的聚类、归纳与分析，可以形成客户热点问题统计、业务趋势分析；通过从通话中挖掘客户、产品等有价值信息，为客服、运营、营销提供支撑；实现企业经营策略的优化，为企业战略的实现提供更多动力。

12.3 智能排班，提升效能

客服平台最终的服务离不开人，一些重要的复杂的业务处理，还是需要人工介入处理，所以在进行大促活动、新品上线时，巨量的客户访问，就需要灵活的客服人力支撑；后期可以通过对历史数据分析、客户覆盖分析、活动类型分析，人力效率分析等多种智能化处理，完成一套智能化的排班功能，既可满足业务需求，又能降低人力资源的浪费情况。

12.4 工单优化

工单子系统，在公司内部沟通、事项跟进、客服服务等领域内，不同的部门或个人使用工单来跟踪处理不同类型的用户服务诉求，根据的具体需求来决定如何使用工单，一个工单可以是一个客户问题，一个工单可以是一个投诉诉求，一个工单可以是一个维权case或者外呼任务。为了提高客服的工作效率，后期会引入抢单模式，所有新建工单流入工单池，所有符合规则的客服人员，都可以抢着完成工单，激发员工的积极性，主动性，更好更快地完成相关工作。

12.5 其它事项

伴随着公司业务的发展，后期可能会有定制化的版本，如果兼顾通用性和个性化也是值得关注的地方；还有一些技术能力的下沉，大数据系统的引入，做到更好的数据分析，推动公司业务的增长，都是值得关注的。