补充介绍：「小得物环境」是一套[全新搭建]独立[物理隔离]的[单地域]的[小流量][生产环境],覆盖了从网络、接入层、中间件、核心应用的系统和服务，为各类产品研发和业务发展的稳定性提供了丰富工具和应用场景。

以下是正文。

        在线客服系统是用户与平台直接沟通交流的渠道，一旦系统出现问题，将会导致平台无法及时感知和解决用户问题。因此在线客服系统的稳定性就变得非常重要。目前在线客服系统在稳定性遇到的挑战有以下几点：

• 由于无灰度环境，无法在可控范围验证新功能，白天发布变得不可能，只能选择在凌晨后低峰发布。这样造成整个发布流程持续到凌晨5点，在较长时间工作负荷下，可能会出现未能覆盖的bug导致上线功能出现问题。

• 由于是凌晨全量发布，没有经过生产流量的验证，问题的爆发往往会延迟到早晨8:00 客服上班这个时间点，一旦出现问题，需要全量回滚，由于回滚时间比较长，会造成故障时间变长，故障影响面扩大。

• 基于现在的「小得物」，可以做到生产灰度，但是参与灰度的客服人员和用户不可控，无法做到功能验证的全覆盖。

  
  

        基于以上问题和在线客服系统的特殊性，我们制定了适合自己的灰度生产策略。进而达成以下目标：

• 解决IM不能白天发布问题。

• 支持部分用户及客服线上流量做灰度功能验证。

• 降低因发版导致的P级故障和冒烟问题的发生率。

二、遇到的挑战

        因为在线客服系统同时存在C端和B端，如何灰度以及制定怎样的灰度策略才能尽可能多的覆盖功能场景，是一件需要仔细考虑的事情。

• 长链接服务能不能灰度？
          IM网关分为长链接服务、业务服务，长链接服务发版频率较低，网关业务服务发版频率适中，要不要灰度网关业务服务，和基架同学深入讨论过，消息群组服务为了消息发送的性能，需要进程内缓存topic相关信息，没有使用分布式缓存，消息存在多端进行通信的场景，当灰度时，用户和客服在不同环境上时会有问题，一个问题是会导致两套消息群组服务都有topic缓存，产生不断互相加载的情况（seqId重复），另一个问题是消息同步涉及跨集群通信，要整体改造架构。IM网关作为IM中台，不涉及过多业务，一般都只涉及消息群组服务的发版，只要把控好发布质量，滚动升级的模式暂时够了，暂时没必要灰度。

• C端灰度采用什么策略？

        比较常用的策略是通过uid进行灰度，指定用户进入灰度环境，此时对于B端客服来说，会存在小得物或者生产环境接待用户的情况，这种情况是不可控的。单纯采用uid灰度覆盖的功能有限，需要B端和C端配合的功能不能够验证到。

• B端灰度采用什么策略？
          B端采用客服uid灰度是比较合理的，灰度人员从不同职场去筛选，这样就可以从不同职场、不同网络环境，不同人员的维度去做灰度验证。这里存在一个问题，客服相对不固定，灰度人员维护比较麻烦。

• C端进线用户和B端客服同时在灰度环境？
          为了满足C端用户和B端客服同时在灰度环境，需要在分配客服的时候，选择的客服人员也在灰度环境。对此我们针对C端增加了分流入口的灰度策略，B端增加了客服组的灰度策略，确保分流入口和客服组一一对应，保障了灰度的用户会分配给灰度的客服。

三、系统分析
1. 灰度场景

        从业务用例来看，我们灰度的群体是客服和用户，客服使用章鱼工作台和用户聊天，用户通过 App 端和小程序端进线来咨询问题，这个交互过程会产生以下几种灰度场景。

目前线上比较多的场景其实是旧版 App 端+灰度用户+灰度客服这种场景，因为客户端全量是在服务端全量发布之后进行的。

2. 灰度策略

灰度生产的目标就是尽可能多的验证上述的场景，为此我们制定了以下的灰度策略：

