一个架构常识：当调用方需要关心执行结果，通常使用RPC调用。

成都创新互联长期为上1000+客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为丹棱企业提供专业的网站制作、做网站，丹棱网站改版等技术服务。拥有10年丰富建站经验和众多成功案例,为您定制开发。

 
 
 
 

  
  
  
  
ret = PassportService::userAuth(name, pass); 
  
  
  
  
switch(ret){ 
  
  
  
  
 case(YES) : return YesHTML(); 
  
  
  
  
 case(NO) : return NoHTML(); 
  
  
  
  
 case(JUMP) : return 304HTML(): 
  
  
  
  
 default : return 500HTML(); 
  
  
  
  
} 
 
 
 
 

上一篇《服务化，耦合却更加严重》提到，执行结果的处理和业务强相关，则switch case应该放在上游业务方，而不应该放到底层通用服务。

登录页面调用passport服务，会根据passport服务的返回结果，区别执行登录成功，登录失败，执行错误。调用方关注执行结果时，不宜使用MQ通讯。

使用MQ通讯，调用方不能直接告之用户登录成功又或失败，阻塞住等待MQ通知回调不但使得编码复杂，还会引入消息丢失的风险，中间多加入一层，多此一举，基本没有人这么玩。

但如果调用方不关心执行结果，却仍然使用RPC调用，会引发上下游极大的耦合与瓶颈。

场景还原

有一个通用的上游服务，例如“帖子发布”服务，负责公司通用的帖子发布业务。有一些个性化的业务关心“用户发布帖子”这个事件，例如：

• 用户发布帖子后，大数据部门要更新用户的画像
• 用户发布帖子后，信息质量部门要异步检查帖子是否合规
• 招聘业务最近在做用户促活，如果用户发布的是招聘帖子，要增加积分
• …

个性化下游关注这个事件，但下游对事件的执行结果，“帖子发布”服务却并不关心，如果“帖子发布”服务通过RPC的方式去通知下游，就会有很大的问题。

耦合为何存在?

帖子发布服务，这本来应该是一个非常基础的服务，上游upper通过RPC调用将事件同步给事件关注业务方biz1/biz2/biz3：

• 一旦有新的业务需求要关注这个事件，修改代码的是通用上游upper，此时通用服务的owner就在心里骂娘了“为何有需求的是你，修改代码的却是我”
• 一旦业务侧出问题，会影响上游通用基础服务，此时通用服务的owner又在心里骂娘了“我ca，稳定性的KPI，全被兄弟部门毁了”
• 一旦业务侧接口升级，上游基础服务需要配合升级，此时通用服务的owner可能又会抱怨“为何被动升级的人总是我”

架构不合理，简直痛不欲生。

如何解耦呢?

如果事件发出方不关心订阅方的执行结果，不能用RPC，应该用MQ。

MQ能够做到上下游物理上和逻辑上都解耦：

• 物理上解耦，增加MQ之后，上游互不知道彼此的存在，不会建立物理连接了，大家都只与MQ建立物理连接
• 逻辑上解耦，事件发布方甚至不用知道哪些下游订阅了这个消息，新增消息的订阅方只需要连接MQ就行了，不需要上游关注

MQ是一个非常常见的物理上解耦、逻辑上也解耦的利器。

• 关注下游执行执行结果，用RPC;
• 不关注下游执行结果，用MQ，不用RPC;

这只是一个很小的优化点，但对于通知解耦却是非常有效。

【本文为专栏作者“58沈剑”原创稿件，转载请联系原作者】

标题名称：MQ—互联网架构解耦神器
地址分享：http://cdbrznjsb.com/article/djsjopd.html