服务间调用，RPC和MQ如何选择？

前言

在微服务架构中，服务间调用是十分常见的场景。通常情况下，我们会直接使用微服务框架提供的RPC协议进行服务间调用。
但在没有使用微服务框架的小型集群中，我们通常手写HTTP请求来完成服务间调用。
这里我们就来探讨下，在一些场景中，我们如何选择服务间调用的方式……

RPC与MQ的区别

RPC

Remote Procedure Call，远程过程调用。具体的技术实现方式有很多，我们就以HTTP为例。
上游服务发送HTTP请求，调用下游服务提供的接口，完成服务间通信。
优势：技术实现简单。
劣势：需要等待下游服务的执行结果，必要时还需要处理调用异常。

MQ

Message Queue，消息队列。
上下游服务在同一topic中，上游服务生产一条消息，下游服务消费消息，完成服务间通信。
优势：服务间完全解耦，不需要关心执行结果。
劣势：无法保证实时性和强一致性。

总结

结合上述两种服务间调用的优劣势，再结合相关业务，我们可以大致做一下总结。

选择RPC的场景：

上游服务需要关注下游服务的执行结果，也就是说下游服务执行的结果，会决定上游服务接下来的逻辑该如何处理。
例1.支付完成后，支付服务调用相应的业务系统，完成相应的操作。如：开通账号，开通会员等……
例2.活动页服务收到表单提交后，调用对应服务完成开通账号，创建订单等……

选择MQ的场景：

不关心下游服务的执行结果，能接受或能暂时接受消息丢失或执行失败的情况。
例1.消息通知类。如：业务系统调用通知服务，发送短信、邮件或微信消息等……
例2.数据同步类。如：业务系统在一些关键节点上产生的数据通过MQ推送到数据平台。

---

题外话

上述只是列举了几种情况，提供了一点点思路。具体选择哪种方案，一定要集合自身的业务。
如果可以接受短暂的数据不一致，且有相应的补偿机制，支付服务向下游服务的调用也可以通过MQ来实现。
如果业务需要很强的一致性和实时性，短信或邮件通知也可以通过RPC来实现。