上个月接了个活客户的诉求听起来特简单微信里收到的客户消息能不能同步到他们公司的ERP系统里去我当时拍着胸脯说没问题调API就行。结果真动手才发现没想的那么轻松——微信那头是消息流ERP那头是业务表两边的数据模型根本对不上。更麻烦的是客户还提了一堆要求要实时、要可靠、不能丢、最好还能让ERP反向往微信发消息。我翻了三天资料把能想到的数据传递方式都研究了一遍最后归纳出4种方案。每种我都拿小demo跑过各有各的适用场景也各有各的坑。先说清楚这4种不是非此即彼的实际项目里经常组合着用但选型之前你得先搞清楚每种的特点。这篇就把这4种方式掰开讲清楚特别是做微信和第三方系统对接的同学选型的时候能少走点弯路。方式一API直接调用这是最直接的方式——你的业务系统直接调Eyun的RESTful API想发消息就调发送接口想拉数据就调查询接口。所有请求都是JSON格式带上Token做鉴权就行。典型场景ERP里某个订单状态变了触发一个事件事件处理器调sendText给客户发个通知。整个链路就是你主动去调调完就完事。要点有两个一是Token鉴权每个请求头里得带上Authorization二是wId指定实例你有多个微信号的话得告诉API用哪个号发。这俩搞错了要么401要么发错号我早期都踩过。优点实现最简单会调HTTP就行控制力最强想什么时候发就什么时候发。对ERP这种老系统特别友好不用ERP改造啥你这边主动调就行。缺点只能你主动去调微信那头有啥事你不知道。比如客户给你回了消息你不调查询接口就感知不到。而且要是ERP那边频繁触发你得自己控制频率别把API打满了。我早期没做限流搞促销的时候ERP一口气触发了200多条发送请求直接把实例打到限流后面半小时发啥都报错。还有个容易忽略的点Token一定要放服务端的环境变量里别硬编码进代码更别提交到Git仓库。我有同事把Token写死在代码里提交了第二天额度被刷光血泪教训。这种方式适合业务系统驱动微信的单向场景更多接口细节可以查 Eyun开发文档发送类的接口参数都列得很清楚。方式二Webhook中转这种方式反过来——微信那头有事了Eyun主动推给你你接收后再转发给第三方系统。典型场景客户在微信里发了条消息Eyun通过Webhook推到你的服务你的服务把消息格式转换一下转发给ERP或者CRM。要点也有两个一是消息体格式转换Eyun推过来的是它自己的JSON结构ERP那边要的可能是另一种格式中间得做一层映射二是签名校验你的回调地址是公网可访问的不做验签别人伪造个请求进来就乱套了。优点实时性最好事件发生几秒内就能推过来不用你主动轮询。缺点你得有个公网可访问的服务来接收而且5秒内必须返回200不然Eyun会认为你没收到然后重推。所以收到请求后别在回调里干耗时的事先返回200真正的处理丢队列异步做。下面是我用的Webhook中转格式转换的实现把Eyun推过来的消息转成ERP能认的格式from flask import Flask, request, jsonify import hashlib, hmac, requests, threading app Flask(__name__) WEBHOOK_SECRET your_secret def verify(raw_body, signature): expected hmac.new(WEBHOOK_SECRET.encode(), raw_body, hashlib.sha256).hexdigest() return hmac.compare_digest(expected, signature) def to_erp_format(event): 把Eyun消息格式转成ERP需要的格式 return { customer_id: event.get(fromUser), message: event.get(content), msg_type: event.get(msgType), received_at: event.get(timestamp), source: wechat } def forward_to_erp(payload): 异步转发给ERP系统 try: requests.post(https://erp.example.com/api/messages, jsonpayload, timeout10) except Exception as e: # 失败进队列后面重试 retry_queue.put(payload) app.route(/webhook/wechat, methods[POST]) def receive(): raw request.get_data() if not verify(raw, request.headers.get(X-Signature, )): return jsonify({code: 403, msg: 验签失败}), 403 event request.get_json() erp_payload to_erp_format(event) threading.Thread(targetforward_to_erp, args(erp_payload,)).start() return jsonify({code: 0, msg: ok}), 200这段代码的关键是先验签、再转换、异步转发、立即返回。别在回调里同步等ERP响应ERP那边慢一点你就超时了Eyun一重推就重复处理。再说下格式转换这块的细节。Eyun推过来的JSON字段名是它自己定义的一套比如fromUser、msgType、contentERP那边要的字段名可能完全不一样比如customer_id、message_type、message_body。这层映射看着简单但字段一多就容易漏。我的做法是维护一张映射表新加字段的时候改表不改代码省得每次发版。还有个坑是消息类型对不齐。微信里有文本、图片、语音、视频、名片、链接好几种但ERP那边可能只认文本和附件两类。图片语音视频在ERP里都得转成附件处理转发的时候得带上原消息类型方便ERP那边区分。我早期把图片消息当文本转content字段是个URLERP那边显示一串网址客户看了半天没搞懂是啥。方式三数据库共享这种方式不直接在系统间传消息而是让Eyun把消息写到一个共享数据库里第三方系统自己去读。典型场景消息记录要同步给好几个系统——ERP要看、CRM要看、BI报表也要看。你要是每个系统都搞一套Webhook转发维护成本太高。不如统一写到一个库里谁要用谁来读。要点一是消息去重Webhook可能重推写库前按msgId去重不然同一条消息入库两次二是增量同步第三方系统读的时候别每次全量扫记个最后读取的时间戳只读新增的。还有个隐藏的坑——时区问题我用的时间戳是UTC第三方系统按本地时间读没对齐导致漏读了一批消息排查了一下午。优点一对多分发天然支持多个系统读同一个库互不影响数据持久化在库里即使第三方系统当时挂了恢复后还能补读。对那种跑批处理、做报表的系统特别合适它们本来就不在乎实时性要的是数据全和稳定。缺点实时性差一截得第三方系统主动来读读的频率决定延迟。而且共享数据库是个耦合点表结构一改所有下游都得跟着改。我之前加了个字段结果两个下游系统解析报错折腾了一天。这种方式适合消息要给多个系统用、对实时性要求没那么高的场景。Webhook怎么配、回调数据长啥样可以翻翻 Eyun平台 上的说明回调格式和重试机制都讲得挺细。方式四消息队列桥接这种方式是Webhook中转的升级版——Eyun的回调不直接转给第三方系统而是先丢到消息队列RabbitMQ或者Kafka第三方系统作为消费者从队列里取。典型场景一条微信消息要触发多个系统响应——CRM要记录、客服系统要弹窗、风控系统要分析。你要是Webhook里依次调三个系统一个慢全堵住。丢队列里各系统各消费各的互不拖累。要点一是队列缓冲消费方处理不过来的时候消息在队列里排队不会丢二是消费幂等同一个消息可能被投递多次队列重试机制消费方得能识别重复消息。我用Kafka的话会按msgId做消费去重RabbitMQ的话用消息幂等表原理都一样。优点解耦最彻底生产者和消费者互不感知可靠性最高队列持久化消费确认消息基本不会丢扩展性好加个消费方就是加个订阅不用动生产者。消费方挂了重启后还能从上次的位置继续消费不丢数据。缺点架构最复杂得多维护一套消息队列排查问题链条长消息从Eyun到队列到消费者哪一环出问题都得查。而且引入队列后运维成本也上去了得监控队列堆积、消费延迟这些指标不然队列堵了你都不知道。四种方式对比我把四种方式放一张表里对比下选型的时候一目了然对比维度API直接调用Webhook中转数据库共享消息队列桥接实时性取决于调用频率秒级准实时分钟级依赖轮询秒级依赖消费速度实现复杂度低中中高可靠性中需自己重试中依赖回调可达高落库不丢高队列持久化适用规模小单系统对接中1对1转发中1对多读取大多系统并行响应数据方向业务系统→微信微信→业务系统微信→多系统微信→多系统怎么选我有个简单的判断标准只往微信发不收的用方式一微信往一个系统转的用方式二消息要给好几个系统读的用方式三一条消息要触发多个系统实时响应的用方式四。要是你拿不准先从方式一或者方式二起步跑起来再迭代别一上来就上方式四那种重型架构杀鸡用牛刀反而把自己绕进去。实际项目里这几种经常组合着用。我给客户最终上线的方案就是方式二方式四——Webhook先把消息接进来验签后丢KafkaERP、CRM、风控各消费各的。既保证了实时性又不会因为某个系统慢拖累全局。ERP那边还需要反向往微信发通知那就再叠加方式一业务系统该调sendText就调。三种方式各管一摊互不冲突。最后做完这个项目我最大的感受是对接方式没有最好只有最合适。客户的ERP是老系统接口慢得要命一开始我硬上Webhook直接转结果ERP一卡就把回调全拖超时了Eyun疯狂重推消息重复处理一团糟。后来改成队列缓冲才消停。选型之前先想清楚三件事你要对接几个系统、对实时性要求多高、第三方系统接口稳不稳。这三个问题答清楚了该用哪种方式基本就定了。还有一个容易漏的考量——可靠性兜底。不管选哪种方式都得想清楚消息丢了怎么办。方式一方式二这种实时传递的失败重试得自己写方式三方式四这种落库落队列的相对好兜底但消费方挂了也得有补偿机制。我的习惯是重要消息除了实时传递还会异步落一份到库里万一实时通道出问题还能从库里捞回来补处理。多花点存储换的是心里踏实。如果你刚开始搞微信和第三方系统的对接建议先把 Eyun开发文档 通读一遍把API的能力边界摸清楚再动手。接口能干啥、不能干啥心里有数了选型的时候才不会瞎拍脑袋。写代码这事儿思路对了事半功倍。希望这篇能帮你少踩点坑。
