💡 当调用方需要获取执行结果时，应该使用RPC（远程过程调用）。例如，用户登录页面需要根据passport服务的返回结果来确定登录是否成功，此时RPC能够提供同步调用的能力，方便调用方获取即时反馈。
💡 当调用方不关心执行结果时，应该使用MQ（消息队列）来进行解耦。例如，帖子发布服务只需要发布帖子事件，而不需要关心下游服务（如大数据、信息质量部门）的处理结果，MQ可以实现异步通信，避免上下游之间的耦合。
💡 使用RPC可能导致上下游耦合。如果上游服务通过RPC通知下游，则新增或修改下游业务时，上游服务也需要修改，这增加了上游服务的维护成本和风险。
💡 MQ能够实现物理和逻辑上的解耦。上游服务和下游服务通过MQ进行通信，彼此之间无需直接建立连接，新增下游服务时，只需订阅相应的消息即可，无需修改上游服务的代码。
💡 选择RPC还是MQ取决于业务需求。如果需要同步获取结果，则选择RPC；如果不需要同步获取结果，则选择MQ。理解这两种通信方式的适用场景，有助于构建更灵活、可扩展的系统架构。
58沈剑 2025-07-16 07:16 广东
MQ是架构解耦利器，能用MQ就不要用RPC，这个观点对吗？
什么时候用RPC？
当调用方需要关心执行结果，通常使用RPC调用。
登录页面调用passport服务，会根据passport服务的返回结果，区别执行登录成功，登录失败，执行错误。
ret = PassportService::userAuth(name, pass);switch(ret){case(YES) : return YesHTML();case(NO) : return NoHTML();case(JUMP) : return 304HTML():default : return 500HTML();}
调用方关注执行结果时，使用RPC。
如果强行使用MQ进行上下游解耦呢？
如果强行使用MQ进行上下游解耦呢？
使用MQ通讯，调用方不能直接告之用户登录成功又或失败，阻塞住等待MQ通知回调不但使得编码复杂，还会引入消息丢失的风险，中间多加入一层，多此一举，基本没有人这么玩。
那能否一律使用RPC调用呢？
不能。如果调用方不关心执行结果，却仍然使用RPC调用，会引发上下游极大的耦合与瓶颈。
场景还原
有一个通用的上游服务，例如“帖子发布”服务，负责公司通用的帖子发布业务。有一些个性化的业务关心“用户发布帖子”这个事件，例如：
1. 用户发布帖子后，大数据部门要更新用户的画像；
2. 用户发布帖子后，信息质量部门要异步检查帖子是否合规；
3. 招聘业务最近在做用户促活，如果用户发布的是招聘帖子，要增加积分；
4. …
个性化下游关注这个事件，但下游对事件的执行结果，“帖子发布”服务却并不关心，如果“帖子发布”服务通过RPC的方式去通知下游，就会有很大的问题。
耦合为何存在？
帖子发布服务，这本来应该是一个非常基础的服务，上游upper通过RPC调用将事件同步给事件关注业务方biz1/biz2/biz3：
1. 一旦有新的业务需求要关注这个事件，修改代码的是通用上游upper，此时通用服务的owner就在心里骂娘了“为何有需求的是你，修改代码的却是我”；
2. 一旦业务侧出问题，会影响上游通用基础服务，此时通用服务的owner又在心里骂娘了“我ca，稳定性的KPI，全被兄弟部门毁了”；
3. 一旦业务侧接口升级，上游基础服务需要配合升级，此时通用服务的owner可能又会抱怨“为何被动升级的人总是我”；
架构不合理，简直痛不欲生。
如何解耦呢？
如果事件发出方不关心订阅方的执行结果，不能用RPC，应该用MQ。
MQ能够做到上下游物理上和逻辑上都解耦：
1. 物理上解耦，增加MQ之后，上游互不知道彼此的存在，不会建立物理连接了，大家都只与MQ建立物理连接；
2. 逻辑上解耦，事件发布方甚至不用知道哪些下游订阅了这个消息，新增消息的订阅方只需要连接MQ就行了，不需要上游关注；
稍作总结
MQ是一个非常常见的物理上解耦、逻辑上也解耦的利器：
1. 关注下游执行执行结果，用RPC；
2. 不关注下游执行结果，用MQ，不用RPC；
这只是一个很小的优化点，但对于通知解耦却是非常有效。
知其然，知其所以然。
思路比结论更重要。
AI辅助创作，多种专业模板，深度分析，高质量内容生成。从观点提取到深度思考，FishAI为您提供全方位的创作支持。新版本引入自定义参数，让您的创作更加个性化和精准。
鱼阅，AI 时代的下一个智能信息助手，助你摆脱信息焦虑