谈微服务间接口强耦合问题解决(200706)

栏目: IT技术 · 发布时间: 4年前

因此今天我们来谈下面对这种情况我们可以从哪些思路下手去解决。

两个微服务本身紧耦合则进行合并

谈微服务间接口强耦合问题解决(200706)

如果两个微服务间出现大量接口相互调用,即可以认为紧耦合。或者我原来的判断标准,即两个微服务对应的后台数据表,其中30%以上都需要两个微服务交叉访问,那么就认为两个微服务本身耦合性极强。

在这种情况下处理措施就是原来微服务划分的太细了,需要对两个微服务进行合并。

交叉依赖转变为共性依赖

谈微服务间接口强耦合问题解决(200706)

要知道在传统软件开发里面往往是不允许两个组件交叉依赖的。但是在新的IOC和微服务开发里面,大量都是反射调用,两个组件相互依赖不会有问题。但是这本身也不是一种很好的设计方法。

如果两个微服务或多个微服务相互依赖内容本身具备共性。那么最好的做法就是将共性内容全部移出,下沉为一个共性基础微服务模块再朝上提供服务。

即将两个微服务依赖内容下沉,将交叉依赖转变为对底层的共性依赖。

对某个微服务实现单元进行迁移

谈微服务间接口强耦合问题解决(200706)

为什么出现这种场景?

简单来说就是原来的微服务模块划分和业务功能划分不合理。比如上图中的微服务A中的A1部分。这个部分内容需要大量被微服务B调用,但是A1实际依赖微服务A中其它部分的内容却很少。

这种就是典型的A1部分功能划分位置不合理。最好的做法就是将A1功能从微服务A迁移到微服务B,实现对原有业务划分不合理的纠正。

将细粒度服务转变为真正的粗粒度服务

谈微服务间接口强耦合问题解决(200706)

服务本身应该具备粗粒度属性,暴露仅仅需要暴露的内容。比如微服务A实现客户信用检查和评级。微服务B需要客户信用。有两种做法

第一种是B调用A多个接口,把客户基本信息,客户交易信息,客户违约信息全部查询过来,然后自己计算客户信用。这就是我们说的典型细粒度服务接口。

第二种即是只需要输入客户编码,微服务A返回最早的信用评级。

对于后者就是我们常说的粗粒度接口或领域服务,服务间的交互应该以领域服务和粗粒度服务为主,避免掉完全的数据库表的CRUD类服务接口。


以上所述就是小编给大家介绍的《谈微服务间接口强耦合问题解决(200706)》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

深入理解C#(第3版)

深入理解C#(第3版)

斯基特 (Jon Skeet) / 姚琪琳 / 人民邮电出版社 / 2014-4-1 / 99.00元

本书是世界顶级技术专家“十年磨一剑”的经典之作,在C#和.NET领域享有盛誉。与其他泛泛介绍C#的书籍不同,本书深度探究C#的特性,并结合技术发展,引领读者深入C#的时空。作者从语言设计的动机出发,介绍支持这些特性的核心概念。作者将新的语言特性放在C#语言发展的背景之上,用极富实际意义的示例,向读者展示编写代码和设计解决方案的最佳方式。同时作者将多年的C#开发经验与读者分享,读者可咀其精华、免走弯......一起来看看 《深入理解C#(第3版)》 这本书的介绍吧!

在线进制转换器
在线进制转换器

各进制数互转换器

UNIX 时间戳转换
UNIX 时间戳转换

UNIX 时间戳转换

HSV CMYK 转换工具
HSV CMYK 转换工具

HSV CMYK互换工具