1. 同步处理--上游请求我，我同步请求下游，收到下游响应后返回上游结果。
1）主要关注上游请求我、我请求上游的参数保持一致性进行透传。
2）调下游发生异常，通讯失败--如超时等，应该根据具体业务判断，是返回上游处理中还是返回上游失败（有些业务场景可以认为通讯失败也是失败）。
3）调下游发生异常，是否有重试机制、是否有补偿机制。重试机制--比如重发一次，下游是否做了幂等？补偿机制--异常判定成处理中，可以异步起个调度，定时捞取处理中交易进行查询。
2. 异步处理--上游请求我，我同步返回已受理、处理中等，落库后，我起个调度，请求下游，收到下游响应结果再通知上游。自己系统可以控制处理进度，避免上游短时大量交易并发对我的系统造成压力。
3. 同步异步同时存在时，可能会出现一些问题：
1）由于网络原因，或者下游处理能力等原因，导致异步返回比同步响应快，一般谁先回来先处理谁。比如原交易还在路上，查询交易结果或者异步通知的交易结果已经回来了。需要考虑本系统的处理是否有问题，尤其是控制交易状态：终态不能更新、终态不能反复更新（否则可能重复触发后续处理流程，比如重复发Q）
2）同步比异步结果先返回，正常情况下应该是这样的。需要考虑的问题同上。
3）异步调用因为流程中断了，所以明确结果后一般需要通过调用上游接口或者给上游发Q的方式，通知上游交易结果。关于Q使用的问题，再单独写一下可能出现的问题。