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

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

微保客服云平台基于SaaS模式，采用微服务的架构设计实现，主要支持2B的保险行业客服服务。系统包含了业务网关、坐席平台等十几个核心系统，并结合公共服务及运维服务，共同构建了完善的客服系统平台，下面就谈一谈平台搭建过程中的一些选型和实践。

项目背景

打造保险行业支持2B的客服云平台，在微服务化技术框架下，会涉及到前端、业务网关等很多模块，各微服务都希望在满足业务需求的前提下实现DevOps，达到开发维运一体化，实现敏捷开发持续交付。

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

一、SaaS模式下分层方案和技术选型二、业务网关PB文件依赖问题及重构改造三、图解客服云平台的架构设计四、AOP拦截实现多租户数据源自动切换五、IM会话状态的解耦，实现无状态服务六、质检服务的实现过程及数据精细发展七、客户信息分库分表，数据脱敏实现八、服务治理的方法，全链路跟踪的实现九、关键业务监控及准实时数据刷新

01

SaaS模式下分层方案和技术选型

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

1.1 接入层

接入层主要是通过技术手段实现用户的鉴权识别，区分不同的租户不同的用户，满足业务层针对不同的租户提供不同的业务处理逻辑，通常业界有帐号区分、URL区分、域名区分等几种不同的方式。

帐号区分就需要根据规则，制定不同的帐号规则，比如加入前缀或后缀，这种方式在多租户模式下，很难满足用户的使用需求，用户体验非常差，而且暴露帐号规则，容易被人为破解和攻击，不符合实际的使用场景。

URL区分，就需要在网关层做好重定向，根据不同的租户转换为用户实际的请求URL，管理比较复杂，配置维护成本也比较高。

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

1.2 业务层

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

1.3 数据层

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

02

图解客服云平台的架构设计

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

2.1 时序图

2.2 架构图

03

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

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

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

通过研究GRPC的底层代码，发现可以在服务端启动时开启反射功能addService(ProtoReflectionService.newInstance())，客户端即可通过反射机制在运行时动态地获取服务端可调用对象定义的方法，从而解决之前实现方案中对PB jar包的依赖问题。

使用此技术重构后，我们在网关启动时可以初始化全量加载一次映射关系；然后再定时获取，比如每五分钟获取一次映射关系；最后当访问的URL没有时再主动尝试获取一次映射关系。结合这几种措施从而实现网关一次发布、持续服务、实时寻址、主动发现的功能。

04

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

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

05

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

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

客户通过服务A，发送一条消息 ，系统首先存储消息；

然后判断坐席是否连接在本服务器A中；

如果在本服务中，则直接推送新消息提醒给坐席端；

否则，根据缓存中保存的当前坐席所在的服务，把新消息提醒推送到对应服务的CMQ；

服务A消息处理结束；

同时，所有的服务A、B、C都在接收CMQ消息；

当收到一条属于本服务的CMQ消息后，就继续判断坐席是否在本服务中；

如果是在本服务，则直接推送新消息提醒给坐席端；

否则，如果坐席登录状态再次发生变化，则做相应处理；

本机的消息处理结束；

06

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

质检服务是一种非常重要的质量管控手段，既可以起到监管客服人员的服务质量、知识的专业程度，也可以实时地发现产品的市场言论热点，及时地跟进服务、响应客户。

坐席平台在收到会话内容后，首先推送至kafka中，质检服务负责消费kafka中的会话内容；根据预先定义的质检规则，针对敏感词汇、违规内容发送业务告警。主管人员或系统自动结合上下文分析，对客服的回复质量进行评分及统计。

我们也正在利用大数据处理引擎Flink，依据会话窗口为切割，实现会话数据的互动时间、互动次数、专业程度、热点产品、关注度等信息分析聚合，在数据挖掘、线索发现等方面为用户的精细化运营提供数据支撑服务。

07

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

客户信息会涉及到客户资料、保单信息、订单信息，以及其它附加的如亲属信息等，这个一般根据业务量做好分库分表就可以下沉为基础服务了。

在做分库分表时，比如针对用户ID进行hash分库分表时，一定要hash两次，也就是针对数据库一次，针对数据表一次，才能做到真正的均衡存储。

由于微保客服平台是针对保险行业的，需要非常注重隐私保护，虽然平台做了层层的权限管控，但是在实际的运营中并不能绝对的保证权限是严格分配的，所以一定要有数据脱敏措施，并且针对敏感数据的一切操作做好操作日志。

通过把脱敏处理技术能力下沉，做成了公司统一的脱敏服务，针对所有敏感信息统一处理转换。针对异常、大量、频繁的敏感信息操作，自动触发临时权限管控机制，并告警通知给相关管理人员。对于敏感数据，无论是监管要求，还是从信息安全方面讲，不进行脱敏处理都是不能容忍的，这也是微保客服云平台踩坑的经验教训。

08

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

微服务下的服务治理非常重要，服务依赖具有扇面的结构：如果上游服务出现异常，极易引发雪崩。服务治理涉及全链路跟踪、服务熔断、服务降级、服务限流等方面。因为微保客服平台内部是通过GRPC实现微服务通信，所以只需要把requestId、traceId等信息设置到请求的header，在依赖的下游服务中透传，即可实现全链路跟踪定位需求。

防范雪崩的方案主要有熔断模式、隔离模式、限流模式。

其中熔断设计上微保客服平台主要参考了Hystrix的做法，通过熔断请求判断算法、熔断恢复机制、熔断报警相结合，实现服务熔断；当然这是框架层面的处理，实际基础运维层也有相关的熔断处理手段，这里就不再展示讨论。

隔离模式的实现一般都采用舱壁隔离原则 ，具体实现上有线程池隔离模式、信号量隔离模式，原理就是给调用依赖服务的通道一定的空间，占满则直接返回错误或异常告警。

限流模式，实际上并不能真正地解决雪崩问题，只能起到保护延缓的作用，常见的限流算法有：漏桶、令牌桶，当然计数器也可以进行粗暴限流实现；漏桶算法在于控制流出的速度，令牌桶算法在于控制流入速度，而且可以承受一定量的流量增长；算法都各有所长，具体还要看实际的业务场景来选择方案，毕竟脱离业务场景的系统设计，都是在耍流氓嘛。

09

未来展望

9.1 意向识别，线索挖掘

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

9.2 智能质检，数据赋能

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

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

9.3 智能排班，提升效能

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

9.4 其它事项

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

后台留言功能已开启，欢迎留言吐槽哦~