我们来看一个案例。
前端页面上，用户在订单详情页确认完信息后，点击“确认支付”，发起余额支付。
这里，我们做如下3项假定。
1）后台程序暴露的“支付”Rest接口名为 order/pay。
2）后台程序对于“支付”的处理逻辑，我们简化成下面的业务流程。
3）后台程序是微服务结构，包括提供RestAPI接口的springmvc服务和后面的订单服务、账户服务。
那么，下面两种实现，你选择哪一种？
比较上面两种实现方式，第一种是在order/pay这个rest接口里先校验订单状态，通过后才调用订单服务的“支付订单”接口。 第二种是直接转发请求给订单服务的“支付订单”接口。
相比来说，第一种更靠谱一些。
Why？
看上去，虽然两种实现方式都能达到目的，第一种方式还多了一个前置的校验。为什么我建议采用第一种方式呢？
这是典型的程序业务处理的方式。——接收到请求入参后，先进行前置校验，如果校验失败直接终止返回，否则才走后面的业务处理流程。
有同学就说了，直接调用订单服务的“支付订单”接口，“支付订单”接口的实现里不是也有订单状态的前置校验吗？
从技术的角度来说，这是有区别的。“支付订单”作为一个业务处理接口，我们要做的控制会比较多，例如日志、耗时、幂等、锁等。因此，从这个角度来说，在需要支付订单的时候再调用，是不是更合理呢？
类似的案例，也包括，我们的mq消费者，在从队列里拿到消息后，先进行必要的判断和校验，然后再调用业务方法。而不是一上来就直接把参数丢给业务方法。
本文设计文稿自：https://www.processon.com/view/link/611e38c2e0b34d3511f7c479
标签：递餐,订单,程序实现,前置,校验,接口,--,支付,服务 From： https://www.cnblogs.com/buguge/p/17765857.html