什么是耦合？耦合是一种架构状态，架构中不相关的代码、模块、服务和系统由于某种原因被链接在一起，独立性很差。影响相互影响，变化相互改变。.从感官上，如何发现系统中的耦合？作为一个技术人，经常在心里骂上下游，骂兄弟部门，“这东西跟我有什么关系？这件事我凭什么要配合？”。显然不应该有联动，但被动配合可能会造成潜在的耦合。但如果服务化不合理，一些个性化服务下沉到底层，就是典型的耦合。场景还原业务1、业务2、业务3，因为join导致数据库实例耦合在一起。为了实现通用数据库表-用户的解耦，实现了服务，将通用用户数据的访问从服务中抽象出来。由于服务不合理，会很少有个性化的业务逻辑，在底层服务中实现。典型的伪代码是：switch(biz_type){case(1):exec_logic1();case(2):exec_logic2();case(3):exec_logic3();default:exec_default();}为什么会导致耦合？可能假设业务1有新的个性化需求，本来是在业务1自己的代码中实现的，这是合理的，但是工程师S认为底层通用服务中也有少量业务1的个性化代码。经过评估，他发现在底层实现新的需求变更的代码最少，时间最短，于是他来到了底层服务。负责工程师B.-业务1工程师S：“我有一个小需求，请帮帮我”-底层工程师B：“底层实现个性化不合理”-业务1工程师S：“反正有switch的代码case，稍微改一下不麻烦，我这边实现起来很复杂，xxoo需要这样来做。”-底层工程师B：“真的很复杂，我来做吧”-…如果留下不合理的代码，就会有第一个被攻破，如果业务1被攻破，业务2就会被攻破。随着时间的推移，底层服务越来越复杂：业务1的个性化代码越来越多，业务2、业务3；业务1、业务2、业务3给底层工程师带来越来越多的需求；底层工程师逐渐成为项目的瓶颈，业务1、业务的项目2、业务3逐渐延迟，但底层工程师rs逐渐被指责；直到有一天，底层服务出来了。发现一个小bug，影响了业务1、业务2、业务3，历史总是惊人的相似：-业务1的大boss第一个在群里发疯：“技术怎么了，为什么systemdown”-Business1工程师S一脸无辜：“底层系统改造，工程师S的bug”嗯，不过这个原因好像大boss也解释不通...-底层服务工程师B有委屈：“……”。明明是业务方的需求，为什么修改代码的是我底层？业务代码有问题，为什么是底层怪罪我？每次在心里骂妈妈，都可能是系统耦合。如何解耦？业务码上浮，通用码下沉，服务周到。解决方案并不复杂。在分层架构中，每一层都有自己的职责，每一层都应该守住自己的底线。大家在做技术方案的时候遇到过这样的场景吗？“Lesscodeonyourside”和“Shorttimeonyourside”被用作设计妥协的理由，但更多的问题应该问：“如何合理地做？”》业务代码上浮，普通代码下沉，服务彻底。只是一个小小的优化点，但是对于底层服务的解耦非常有效。希望大家每天都有一点收获，让架构可以再好一点。【本文为专栏作家《58神剑》原创稿件，转载请联系原作者】点此阅读更多本作者好文
