分享一例设计方案：同一系统里不同应用服务之间的通信

优付系统结构如下。一个数据库之上，有商户API（RestAPI）、OMS运营后台、商户Portal门户这3个独立部署的SSM应用，三者各有不同的职责。

现在呢，要在OMS运营后台开发一个补偿工具。当付款单下发因为系统发版等意外导致失败时，则人为通过这个工具，来选择需要重发的订单并交由系统重发。

但是，付款单下发逻辑在商户API服务里。

那么，如何实现这个小小的优化需求呢？

分析如下几种方案：

• 方案1. 商户API服务新增一个RestAPI，供OMS调用。这样的话，要做好Rest接口的安全认证，防止非法访问。相应地，OMS对接这个RestAPI也会有一些工作量。

• 方案2. 考虑到是同一个数据库，所以，可以创建一个订单重发表，OMS保存要补偿的订单。商户API通过spring schedule来定时轮询这张数据表进行重发。这个方案的实现成本比较小，可取。小小的不足是，定时任务，时效会偏慢。

• 方案3. 借助消息中间件（当前系统已集成RabbitMQ）。OMS作为消息生产者，商户API服务是消息消费者。消息中间件的可靠传输、即时消费、易于使用的优势，让这个方案具有闪光点。

• 方案4. RPC调用也是不错的选择，例如dubbo。当前这个系统未有效使用RPC，暂不考虑这个方案。

以上每一种方案，幂等是必不可少的。