微信客服机器人（踩坑记录、SpringBoot、企业微信）

转载请注明出处：https://www.jjput.com/archives/wei-xin-ke-fu-ji-qi-ren

总体流程

1. 当有新的消息时，微信主动请求微服务接口，通知有新消息。
2. 微服务主动向微信拉取消息列表（最多1000条）。
3. 对消息列表中的每一个消息向机器人进行提问。
4. 机器人返回答案。
5. 将答案进行处理后，通过微信接口向微信用户进行发送。

微信功能说明文档（步骤1、2、5）

0、准备工作

在第一步接受微信消息前，需要进入微信客服后台配置。

根据文档3.1-支持Http Get请求验证URL有效性（微信这方面有很多份文档，这点必须吐槽一下，有些过时了按照上面基本不对，基本都不是特别完善），我们需要完成一个Get请求，以用于微信配置时验证url正确性。

注意验证url与下面回调url都应该是相同路径，只是请求方式不同(Get&Post)

接收到Get请求后，还需要正确的解密数据，将解密后的数据返回。

微信解密说明文档

解不出来，可以借助官方解密demo（支持C++、Python、PHP、java、C#、golang、node）

1、回调消息通知

完成准备工作以后，并正确的配置了回调路径后，我们开始接收回调消息通知。

详细查看文档-3.2支持Http Post请求接收业务数据

这里注意一下POST接收的消息体类型是text/xml不是application/xml!!更不可能是application/json;charset=UTF-8!!!

做到这我真的快受不了，必须喷一下，他娘的微信的api文档他自己验证过没有？这就是堂堂一线大厂？对外公开文档如此不严谨。

2、主动获取消息列表

这一步我们才是真正的获取到用户给我们发送到消息。

这里没什么好说的，按照官方文档可以走得通。

最后说明一下cursor这个参数，第一次可以不带，后续请求务必带上，该字段主要过滤已经接收过的消息，避免重复消费。

当然我们自己还要做些策略，不要全信官方！！

我这里将每次的msgid做了存储。消费策略是先判断消息时长未超过30分钟->msgid未被记录（redis缓存msgid，30分钟超时）。

5、发送消息

这里直接参照官方文档走即可，并没有什么坑踩。

并且官方支持日常聊天的所有消息格式：

消息格式(msgtype)

msgtype	说明
text	文本
image	图片
voice	语音
video	视频
file	文件
location	地理位置
msgmenu	菜单
event event_type=enter_session	用户进入会话
event event_type=msg_send_fail	消息发送失败

机器人（步骤3、4）

机器人这边我不做过多介绍，考虑到每个人选择不同（我自己是用阿里的客服机器人）。

面上看上去只有两个步骤，但根据公司业务需求，背后的逻辑可能会非常多，比如什么情绪判断，主动接入人工，拟人化话说等等。

设计文档

最后我给出自己的部分设计方案，希望大家探讨，有不合理之处欢迎指正。感激不尽！🙏

消息队列

我这里设计了两个队列（用的是RabbitMQ）：

• WechatIssueMsg：回调接收到消息通知以后，尽可能的少做任何耗时操作，因为这里是所有流量的入口。做完基本校验以后（其实我觉得可以狠点，校验个锤子，分发下去后各个消费者自己校验）。消费者收到消息后，开始主动拉取消息列表，只进行消费策略过滤，将未消费的下发到WechatMsgHandler队列处理。
• WechatMsgHandler：处理实际消息，与机器人通讯，并将机器人返回的消息发送给用户。

WechatMsgHandler这里我考虑的很近，是否要加这个队列，最后还是决定要加。

因为主动拉取消息列表这个操作的时候，很可能一次性拉到非常多的消息（假如100个人同时发给客服消息），明显的当前的这个消费者会处理非常久。其实10个人同时发就会明显受不了。

但如果我通过再加一个消息队列，进行分流处理，就不一样了。WechatIssueMsg的消费者仅仅只是遍历一边列表，根据消费策略过滤已消费的，下发未消费的。这个过程非常快。

后期只需要加WechatMsgHandler消费者就可以很轻松的增加单位时间内的处理量。