微服务业务模块间的调用如何解耦?

跨模块解耦设计

大家好,我是小玺,今天给大家分享一下前几年我在分布式项目中业务模块间的调用如何解耦。

1、设计背景

目前市场需求参差不齐且不景气,大公司也都在"裁员广进",预算基本都缩减,客户在预算比较紧张的情况下,对于软件的需求也只能挑着重点去购买,有时客户仅需要产品的某些业务模块+自有的系统灵活搭配。例如物流行业经典OTWB,预算问题导致只购买W或者T业务,因此需要对完整的OTWB进行解耦,单独部署且使用。 (PS:懂得都懂,不可能去用一堆的if-else屎山代码每个操作都去判断,成本高且不易维护,代码健壮性不得劲)

2、设计说明

将涉及跨模块调用的项目代码进行抽离,达到各个业务模块解耦

3、UML设计

说明
对象 说明
用户 系统操作用户
后端接口 用户界面操作后,实际调用后台的接口
跨模块调用接口 仅提供当前业务模块涉及跨模块调用接口供后端接口调用(不包含具体的跨模块逻辑实现)
模块调用默认实现类 对【跨模块调用接口】进行跨模块的逻辑实现(产品默认实现逻辑)
模块调用第三方实现类 对【跨模块调用接口】进行跨模块的逻辑实现(根据项目情况定制化开发)
步骤
复制代码
1、用户前端发起请求
2、调用跨模块抽离的接口方法
3、根据模块实现配置调用项目中公司内部提供的【模块调用默认实现类】,或者客户方提供的【模块调用第三方实现类】
4、跨模块实现成功返回请求结果
5、模块调用接口反馈结果到业务模块
6、业务模块继续走请求的其它代码逻辑
7、业务接口请求返回请求成功

4、设计思路

对代码中跨模块调用的地方,将跨模块调用的功能抽离成一个接口,并对该接口的实现区分为系统默认实现模块和第三方实现模块,原项目中相关跨模块调用逻辑实现代码抽离到系统默认实现模块,项目上通过跨模块调用配置选择模块调用走系统默认实现还是第三方实现。

若选择第三方实现模块,则不再引用系统默认实现模块(包含了其它各个业务模块的代码依赖),从而实现业务模块间的解耦,单一业务模块也能正常使用。

以上就是关于微服务的解耦设计。欢迎大家各抒己见,有什么好的思路和建议一起交流。

相关推荐
岁岁种桃花儿2 小时前
SpringCloud从入门到上天:分布式和微服务基础
分布式·spring cloud·微服务
爱吃山竹的大肚肚16 小时前
微服务间通过Feign传输文件,处理MultipartFile类型
java·spring boot·后端·spring cloud·微服务
鸽鸽程序猿1 天前
【JavaEE】【SpringCloud】分布式事务 Alibaba Seata
分布式·spring cloud·java-ee
没有bug.的程序员1 天前
Spring Cloud Sentinel:熔断降级规则配置与分布式流量防线实战终极指南
java·分布式·后端·spring cloud·sentinel·熔断规则·分布式流量防线
梵得儿SHI1 天前
实战项目落地:微服务拆分原则(DDD 思想落地,用户 / 订单 / 商品 / 支付服务拆分实战)
spring cloud·微服务·云原生·架构·微服务拆分·ddd方法论·分布式数据一致性
努力也学不会java1 天前
【Spring Cloud】优雅实现远程调用-OpenFeign
java·人工智能·后端·spring·spring cloud
m0_740043733 天前
【无标题】
java·spring boot·spring·spring cloud·微服务
编程彩机3 天前
互联网大厂Java面试:从微服务到分布式缓存的技术场景解析
redis·spring cloud·消息队列·微服务架构·openfeign·java面试·分布式缓存
Anastasiozzzz3 天前
Nginx和Ribbon的区别
后端·spring cloud·ribbon
码农水水3 天前
从 OpenFeign 到 RestClient:Spring Cloud 新时代的轻量化 HTTP 调用方案
java·运维·后端·spring·http·spring cloud·面试