什么是耦合？耦合是一种架构状态，架构中不相关的代码、模块、服务和系统由于某种原因被链接在一起，独立性很差。影响相互影响，变化相互改变。.从感官上，如何发现系统中的耦合？作为一个技术人，经常在心里骂上下游，骂兄弟部门，“这东西跟我有什么关系？这件事我凭什么要配合？”。显然不应该有联动，但被动配合可能会造成潜在的耦合。今天我们来看一个RPC错用的耦合场景。架构常识：当调用者需要关心执行结果时，通常使用RPC调用。ret=PassportService::userAuth(name,pass);switch(ret){case(YES):returnYesHTML();case(NO):returnNoHTML();case(JUMP):return304HTML():default:return500HTML();}之前的文章《明明服务化了，为啥耦合更加严重了?》提到，执行结果的处理与业务强相关，所以switchcase应该放在上游业务端，而不是底层的通用服务。登录页面调用passport服务，根据passport服务的返回结果，区分登录成功、登录失败、执行错误。当调用者关注执行结果时，不适合使用MQ通信。如果强行使用MQ通信，调用方无法直接告诉用户登录成功或失败。阻塞等待MQ通知回调，不仅编码复杂，还会引入消息丢失的风险。中间多加一层是画蛇添足，基本没人做这个Play。但是，如果调用者不关心执行结果，仍然使用RPC调用，就会造成上下游很大的耦合和瓶颈。场景还原有一个通用的上游服务，比如“postpublishing”服务，负责公司通用的postpublishing业务。有一些个性化服务关心“用户发帖”事件，例如：用户发帖后，大数据部门需要更新用户画像；用户发帖后，信息质量部门需要异步检查帖子是否合规；做用户推广时，如果用户发布招聘帖，需要加分；…个性化下游关注这个事件，但是事件的下游执行结果，“发布后”服务不关心，如果“发布后”服务通过RPC通知下游就会有大问题。为什么耦合存在？发布服务，这应该是一个非常基础的服务。上游上层通过RPC调用将事件同步给事件关注的业务方biz1/biz2/biz3：(1)一旦有新的业务需求，关注这个事件，修改代码的就是一般上游上层.这时，总服的老板心里在骂，“为什么需要的是你，修改代码的是我”；（2）一旦业务端出了问题，就会影响到上游的总务基础服务，此时总务老板心中暗骂，“我靠，稳定的KPI都被兄弟部门给毁了”";(3)业务端接口升级后，需要升级上游基础服务。这时候，一般服务的老板可能会抱怨“为什么被动升级的总是我”；结构不合理，差点疼死。如何解耦？如果事件发送者不关心订阅者的执行结果，则不能使用RPC，应该使用MQ。MQ可以同时实现上下游的物理和逻辑解耦：（1）物理解耦。添加MQ后，上游不知道对方的存在，不会建立物理连接。每个人只与MQ建立物理连接。;(2)逻辑解耦，事件发布者甚至不需要知道有哪些下游订阅了这条消息，新消息的订阅者只需要连接MQ，不需要上游关注；MQ是一个很常见的物理解耦，逻辑解耦的利器。关注下游执行的执行结果，使用RPC。不关注下游执行结果，用MQ代替RPC。这只是一个小的优化点，但是对于通知解耦是非常有效的。希望每天都有一点收获，结构会好一点。【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】点此阅读更多该作者好文
