简单易用的几个业务服务解耦方案

小七学习网,助您升职加薪,遇问题可联系:客服微信【1601371900】 备注:来自网站

对于大多数业务开发同学来说,业务逻辑的解耦设计至关重要,那有哪些行之有效的方法么? 本文结合作者在实际业务项目建设经验,为大家总结一套比较普适性的解耦设计方案。 主要内容包括: 服务接口解耦 服务逻辑…

对于大多数业务开发同学来说,业务逻辑的解耦设计至关重要,那有哪些行之有效的方法么?

本文结合作者在实际业务项目建设经验,为大家总结一套比较普适性的解耦设计方案。

主要内容包括:

  1. 服务接口解耦
  2. 服务逻辑解耦
  3. 服务模块解耦

适合人群:从事业务系统建设的产品、研发人员。



认识解耦

关于解耦,初次听起来概念可能有些许陌生,但是生活中的解耦随处可见。

生活中的解耦

例如,我网购了一件商品,快递员需要将商品派送到我手上,那他的商品派送就需要依赖我的时间和所在的位置。那快递员将商品派送到离我最近的便利店,等我时间方便了以后随时去取件,这样便利店就将快递员和我之间的派件过程进行了解耦。快递的派发和收取目的都达到了,而且自由度还比较高。

在这里插入图片描述

在软件工程中,解耦即可以理解为降低耦合度,模块间有依赖关系必然存在耦合,理论上的绝对零耦合是做不到的,但可以通过一些现有的方法将耦合度降至最低,达到简化关系的目的。

业务服务解耦常见方案

设计的核心思想:尽可能减少代码耦合,如果发现代码耦合,就要采取解耦技术

对于常见的多耦合、依赖的服务而言,需要解耦成流程清晰、可控的垂直架构,便于后期维护和迭代。

在这里插入图片描述

从不同范围来看,常见方案主要包括:

  • 服务接口解耦
  • 业务逻辑解耦
  • 业务模块解耦

那接下来,让我们逐个来进行学习和了解吧~

业务服务解耦

对于业务服务解耦,针对服务接口解耦,我们可以采用单一职责原则。

A class or module should have a single reponsibility。

——Robert C. Martin 《敏捷软件开发:原则、模式与实践》

单一职责原则适用范围包括:接口、方法和类。

原方案

我们原来的一个接口类 T 拥有职责 P1、P2、P3 这个方面,某个职责逻辑调整都会对类 T 进行调整,而且影响范围存在不确定性,会存在代码改动的风险。

在这里插入图片描述

改进方案

改进之后,我们可以为职责 P1、P2、P3 每个职责分类一个接口类,这样职责范围划分明确,且降低互相影响的风险。

在这里插入图片描述

单一职责原则应用总结

其主要优势体现在以下方面:

  • 降低接口的复杂度
  • 提升编码的可读性
  • 提高系统的可维护性
  • 降低变更引起的风险

虽单一职责原则包括诸多优点,但仍需额外注意事项:

单一职责原则,最重要的就是理解职责的划分。

  • 职责划分,有时会因项目、环境不同而不同;
  • 接口设计的时候需要尽量做到单一职责,但切忌生搬硬套;
  • 需要我们有足够的开发经验和能力去具体分析。

业务逻辑解耦

你是不是还在写着大量的 if else 语句,if else 不仅难维护不易扩展,而且使代码臃肿不堪?

来看个例子吧~

    // 多业务类型处理逻辑情况    if (a < 1) {        //doSomething …    } else if (a < 2) {        //doSomething …    } else if (a < 3) {        //doSomething …    }

当代码足够繁杂时候,我们一个小小失误都会造成大问题,而且很难去排查。

如下例所示,(a < 3)前的 if 前缺少一个 else,语法上没有问题,但是处理逻辑变化很大。

    // 多业务类型处理逻辑    if (a < 1) {        //doSomething …    } else if (a < 2) {        //doSomething …    }   if (a < 3) {        //doSomething …    }

Q:对于上述的问题,你有什么好的解决办法么?