（1）用户uid范围灰度

        uid范围灰度可以帮我们验证整个App 端与服务端交互的逻辑，如进线、机器人问答、猜你想问、分配客服、人工会话、评价等功能。uid筛选的准则是在灰度范围的用户，7天平均进线量不能超过总进线量的3%。

（2）进线分流灰度

        有时一个功能需要用户和客服交互才能被验证到，所以需要用户和客服同时在灰度环境，这就需要将灰度的用户分配给灰度的客服，分配是基于咨询入口的，每个入口进来的用户都会被分配到关联的客服组。为此我们定义了一些特殊的灰度规则，如：

xdw-kefu-agent-gid: 14133836521****代表灰度的客服组，该客服组下的所有客服都会被灰度到小得物环境。

xdw-kefu-entryid: 12133836112****代表分流入口，从该入口进行咨询的用户都会被灰度到小得物环境。

筛选分流入口和客服组也有一定的标准：

• 分流入口和客服组要对应。

• 分流入口进线量不能超过总进线量的3%。

• 客服组总人数在50以内。

（3）客服uid灰度

        目前客服分布在不同的职场，这些职场的网络环境不同，使用人员也不同，灰度名单需要尽可能覆盖比较多的职场，所以也需要从各个职场中筛选一批客服进入灰度名单。

四、系统改造

        为了支持上述灰度策略，我们对 H5 和 App 端进行了相应的改造，将灰度标通过 head 头或者 cookie 传给 DLB，架构同学也针对 DLB 进行了改造，支持自定义 head 头的灰度策略。

1. HTTP 请求

        前端 Http 请求头带入流量标，自定义流量标以 xdw-kefu 开头。

• accessToken （员工 uid）支持各职场客服灰度

• xdw-kefu-agent-gid: 141338365**** //客服组id，支持整个组灰度

Accept: application/json, text/plain, */*Accept-Encoding: gzip, deflate, brAccept-Language: zh-CN,zh;q=0.9User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36accessToken: D9ECDE2F26C1CBA44734EA80EB704A4702BA9C81A5E48DC328832DBFB1947D1A350F52350******xdw-kefu-agent-gid: 141338365****,141338365****

2. 静态资源

        Js/CSS 静态资源通过 cookie 带入流量标。

Cookie: xdw-kefu-agent-gid=141338365*****,141338365*****; accessToken=D9ECDE2F26C1CBA44734EA80EB704A4702BA9C81A5E48DA61EDA9071F47E80C4E7E9A21C0B2A12A591C46411******

3. 长链消息

        H5/App 端长链消息通过消息头带入流量标

head: {  "xdw-kefu-entryid": "141338365*****", //分流入口  "xdw-kefu-uid": "112233",  //用户id  "xdw-app-version": "1.0.0",  //app版本  "xdw-device-id": "iOS/Android" //设备信息}

4. IM网关

• action和message消息增加head头。

• 将客户端流量标，附加到HTTP请求头传递给客服DLB。

五、架构

改造后的整体架构如上图所示，我们新增了 2 个 SLB 承载来自消息服务和客服工作台的流量。使用同一个 DLB 集群来进行流量调度。实现了以下灰度功能：

• 支持客服 uid（accessToken） + 客服组灰度。

• 支持用户 uid + uid 范围 + 分流入口灰度。

• 支持后端服务和 H5 静态资源灰度。

六、收益

在 X 版本发布中我们加入了小得物的节点，总体流程如下，整个发布是在白天进行，并且经过了生产流量的验证。发布总体比较顺利。

七、总结

        经过此次架构升级，我们实现了服务端灰度，覆盖进线、机器人问答、猜你想问、分配客服、聊天、评价，用户信息、服务追踪、寄售查询、订单查询等功能。前端灰度覆盖章鱼工作台、后台管理系统、工单系统。总体来说符合我们开始制定的目标。后续需要推进的事情还有很多，我们会持续蓄力。