谈微服务间接口强耦合问题解决(200706)
source link: http://blog.sina.com.cn/s/blog_493a84550102z8mb.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
因此今天我们来谈下面对这种情况我们可以从哪些思路下手去解决。
两个微服务本身紧耦合则进行合并
如果两个微服务间出现大量接口相互调用，即可以认为紧耦合。或者我原来的判断标准，即两个微服务对应的后台数据表，其中30%以上都需要两个微服务交叉访问，那么就认为两个微服务本身耦合性极强。
在这种情况下处理措施就是原来微服务划分的太细了，需要对两个微服务进行合并。
交叉依赖转变为共性依赖
要知道在传统软件开发里面往往是不允许两个组件交叉依赖的。但是在新的IOC和微服务开发里面，大量都是反射调用，两个组件相互依赖不会有问题。但是这本身也不是一种很好的设计方法。
如果两个微服务或多个微服务相互依赖内容本身具备共性。那么最好的做法就是将共性内容全部移出，下沉为一个共性基础微服务模块再朝上提供服务。
即将两个微服务依赖内容下沉，将交叉依赖转变为对底层的共性依赖。
对某个微服务实现单元进行迁移
为什么出现这种场景？
简单来说就是原来的微服务模块划分和业务功能划分不合理。比如上图中的微服务A中的A1部分。这个部分内容需要大量被微服务B调用，但是A1实际依赖微服务A中其它部分的内容却很少。
这种就是典型的A1部分功能划分位置不合理。最好的做法就是将A1功能从微服务A迁移到微服务B，实现对原有业务划分不合理的纠正。
将细粒度服务转变为真正的粗粒度服务
服务本身应该具备粗粒度属性，暴露仅仅需要暴露的内容。比如微服务A实现客户信用检查和评级。微服务B需要客户信用。有两种做法
第一种是B调用A多个接口，把客户基本信息，客户交易信息，客户违约信息全部查询过来，然后自己计算客户信用。这就是我们说的典型细粒度服务接口。
第二种即是只需要输入客户编码，微服务A返回最早的信用评级。
对于后者就是我们常说的粗粒度接口或领域服务，服务间的交互应该以领域服务和粗粒度服务为主，避免掉完全的数据库表的CRUD类服务接口。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK