优付系统结构如下。一个数据库之上，有商户接口（RestAPI）、运营后台（OMS）、商户门户这3个独立SSM应用，三者有各自不同的功能处理逻辑。
现在，我们需要制作一个补偿工具。当因系统版本发布等意外情况发出支付单时，应通过该工具手动补发。
[En]
Now, we need to make a compensation tool. When the payment order is issued due to accidents such as the release of the system version, it should be reissued manually through this tool.
工具要做到运用后台（OMS）系统。
但是，付款单下发逻辑在商户接口服务里。
那么，如何实现这个小小的优化需求呢？
方案如下：
-
商户接口服务新增一个RestAPI，供OMS调用。这样的话，要做好Rest接口的安全认证，防止误访问。那么，OMS对接就会有这些工作量。
-
考虑到是同一个数据库，所以，可以建一个表，OMS保存要补偿的订单。商户接口服务定时轮询这个表进行处理。不足：定时任务，处理时效慢。
-
利用消息队列（MQ）。这是最好也是最可靠的方案。OMS作为消息生产者，商户接口服务是消息消费者。保证了处理时效，局域网也不需要考虑接口安全。碰巧RabbitMQ消息中间件当前在系统里有使用，所以接入成本很小。