基于 RPC 通信的微服务架构，其特点是一个服务依赖于其他服务返回的结果，只有依赖服务执行成功并返回后，这个服务才算调用成功。这种架构适用于用户请求是读请求的情况，就像下图所描述的那样，比如用户的一次 Feed API 请求，会调用 Feed RPC 获取关注人，调用 Card RPC 获取视频、文章等多媒体卡片信息，还会调用 User RPC 获取关注人的昵称和粉丝数等个人详细信息，只有在这些信息都获取成功后，这次用户的 Feed API 请求才算调用成功。
而基于 MQ 消息队列通信的架构，其特点是服务之间的交互是通过消息发布与订阅的方式来完成的，一个服务往 MQ 消息队列发布消息，其他服务从 MQ 消息队列订阅消息并处理，发布消息的服务并不等待订阅消息服务处理的结果，而是直接返回调用成功。
这种架构适用于用户请求是写请求的情况，就像下图所描述的那样，比如用户的写请求，无论是发文、评论还是赞都会首先调用 Feed API，然后 Feed API 将用户的写请求消息发布到 MQ 中，然后就返回给用户请求成功。如果是发文请求，发文服务就会从 MQ 中订阅到这条消息，然后更新用户发文列表的缓存和数据库；如果是评论请求，评论服务就会从 MQ 中订阅到这条消息，然后更新用户发出评论的缓存和数据库，以及评论对象收到评论的缓存和数据库；如果是赞请求，赞服务就会从 MQ 中订阅到这条消息，然后更新用户发出赞的缓存和数据库，以及赞对象收到的赞的缓存和数据库。这样设计的话，就把写请求的返回与具体执行请求的服务进行解耦，给用户的体验是写请求已经执行成功，不需要等待具体业务逻辑执行完成。
总结一下就是，基于 RPC 通信和基于 MQ 消息队列通信的方式都可以实现微服务的拆分，两者的使用场景不同，RPC 主要用于用户读请求的情况，MQ 主要用于用户写请求的情况。对于大部分互联网业务来说，读请求要远远大于写请求，所以针对读请求的基于 RPC 通信的微服务架构的讨论也更多一些，但并不代表基于 MQ 消息队列不能实现，而是要区分开它们不同的应用场景。
