微服务之松耦合

参考:https://microservices.io/post/architecture/2023/03/28/microservice-architecture-essentials-loose-coupling.html

There's actually two different types of coupling:

runtime coupling - influences availability

design-time coupling - influences development velocity

Runtime coupling and availability

Runtime coupling between services is the degree to which the availability of one service is affected by the availability of another service. Or to be more precise, it's degree to which the availability of an operation implemented by one service is affected by the availability of another service

微服务化以后导致一个请求会同步调用多个服务,请求的时常和可用性都会降低。

Reducing runtime coupling

使用异步的方式可以提高请求的可用性,但是客户端变得更复杂了,必须轮询服务器获得请求的状态。

这里建议的依然是orderService调用Consumer Service,只是放到异步线程了而已。其实到底是OrderService调用ConsumerService的RPC api, 还是Consumer Service监听OrderService的事件,要看业务逻辑而定,如果ConsumerService是OrderService的强依赖(说明OrderService domain必须要理解ConsumerService domain的概念和API),那么RPC的方式是合理的,反之,异步消息的方式更合理。

DDD总是推荐异步消息,因为一个transaction只更新一个aggregate。

Design-time coupling and development velocity

The degree of design-time coupling between a pair of software elements - classes...services - is the likelihood that they need to change together for the same reason. Design-time coupling between services in a microservice architecture is especially problematic. Let's look at why it's a problem and how we can minimize it.

这其实就是《整洁架构》里面所说的单一指责原则,或者说共同闭包原则,如果两个模块总是因为同一个原因改变,那么他们就应该属于一个模块,或者说,在微服务架构下,一个服务内部。

If two services are loosely coupled, then a change to one service rarely requires a change to the other service. However, if two services are tightly coupled, then a change to one service often requires a change to the other service. These types of lock step changes are expensive since it typically involves breaking API changes.

For example, let's imagine that the Order Service and Customer Service are tightly coupled. Each time a breaking changes needs to be made to the Customer Service the sequence of steps is as follows:

Change the Customer Service to add a new major version of its API. The service must implement both the old and new version of its APIs until all clients have been migrated over.

  • Migrate the Order Service to the new API version
  • Remove the old API version from the Customer Service
  • What's even worse, is that quite often the services are owned by different teams, which requires those teams to coordinate the changes. In other words, design-time coupling between services undermines team autonomy.

Reducing design-time coupling

Minimizing design-time coupling is one of the dark matter attractive forces that resists decomposition. There are a couple of different ways to minimize design-time coupling between services.

design subdomains to be loosely coupled - loosely coupled subdomains can be packaged as different services. Loose design-time coupling is usually achieved by each subdomain having a stable API that encapsulates its implementation.

package subdomains that are tightly coupled in the same service - If two subdomains are tightly coupled, then packaging them together in the same service will avoid design-time coupling between services.

解决方法也很简单,就是遵循DDD的设计,子模块(微服务)之间应该有合理的边界,每个子模块有相对独立的业务逻辑,子模块的API应该相对稳定。遵守单一指责原则,共同闭包原则。

相关推荐
是小崔啊2 小时前
叩丁狼K8s - 概念篇
云原生·容器·kubernetes
SmartBrain2 小时前
DeerFlow 实践:华为IPD流程的评审智能体设计
人工智能·语言模型·架构
一水鉴天7 小时前
整体设计 之 绪 思维导图引擎 之 引 认知系统 之 序 认知元架构 从 三种机器 和 PropertyType 到认知 金字塔 之2(豆包助手)
架构·认知科学
AKAMAI8 小时前
Sport Network 凭借 Akamai 实现卓越成就
人工智能·云原生·云计算
ajax_beijing9 小时前
zookeeper是啥
分布式·zookeeper·云原生
程思扬10 小时前
利用JSONCrack与cpolar提升数据可视化及跨团队协作效率
网络·人工智能·经验分享·docker·信息可视化·容器·架构
从零开始学习人工智能11 小时前
快速搭建B/S架构HTML演示页:从工具选择到实战落地
前端·架构·html
小小工匠11 小时前
架构思维: 高并发场景下的系统限流实战
架构·限流算法·限流实战
user48402325423912 小时前
使用自定义snapshotter修改容器的rootfs路径
云原生
骆驼102414 小时前
40分钟的Docker实战攻略
云原生·eureka