原创投稿
  1. 趣知天下事首页
  2. 科技
  3. 技术

凭啥修改代码的是我？原来这就是耦合！

糖太宗 • • 技术 • 阅读 29
你有没有遇到过这样的场景？
（1）硬件升级，要换一台高配机器；
（2）网络重新规划，若干服务器要调整机架；
（3）服务器当机，要重新部署恢复服务；
…
 
凭啥修改代码的是我？原来这就是耦合！
更具体的，如上图：数据库换了一个ip，此时往往连接此数据库的上游需要修改配置重启，如果数据库有很多上游调用方，改配置重启的调用方会很多，每次换ip的成本往往很高，成为大家共性的痛点。
 
由A的调整（数据库换ip），配合修改和调整的却是BCDE（改配置重启），BCDE内心非常的郁闷：明明换ip的是你，凭什么配合重启的却是我？
 
根本上，这是一个“架构耦合”的问题，是一个架构设计上“反向依赖”的问题，本文将讨论的是架构设计中常见的“反向依赖”的设计，以及对应的优化方案，希望对大伙有所启示。
 
如何寻找不合理的“反向依赖”耦合？
方法论：变动方是A，配合方却是BCDE。
（或者说需求方是A，改动方却是BCDE。）
画外音：想想“换IP的是你，配合重启的却是我”更好记忆。
 
如果系统中经常出现了这类情况，就是“反向依赖”的特征，往往架构上有优化的空间。
 
场景1：公共库导致耦合。
凭啥修改代码的是我？原来这就是耦合！
三个服务s1/s2/s3，通过一个公共的库biz.jar来实现一段业务逻辑，s1/s2/s3其实间接通过biz.jar耦合在了一起，一个业务s1修改一块公共的代码，导致影响其他业务s2/s3，架构上是不合理的。
 
优化方案1：业务垂直拆分。
凭啥修改代码的是我？原来这就是耦合！
如果biz.jar中实现的逻辑“业务特性”很强，可以拆分为biz1.jar/biz2.jar/biz3.jar，来对s1/s2/s3进行解耦。这样的话，任何业务的改动，影响范围只是自己，不会影响其他人。
 
优化方案2：服务化。
凭啥修改代码的是我？原来这就是耦合！
如果biz.jar中实现的逻辑“业务共性”很强，可以将biz.jar优化为biz.service服务，来对s1/s2/s3进行解耦。服务化之后，兼容性能更好的通过接口自动化回归测试来保证。
 
基础服务的抽象，本身是一种共性聚焦，是系统解耦常见的方案。
 
场景2：服务化不彻底导致耦合。
凭啥修改代码的是我？原来这就是耦合！
服务化是解决“业务共性”组件库导致系统耦合的常见方案之一，但如果服务化不彻底，service本身也容易成为业务耦合点。
 
典型的服务化不彻底导致的业务耦合的特征是，共性服务中，包含大量“根据不同业务，执行不同个性分支”的代码。

switch (biz-type)

case biz-1 : exec1

case biz-2 : exec2

case biz-3 : exec3

…

 
在这种架构下，biz-1/biz-2/biz-3有个性的业务需求，可能导致修改代码的是共性的biz-service，使其成为研发瓶颈，架构上也是不合理的。
 
优化方案：业务特性代码上浮，业务共性代码下沉，彻底解耦。
凭啥修改代码的是我？原来这就是耦合！
把swithc case中业务特性代码放到业务层实现，这样biz-1/biz-2/biz-3有个性的业务需求，升级的是自己的业务系统。
 
场景3：notify的不合理实现导致的耦合。
凭啥修改代码的是我？原来这就是耦合！
《究竟什么时候该使用MQ？》一文中有一类业务场景，消息发送方不关注消息接收方的执行结果，如果采用调用的方式来实现通知，会导消息发送方和消息接收方耦合。
 
如何新增消息接收方biz-4，会发现修改代码的是消息发送方，新增一个对biz-4的调用，极不合理。
 
优化方案：通过MQ实现解耦。
凭啥修改代码的是我？原来这就是耦合！
消息发送方upper将消息发布给MQ，消息接收方从MQ去订阅，任何新增对消息的消费，upper都不需要修改代码。
 
场景4：配置中的ip导致上下游耦合。
凭啥修改代码的是我？原来这就是耦合！
即“缘起”中举的例子，下游服务换ip，可能导致多个服务调用方修改配置重启。上下游间接的通过ip这个配置耦合在了一起，架构不合理。
 
优化方案：通过内网域名而不是ip来进行下游连接。
凭啥修改代码的是我？原来这就是耦合！
如果在配置中使用内网域名来进行下游连接，当下游服务或者数据库更换ip时，只需要运维层面将内网域名指向新的ip，然后统一切断原有旧的连接，连接就能够自动切换到新的ip上来。这个过程不需要所有上游配合，非常帅气，强烈推荐！
总结
如何发现系统架构中不合理的“反向依赖”设计？
（1）变动方是A，配合方却是BCDE；
（2）需求方是A，改动方却是BCDE；
此时往往架构上可以进行解耦优化。
常见反向依赖如何优化？
（1）公共库导致耦合。
优化一：如果公共库是业务特性代码，进行公共库垂直拆分。
优化二：如果公共库是业务共性代码，进行服务化下沉抽象。
 
