首先，我们来看下，通常在支付形态的API接口中，使用都是Https协议+RSA证书体系，来完成整个交易的安全，那么这个notifyUrl必然也是这个协议和安全体系之下的。
其次，notifyUrl通常情况下由商户或用户提供，并且在支付接口的传入。那么问题来了，回调接口对于提供接口的一方是不可控制的，这些回调的接口的质量参差不齐，来源请求非常多，各自还需要做相互不影响，并发量跟正向支付请求同等量可能还要超过。
接下来我们来考虑如何设计一个回调请求notiflyUrl的中间件，来方便支付场景中非常重要的一环。
整个系统分为核心处理和商户回调请求业务管控。
核心处理：
代理接收层：主要使用同步EDAS RPC通讯框架，业务系统通过将需要回调的请求发送过来。再通过深度业务路由决策，分发到同步请求处理层或异步请求处理层。
同步请求处理层：处理即时回调的场景，如：扫码、网银等。
异步请求处理层：处理批量回调的场景，如：代扣、代发、充值等
补偿重试处理层：上面两类请求在指定重试范围内，通知失败，进入补偿重试。
业务管控：
回调商户黑白名单、URL管控、证书管控、路由计算、控台重发等。
整体架构图如下：
总结：
为了保证性能和优先URL通知到达，采用了先请求URL，再落库的方式（前提业务能自主补偿）。
通过同步和异步两层设计，异步中再采用队列分散型设计，再通过精准的路由策略计算，达到商户或更细粒度的业务操作维度的通知相互不影响。
发送者上面需要考虑Https协议支持，标准TLS1.0～1.2或更高，加密通讯算法上也需要更多支撑，JDK安全限制需要考虑。
外网出口再采用两类方式，一类专线管控类，通过正向代理统一出口（适合银行类通知），一类直接外网请求。
