微服务架构下如何解耦，对于已经紧耦合下如何重构？( 五 ) _微服务架构

在微服务架构里面，我们一直在强调一点，即数据实时需要实时访问，不进行底层数据库的数据集成和同步，这既满足了数据的高一致性，也满足了数据实时性的要求。
但是带来的问题就是强耦合，如果数据提供方出现异常，那么导致消费方业务功能也无法使用。
因为我们可以适量考虑数据落地方式的数据集成在整体微服务架构实施过程中，对于变化不频繁的数据适度落地到微服务模块本地。这样本身可以减少实时的业务接口服务调用，增加单个微服务模块的可用性和可靠性。
对于已经出现强耦合如何重构

文章插图

如果微服务已经实施完成并出现了大量紧耦合的情况，那么我们就需要在后期考虑对微服务架构进行重构，具体重构的方法可以从如下几点考虑。
两个微服务本身紧耦合

文章插图

如果两个微服务间出现大量接口相互调用，即可以认为紧耦合。
或者我原来的判断标准，即两个微服务对应的后台数据表，其中30%以上都需要两个微服务交叉访问，那么就认为两个微服务本身耦合性极强。
在这种情况下处理措施就是原来微服务划分的太细了，需要对两个微服务进行合并。
交叉依赖变为共性依赖

文章插图

要知道在传统软件开发里面往往是不允许两个组件交叉依赖的。
但是在新的IOC和微服务开发里面，大量都是反射调用，两个组件相互依赖不会有问题。但是这本身也不是一种很好的设计方法。
如果两个微服务或多个微服务相互依赖内容本身具备共性。那么最好的做法就是将共性内容全部移出，下沉为一个共性基础微服务模块再朝上提供服务。
即交叉依赖转变为对底层的共性依赖。
对某个微服务实现单元进行迁移

文章插图

为什么出现这种场景？
简单来说就是原来的微服务模块划分和业务功能划分不合理。比如上图中的微服务A中的A1部分。这个部分内容需要大量被微服务B调用，但是A1实际依赖微服务A中其它部分的内容却很少。
这种就是典型的A1部分功能划分位置不合理。
最好的做法就是将A1功能从微服务A迁移到微服务B，实现对原有业务划分不合理的纠正。
将细粒度服务转变为粗粒度服务

文章插图

服务本身应该具备粗粒度属性，暴露仅仅需要暴露的内容。
比如微服务A实现客户信用检查和评级。微服务B需要客户信用。有两种做法
第一种是B调用A多个接口，把客户基本信息，客户交易信息，客户违约信息全部查询过来，然后自己计算客户信用。
第二种即是只需要输入客户编码，微服务A返回最早的信用评级。
对于后者就是我们常说的粗粒度接口或领域服务，服务间的交互应该以领域服务和粗粒度服务为主，避免掉完全的数据库表的CRUD类服务接口。