专栏首页架构师之路换IP的是你,凭啥重启的却是我?

换IP的是你,凭啥重启的却是我?

一、缘起

很多公司,技术经常遇到这样的场景:

1)硬件升级,要换一台高配机器

2)网络重新规划,若干服务器要调整机架

3)服务器当机,要重新部署恢复服务

更具体的,如上图:数据库换了一个ip,此时往往连接此数据库的上游需要修改配置重启,如果数据库有很多上游调用方,改配置重启的调用方会很多,每次换ip的成本往往很高,成为大家共性的痛点。

由A的调整(数据库换ip),配合修改和调整的却是BCDE(改配置重启),BCDE内心非常的郁闷:明明换ip的是你,凭什么配合重启的却是我?

根本上,这是一个“架构耦合”的问题,是一个架构设计上“反向依赖”的问题,本文将讨论的是架构设计中常见的“反向依赖”的设计,以及对应的优化方案,希望对大伙有所启示。

二、如何寻找不合理“反向依赖”

方法论

变动方是A,配合方却是BCDE

(或者说需求方是A,改动方确是BCDE)

想想“换IP的是你,配合重启的却是我”更好理解。

如果系统中经常出现了这类情况,就是“反向依赖”的特征,往往架构上有优化的空间。

三、常见的“反向依赖”与优化方案

【case1:公共库导致耦合】

三个服务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进行解耦。服务化之后,兼容性能更好的通过接口自动化回归测试来保证。

基础服务的抽象,本身是一种共性聚焦,是系统解耦常见的方案。

【case2:服务化不彻底导致耦合】

服务化是解决“业务共性”组件库导致系统耦合的常见方案之一,但如果服务化不彻底,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有个性的业务需求,升级的是自己的业务系统。

【case3:notify的不合理实现导致的耦合】

究竟什么时候该使用MQ》一文中有一类业务场景,消息发送方不关注消息接收方的执行结果,如果采用调用的方式来实现通知,会导消息发送方和消息接收方耦合。

如何新增消息接收方biz-4,会发现修改代码的是消息发送方,新增一个对biz-4的调用,极不合理。

优化方案:通过MQ实现解耦

消息发送方upper将消息发布给MQ,消息接收方从MQ去订阅,任何新增对消息的消费,upper都不需要修改代码。

【case4:配置中的ip导致上下游耦合】

即“缘起”中举的例子,下游服务换ip,可能导致多个服务调用方修改配置重启。上下游间接的通过ip这个配置耦合在了一起,架构不合理。

优化方案:通过内网域名而不是ip来进行下游连接

如果在配置中使用内网域名来进行下游连接,当下游服务或者数据库更换ip时,只需要运维层面将内网域名指向新的ip,然后统一切断原有旧的连接,连接就能够自动切换到新的ip上来。这个过程不需要所有上游配合,非常帅气,强烈推荐!

【case5:下游扩容导致上下游耦合】

这次不是换换ip这么简单了,下游服务提供方原来是集群(ip1/ip2/ip3,当然,上游配置的是内网域名),现在集群要扩容为(ip1/ip2/ip3/ip4/ip5),如果没有特殊的架构设计,上游往往需要修改配置,新增扩容后的节点,再重启,导致上下游耦合。

这类case,大伙有什么好的方案解耦么?

技术细节,且听下回分解。

四、总结

如何发现系统架构中不合理的“反向依赖”设计?

回答:

(1)变动方是A,配合方却是BCDE

(2)需求方是A,改动方确是BCDE

想想“换IP的是你,配合重启的却是我”,此时往往架构上可以进行解耦优化。

常见反向依赖及优化方案?

(1)公共库导致耦合

优化一:如果公共库是业务特性代码,进行公共库垂直拆分

优化二:如果公共库是业务共性代码,进行服务化下沉抽象

(2)服务化不彻底导致耦合

特征:服务中包含大量“根据不同业务,执行不同个性分支”的代码

优化方案:个性代码放到业务层实现,将服务化更彻底更纯粹

(3)notify的不合理实现导致的耦合

特征:调用方不关注执行结果,以调用的方式去实现通知,新增订阅者,修改代码的是发布者

优化方案通过MQ解耦

(4)配置中的ip导致上下游耦合

特征:多个上游需要修改配置重启

优化方案使用内网域名替代内网ip,通过“修改DNS指向,统一切断旧连接”的方式来上游无感切换

(5)下游扩容导致上下游耦合

特性:多个上游需要修改配置重启

换IP的是你,凭啥配合重启的却是我。

本文分享自微信公众号 - 架构师之路(road5858),作者:58沈剑

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2017-04-19

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 一分钟读懂互联网广告竞价策略(一分钟系列)

    一分钟读懂互联网广告竞价策略GFP+GSP+VCG 两个广告位,三家广告主竞价,广告平台究竟应该制定广告竞价策略呢?这是本文即将分享的一个问题。 一、前序知识-...

    架构师之路
  • 58龙哥教你“如何做系统性能优化”(纯干货)

    如何做系统性能优化 性能优化的目标是什么?不外乎两个: 时间性能:减小系统执行的时间 空间性能:减小系统占用的空间 一、代码优化 做代码优化前,先了解下硬件Ca...

    架构师之路
  • 小小的IP,大大的耦合,你痛过吗?

    什么是耦合? 耦合,是架构中,本来不相干的代码、模块、服务、系统因为某些原因联系在一起,各自独立性差,影响则相互影响,变动则相互变动的一种架构状态。 感官上,...

    架构师之路
  • Windows下的tail一二三:tail、BareTail、WinTail WindowsvimPHPUnixDOS

    Windows下的tail一二三:tail、BareTail、WinTail

    阿敏总司令
  • 计算机基础知识_进制转化

              进制转化 一.任何一个进制转化为10进制的方式 156的十进制可以看做1*10^2 + 5*10^1  +   6*10^0 首先我们看一下...

    IBinary
  • Jmeter(三十一)_dummy sampler模拟数据驱动

    之前写过一篇数据驱动的文章 数据驱动测试 ,但是内容过于简单,有些关键的地方没有写明白。这两天参照了一下官方文档,重新整理了一篇数据驱动测试!

    飞天小子
  • SQL92&SQL99实现三表联合查询

    –给city表添加测试数据 insert into city values(1,‘商丘’,‘历史闻名古都’); insert into city val...

    葆宁
  • iis中ASP运行环境配置图解 IIS的安装和基本设置

    现在服务器上的asp运行环境基本上都是用win2003或win2008,当然也有winxp但iis版本是5.1的,大家可以根据需要选择如果为了方便与简单的测试可...

    习惯说一说
  • PPC上的Python IDE

            在[url]http://pythonce.sourceforge.net/Wikka/VensterCE[/url]看到Pythonce里的另...

    py3study
  • 【大牛经验】探讨Java的异常与错误处理

    探讨Java的异常与错误处理 ENTER TITLE ? Java中的异常处理机制已经比较成熟,我们的Java程序到处充满了异常的可能,如果对这些异常不做预先的...

    Java帮帮

扫码关注云+社区

领取腾讯云代金券