【.com原创文章】淘宝每天有数百万客服在线为亿万买家提供服务，而客服平台也从一个简单的配送系统，逐渐演变成涵盖买手、客服、客服主管三位一体的平台解决方案。本文主要分享整个淘宝客服平台架构的演进过程，以及当前的服务如何结合AI赋能的实践。2017年12月1-2日，由主办方主办的WOTD全球软件开发技术峰会在深圳中洲万豪酒店隆重举行。本次峰会的主题是软件开发。阿里云零售事业部高级技术专家顾默在技术架构与业务架构专场会议上带来了主题为“淘宝的智慧客服架构演进之路”的精彩演讲。本文分为三个部分与大家分享近三年淘宝客服架构的演进：阿里电商客服业务背景介绍淘宝智能客服架构演进之路总结阿里电商客服业务背景介绍客服行业历史悠久，在过去的五到十年中，经历了以下三个阶段：在互联网尚未完全兴起的早期，传统客服行业以Callcenter、Email为代表和短信。其主要功能是帮助企业沟通、解决问题、提供售后咨询。随着互联网的发展，该行业出现了基于Web和PC终端的客服。他们通过互联网提供服务。这时候开始出现一些社交媒体和淘宝电商客服人员。近期，随着用户数量的快速增长，整个客服行业开始转向客服云解决方案，实现跨区域为整个公司或企业提供云解决方案。对于阿里电商平台来说，淘宝上每天有数千万的消费者，每天的咨询量可达数亿。相应的，在商家端，与消费者的互动也会有百万次。在双十一等活动期间，虽然这个数字对商家来说变化不大，但消费者的咨询量至少会增加10到20倍。因此，对于整个平台的客服工具，需要向智能化、数据化的方向发展，以提高商家的能效和消费者的满意度。同时，这也是我们解决问题的重点。由于淘宝的大部分服务都来自于商家，提升商家客服的服务质量可以提升整个平台的满意度。淘宝智能客服架构演进之路根据业务发展，我们的架构演进分为三个明确的阶段：分布式系统架构。我们实现了分流系统，具体分为正常分流和排队分流。客服业务系统架构升级。随着业务范围的扩大，我们对整个业务架构进行了重组，调整为事件驱动的业务体系。客服业务系统与AI能力的融合。目前，甚至未来，我们都在与集团内各个AI团队合作，让AI能力与接待场景深度融合。第一阶段：配送系统架构例如：买家登录手机淘宝，找商家提问，点击旺旺头像，系统触发配送操作。像苏宁或小米这样的卖家，后台有十到几百个客服人员，系统需要通过配送选择合适的客服建立对话。可见这是IM聊天过程中的一个关键节点。今年双十一期间，整个配送系统都面临着不小的流量压力。由于每条聊天消息都流经系统，因此对系统来说是一个巨大的性能挑战。一旦系统抖动或者RT变慢，就会影响全网的服务。所以为了应对巨大的吞吐量，我们会千方百计缩短RT。基于以上需求，我们制定了以下不同的解决方案：针对苏宁、小米等超大商户，我们采用了类似负载均衡的定制化解决方案。具体包括：权重、客服分组、基于页面来源的导流。其中，页面来源是指我们根据咨询的路径判断是转发给售前组还是转发给售后组。对于一些全品类商户，他们的客服已经按照品类进行细分分组，所以我们也提供基于品类属性的个性化需求分配。对于汽车行业的一些卖家来说，他们的客服只能服务于当地消费者。因此，我们需要根据不同的会诊来源和地区进行分流。对于排队分流，我们后面会重点讨论。为了追求足够大的吞吐量和足够短的RT要求，同时也考虑到特殊的业务规则、状态变化和用户设置，我们从外部向系统同步了很多变量的信息。带有变化事件的变量进入系统后，为了保证整个系统的稳定性和业务的合理性，我们构建了一套读写分离的架构。我们将整个查询的逻辑放在一个系统中，所有对状态变化的更新放在另一个系统中。两个系统之间的对话是通过缓存进行的。因此，对于读取数据，我们可以使用缓存的最佳实时技术，最大化QPS，降低RT。另外，为了进一步缩短RT，我们还将复杂的计算放在了后续的update操作中。通过提前预测下一次分配应该分配给哪个客服，我们可以直接进行更新操作，从而简化查询和整个计算的复杂度。上图右上为双十一期间商户接待终端的咨询状态。虽然系统实现了分流，RT和吞吐量都很快，但是由于并行接入的咨询请求太多，即使系统能够承受，具体业务的客户人员也会不堪重负。针对商家客服所能招揽的客户数量有限，我们提出的相应解决方案是：通过机器人和导流排队相结合的方式，帮助商家应对高人流量。上图下半部分是排队功能的流程展示：所有进入服务咨询的买家都会分配一个虚拟账号→虚拟账号连接后台阿里店小秘书的服务机器人→机器人通过人工智能与买家联系，并回答简单的问题。如果买家对回答不满意，可以选择切换到人工→切换到人工后按分流分组逻辑放入队列→进入队列后后台调度系统进行买家派遣和客服→创建Reception会话，由客服跟进接待。之所以引入会话的概念，是因为客服主管需要给客服团队设定一个合理的接待限额，来控制同一时间可以接入的人数。例如：耐克的淘宝店铺严格认为，一个客服人员一次最多只能接待5位顾客，如果超过，就会造成服务质量下降。此外，我们还为全链路设置了完整的数据埋点，通过实时统计，帮助每个商户全面了解店铺当前的接待情况。其中包括：有多少人在被机器人服务，有多少人在排队等候，有多少人在被人工接待，每次人工接待的时长，以及响应的速度等。客服主管可以衡量通过观察后台情况了解整体服务状态。由于业务条件的限制，我们设计和采用的排队技术框架与业界不同。首先，由于旺旺集成在手机淘宝各个版本中，可以直接聊天，所以在客户端会有跨终端、跨版本的可能。而我们的排队逻辑是在前端页面完成的，所以我们很难保证老版本的客户端能有新的能力。其次，因为我们的旺旺、千牛等在不同的体系，而阿里这个大平台，把各个业务体系拆分的非常细。因此，要保证跨多个客户端、多个服务器的数据、计划和队列的一致性，我们付出的成本会非常高。所以我们需要做以下事情：我们决定采用服务器端集中的会话状态管理。完全不依赖于客户端的能力做任何事情，所有的解决方案都由服务端来完成。由于无法实现分布式事务，我们通过业务补偿来保证整个队列中状态和数据的最终一致性。在将买家请求分配到合适的队列，通过排队调度管理客服时，我们针对以下问题做了不同的尝试：集中会话管理的高并发处理：使每个客户的接待分布不超过设定的上限。由于在Java中我们通常倾向于以无状态的方式实现各个应用，而各个客服分布在不同的机器上，所以我们设置了一个类分布式锁用于实时查询。如果超过上限，服务将被停止。对于机器无状态竞争带来的分布式锁的开销，我们使用ZK（zookeeper）来管理商户的碎片化，使用单线程机制来处理。我们允许同一台机器和同一个分片中的所有商家使用同一个线程进行处理，从而避免与竞争相关的锁问题。这种有状态的分布式处理机制带来的最大问题就是故障转移。即：由于每个用户只存在于一台机器上，没有任何备份，如果机器因为流量大或其他问题宕机，我们如何快速恢复这些用户而不丢失状态呢？我们采用了强大的故障转移机制，以确保当一台机器或队列发生故障时，可以在大约一到两分钟内重新启动设备以恢复整体状态。队列存储处理：由于商家促销活动的时间不一致，我们不可能实现全网调度，所以必须做一个“开关”，让商家自己设置。同时，当经常创建不同的队列时，由于我们的排队机制完全依赖于分组，所以分组的强度和数量是不可控的。因此，我们采用了MySQL的方案来设置这个开关，从而可以随时动态创建或销毁大量的组。对于“进队快、出队慢”的现象，由于活动高峰期采购商和询价会急剧增加，客服能力有限，“消化”得慢。因此，我们采用了pull的方式。在保证流量能够快速进入的基础上，客服人员分组，根据自身能力不断从同一个队列中拉取。上帝视角排队数据：动态创建副本的能力，需要支持多维度的查询，以及排队优先级和固定分组等因素，都对MySQL的调度能力和吞吐性能提出了非常高的要求。双十一期间，为了让MySQL能够支撑top1000商户，我们对MySQL的整体容量进行了分布式分表的规划，通过MySQL的复杂能力快速支撑业务。当然，我们也遇到了一些新的瓶颈。为了继续支持下一轮的双十一促销活动，我们正在考虑进一步优化性能。第二阶段：客服业务系统架构升级上面说的是最基础最核心的服务分发和排队。但是随着业务的发展，我们发现客服接待整体上可以分为三个角色：消费者、客服和主管。只有这三个角色实现了互动或联动，才能形成最合理的体验关系。据统计，我们平台上有近百万的专业客服人员。如果按照人均月收入3000、5000元计算，客服行业每年的总支出成本高达数百亿。因此，我们迫切需要通过工具或自动化来帮助他们节省这样的成本。在产品能力方面：我们为买家设计了智能服务窗口，买家可以自助领取各商家的优惠券和活动道具。我们增加了输入联想功能，例如：当您使用手机淘宝查询店铺时，它会直接提示您一些常用词。我们在接待面板上启用了Kilo。通过一个相对复杂的界面，客服可以看到整个商户和买家的相关信息，以及接待过程中出现的问题。它还可以提供语音转文字的功能。客服主管后台主要提供监控和调度。可通过服务助理店秘书和AI机器人展示全店及客服的接待转化率，实现门店精细化管理。有过业务开发经验的程序员都知道，功能需求往往是一口气提出来的，留给我们开发的时间通常很紧迫。如上图右侧所示，为了让业务能够“跑起来”，系统整体会呈现一个“垂直”的基础设施：为了降低错误率，会有很多冗余的建设。由于没有充分考虑底层的通用性，各种接口的适用性比较差，复用率低。各个业务模块的依赖关系也比较混乱。系统的处理能力也参差不齐。一般C端的业务量特别大；而B端的业务规模相对较小，但复杂度特别高。所以，如果业务拆分不合理，C端的业务和B端的业务就会放在同一个模块中。所以只要流量过大，商家的系统就可能面临较大的风险。面对上述情况，我们认真梳理并围绕交易关系的核心本质，对整个接待流程进行了合理拆分。用户在IM渠道的交互行为可以分为：买家行为→千牛→商家行为。如上图所示，对于每一端的每个角色，可以分为三个场景：售前、售中、售后。客服方面，涉及到淘宝各项业务的运营，可与自身内部ERP、MS、后台自建系统对接，最终实现各场景互通联动。这里我们提出一个新的思路：以场景为切面，将消费者、客服和业务系统有机结合起来。如果通道两端都有行为，我们可以通过交易事件或者用户行为事件，加上IM聊天事件作为输入源，最终推动整个业务场景向前发展。下面我们将上述流程抽象成一个业务描述：从事件驱动的角度，统一收集所有与平台相关的事件，如聊天消息、交易消息、评价等，然后对这些事件进行解析，标准化，存储和定义到场景中。例如：买家进来咨询商品，商家推荐；买家下单后，商家应尽快提醒买家付款；或买家付款后修改送货地址。梳理好一切之后，我们将这些事件的来源、流程、定义、选择、执行等组装成一系列的信息流，然后组装成各种预定义的场景。通过场景的输出，我需要找到对应的可选服务，比如上面例子中的“修改地址”，其实应该是转到后台的交易流程，完成地址相关的服务。上面提到的“产品推荐”，需要推荐团队的服务能力，才能实现基于内容的产品推荐。***，我们需要将服务能力输出到聊天频道。具体实现中：对于买家而言，只需在IM频道中突出显示相似的卡片、短信、图片或视频即可。对于客服，通过与已有插件的互通，我们只需要在界面右侧展示买家的行为特征，各种事件提醒，需要进行的操作，就不需要放在里面了这个频道。对于监管者来说，主要是数据模型的各种监控和预测。例如：在接待过程中，如果捕获到买家的投诉信息，主管可以判断买家当时的心情，或者分析买家是否因为接待时间长，耐心不够，再转给客服为了特别舒适。基于以上场景，我们重构了业务平台。首先业务垂直动态连接，然后在此基础上提取核心功能，以卡片的形式在渠道上进行交互。另外，通过对复杂场景的实时计算，我们还定义了各种事件。对于前端，我们使用订阅系统来实现各种服务的注册、发布和订阅，使用插件框架来负责第三方服务的接入。消息通道的控制实现了前端框架与底层、服务窗口的交互。前面提到，通过事件将各个服务流程串联起来，我们形成了上图所示的核心业务架构。对于前端遗留下来的一些需要写入核心系统的业务代码，我们将其拆分为四个业务层系统：买家自助服务、配送服务、面向客服的工具、客服主管——导向工具。而图片的下方就是我们的后台平台。从上面可以看出，改成基于事件的方式后，好处是只需要按照我们定义的标准接入新的服务人员，订阅他们关心的事件和处理机制即可。通过识别涉及的场景和对应的??调用服务，最终实现标准化。客服业务系统与AI能力的融合由于我的团队是一个平台，而AI场景是由另一个算法团队实现的，所以双方需要进行算法相关的对接。我们提供了一组用于服务注册、发现和订阅的关系。虽然都是产品推荐，但应用于“航空旅行”的推荐算法将与“女装”的带图片和搜索功能的推荐模型完全不同。目前我们主要使用基于规则的路由机制，但随着服务场景和服务商的增加，我们会融入更多基于AI的决策机制。在将AI与各种IM渠道相结合方面，我们基于对话的框架设计完全可以与Facebook的Messenger和微软的BotFramework竞争。所有连接的聊天场景，无论是机器人还是解决方案，都有一个会话完成机制。这样系统就可以知道是哪个用户在哪个场景下触发了消息或者请求。以往的单轮交互是：一个request进来，一个answer。然而，当今人工智能处理的复杂业务通常需要多轮交互。比如上面提到的航空旅行推荐的例子：在与你是否想旅行进行交互之后；您需要进一步查询是国内游还是国外游；如果是出国旅游，还需要查询目标地区。可见，多轮交互需要AI具备强大的语义匹配、意图识别等交互能力。为了让买家在使用AI时有更好的体验，我们在提供算法接入时允许对方自定义菜单。通过沟通，他们将希望买家输入的答案设置到菜单中。这样的互动提醒，不仅省去了买家的打字输入，也巩固了他们反馈的结果。这种友好的交互也提升了平台的整体处理能力。由于我们本质上是通过消息驱动逻辑来实现的，如上图从左到右：事件源接入→标准化→安全脱敏→控制事件中心和调度中心。同时这里接入外部AI服务→注册授权→开放接口→整体监控。之所以把AI的服务能力拆分出来，是因为我们需要和其他团队合作，实现外部搜索、意图识别、知识库、多轮交互、情感分析等能力。我们的Bot不仅可以与买家互动，还可以与客户服务互动。与点小蜜类似，API作为一种认知服务，可以被各业务方调用。对于用户的聊天数据、客服表现、当天的状态、每个客户角色的数据、存储的产品数据，我们可以通过底层数据的沉淀功能，在不同的场景调用，实现快速开发和轻量化服务交付。结合场景对业务本质的模型进行抽象总结和指导设计：根据上述事件驱动的概念，商品交易或聊天交互触发大量事件，形成联动场景。我们可以通过逐层切片的方式，一个一个地构建具体的场景。从整体上看，不同赛事的组合可以形成不同的驾驶模式。随着业务的复杂性不断调整和优化架构设计：我们不一定非要采用所谓“最好”的中间件方案。只有最适合的业务场景才是最好的架构设计。团队成员对架构有一个统一的认识：我在团队里常说，“架构只有适合不适合，没有好坏之分，用好架构，一定可以实现一定的业务需求；”使用一个糟糕的架构，你也可以最终实现业务需求。”因此，所有团队成员都应该对架构有一致的理解。只有这样，大家在写业务代码的时候，才能主动去思考自己实现的功能在整个架构体系中如何做到平衡和谐，放在哪里才是最合适的。相反，如果团队成员对架构的认知不一致，可能会导致组织内部代码风格和运行模式的不一致。因此，统一的认识对于带领团队满足需求、实现业务至关重要。淘宝技术部-媒体技术与消费连接平台-消费连接平台-平台业务-自营，资深技术专家。2010年加入阿里，2015年开始负责阿里商家客服平台搭建，推动平台架构升级，为阿里域（天猫、淘宝、1688）商家提供客服整体解决方案、航空旅行等）。专注于高并发、高性能、高可用分布式系统的研究与实践。【原创稿件，合作网站转载请注明原作者和出处为.com】