（2）服务化不彻底导致耦合。
特征：服务中包含大量“根据不同业务，执行不同个性分支”的代码。
优化方案：个性代码放到业务层实现，将服务化更彻底更纯粹。
 
（3）notify的不合理实现导致的耦合。
特征：调用方不关注执行结果，以调用的方式去实现通知，新增订阅者，修改代码的是发布者。
优化方案：通过MQ解耦。
 
（4）配置中的ip导致上下游耦合。
特征：多个上游需要修改配置重启。
优化方案：使用内网域名替代内网ip，通过“修改DNS指向，统一切断旧连接”的方式来上游无感切换。
相关推荐：
《InnoDB并发如此高，原因竟然在这？》
《InnoDB，七种锁》
《InnoDB索引，终于懂了》
《InnoDB，四种事务的隔离级别实现》
《InnoDB，调试死锁的方法！》
调研：
贵司修改IP，需要重启么？

发布者：糖太宗，转载请注明出处：https://www.qztxs.com/archives/science/technology/6317

赞 (0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
糖太宗糖太宗
0 0
上一篇 2022年5月12日 下午11:50
下一篇 2022年5月12日 下午11:52

相关推荐

  • 为什么MySQL要升级组复制？1分钟系列 技术

    为什么MySQL要升级组复制？1分钟系列

    前几天发了《Galera，MySQL主从之外的另一种选择》之后，很多朋友在评论里留言： “这不就是Oracle Rac吗？” “这不就是MGR吗？” …   思路比结论重要，为什么比是什么重要，今天就花1分钟，说下这里面架构演进的思路。 画外音：大家不想听底层细节，就不深入细节了。   最早的数据库都是单机的，其最大的痛点是啥？ 无法线性扩展。   磁盘能力...

    糖太宗 糖太宗
    2022年5月11日
    1700
  • 7000字+24张图带你彻底弄懂线程池 技术

    7000字+24张图带你彻底弄懂线程池

    大家好。今天跟大家聊一聊无论是在工作中常用还是在面试中常问的线程池，通过画图的方式来彻底弄懂线程池的工作原理，以及在实际项目中该如何自定义适合业务的线程池。 一、什么是线程池 线程池其实是一种池化的技术的实现，池化技术的核心思想其实就是实现资源的一个复用，避免资源的重复创建和销毁带来的性能开销。在线程池中，线程池可以管理一堆线程，让线程执行完任务之后不会进行...

    糖太宗 糖太宗
    2023年1月26日
    1200
  • 帖子中心，1亿数据，架构如何设计？ 技术

    帖子中心，1亿数据，架构如何设计？

    帖子中心，是互联网业务中，一类典型的“1对多”业务，即：一个用户能发布多个帖子，一个帖子只有一个发布者。   随着数据量的逐步增大，并发量的逐步增大，帖子中心这种“1对多”业务，架构应该如何设计，有哪些因素需要考虑，是本文将要系统性讨论的问题。 什么是x对x？ 所谓的“1对1”，“1对多”，“多对多”，来自数据库设计中的“实体-关系”ER模型，用来描述实体之...

    糖太宗 糖太宗
    2022年5月14日
    2100
  • 如何进行安全设计评审 技术

    如何进行安全设计评审

    如何进行安全设计评审 记录一次安全设计评审的过程，当然这也是我第一次进行安全评审。因此做一个总结。安全设计评审应该是SDL落地安全人员参与过程中首当其冲的地方。仅指安全人员自身的功用。如果按照SDL流程来讲，最前期应该是进行安全培训。我们可以看两个微软SDL官方给出的流程图。   那么在安全设计评审这一阶段，应该怎么去做。我们可以先看下唯品会的SD...

    常山赵子龙 常山赵子龙
    2022年5月28日
    1000

  • 旁路监控

    常见的网络监控模式可以分为两种：一种是旁路监控模式，另一种是串联监控模式。 “旁路监控模式”一般是指通过交换机等网络设备的“端口镜像”功能来实现监控，在此模式下，监控设备只需要连接到交换机的指定镜像端口，所以形象的称之为“旁路监控”。 而串联模式一般是通过网关、网桥或者代理服务器的模式来进行监控，由于监控设备做为网关或者网桥串联在网络中，所以称之为“串联监控...

    常山赵子龙 常山赵子龙
    技术 2022年5月28日
    14800

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

联系我们

400-800-8888

在线咨询： QQ交谈

邮件：admin@example.com

工作时间：周一至周五，9:30-18:30，节假日休息

关注微信