微信客服机器人
总体流程
- 当有新的消息时，微信主动请求微服务接口，通知有新消息。
- 微服务主动向微信拉取消息列表（最多1000条）。
- 对消息列表中的每一个消息向机器人进行提问。
- 机器人返回答案。
- 将答案进行处理后，通过微信接口向微信用户进行发送。
微信功能说明文档（步骤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、回调消息通知
完成准备工作以后，并正确的配置了回调路径后，我们开始接收回调消息通知。
这里注意一下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消费者就可以很轻松的增加单位时间内的处理量。