A:推荐你使用策略模式,让代码更加优雅,健壮,更易扩展。

实际案例分析

问题描述:如果要实现不同运算逻辑的计算能力,该如何实现呢?

在这里插入图片描述

策略模式原理图:

在这里插入图片描述

策略 A、B、C 分别实现不同的运算逻辑,便于后期扩展和维护工作。

策略模式设计原则:

  • 把变化的代码从不变的代码中分离出来
  • 针对接口编程而不是具体类(定义了策略接口)
  • 多用组合/聚合,少用继承(客户通过组合方式使用策略)

策略模式优劣总结

优势:

  • 完美支持 “开闭原则” ,灵活地增加新的算法或行为;
  • 避免多重条件选择语句,易维护;
  • 策略模式提供了一种算法的复用机制(避免重复代码)。

缺点:

  • 具体策略类较多,任何细小的变化都将导致系统要增加一个新的具体策略类;
  • 无法同时在使用多个策略类(每次只能使用一个策略类)。

业务模块解耦

业务模块解耦更多时候是一种设计理念,具体实现的方法其实有很多。

常见处理方案,主要包括以下几点:

  • 接口异步响应,常用于在第三方对接服务、流程
  • 消息生产和消费模式,解耦复杂流程
  • 发布订阅的广播模式,常见于系统通知
接口异步响应

接口请求的时候如果是同步,那么有时业务逻辑处理时间很长,请求就会超时!所以需要在接口请求过来时,就先响应,再去执行业务逻辑。

同步调用方式

A 请求会等待 B 处理完成后,结果返回:

在这里插入图片描述

异步调用方式

A 无需等待 B 处理完成,B 直接返回结果后再做处理流程,而 A 无需关心此过程。

在这里插入图片描述

消息生产和消费模式

目的就是为了解决非同步的生产与消费之间的问题。

在这里插入图片描述

通过存储中介解耦了生产者与消费者的直接交互,这样生产、消费能力的不一致可以通过增减两端的数量进行调整。

发布订阅的广播模式

生产者将消息发布到 Topic 中,同时可以有多个消费者订阅该消息。

广播模式与点对点方式不同,发布到 Topic 的消息会被所有订阅者消费。

在这里插入图片描述

对解耦的总结

其实,解耦的本质就是异步化。

同步处理

即所有事情排队一件件的有序进行,等上件事情完成后才会去做下一件事情。

异步处理

不用阻塞当前线程来等待处理完成,而是允许后续操作,直至其它线程将处理完成,并回调通知此线程。

异步处理适用的业务场景,对数据强一致性的要求不高,异步处理的数据更多时候追求的是最终一致性。

小七学习网,助您升职加薪,遇问题可联系:客服微信【1601371900】 备注:来自网站

免责声明: 1、本站信息来自网络,版权争议与本站无关 2、本站所有主题由该帖子作者发表,该帖子作者与本站享有帖子相关版权 3、其他单位或个人使用、转载或引用本文时必须同时征得该帖子作者和本站的同意 4、本帖部分内容转载自其它媒体,但并不代表本站赞同其观点和对其真实性负责 5、用户所发布的一切软件的解密分析文章仅限用于学习和研究目的;不得将上述内容用于商业或者非法用途,否则,一切后果请用户自负。 6、您必须在下载后的24个小时之内,从您的电脑中彻底删除上述内容。 7、请支持正版软件、得到更好的正版服务。 8、如有侵权请立即告知本站(邮箱:1099252741@qq.com,备用微信:1099252741),本站将及时予与删除 9、本站所发布的一切破解补丁、注册机和注册信息及软件的解密分析文章和视频仅限用于学习和研究目的;不得将上述内容用于商业或者非法用途,否则,一切后果请用户自负。本站信息来自网络,版权争议与本站无关。您必须在下载后的24个小时之内,从您的电脑中彻底删除上述内容。如果您喜欢该程序,请支持正版软件,购买注册,得到更好的正版服务。如有侵权请邮件与我们联系处理。