微服务之松耦合

参考: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应该相对稳定。遵守单一指责原则,共同闭包原则。

相关推荐
小马爱打代码4 小时前
微服务外联Feign调用:第三方API调用的负载均衡与容灾实战
微服务·架构·负载均衡
9527华安8 小时前
FPGA实现40G网卡NIC,基于PCIE4C+40G/50G Ethernet subsystem架构,提供工程源码和技术支持
fpga开发·架构·网卡·ethernet·nic·40g·pcie4c
虚伪的空想家8 小时前
rook-ceph配置dashboard代理无法访问
ceph·云原生·k8s·存储·rook
guojl13 小时前
深度解决大文件上传难题
架构
DemonAvenger13 小时前
Go语言中的TCP编程:基础实现与最佳实践
网络协议·架构·go
Connie145114 小时前
k8s多集群管理中的联邦和舰队如何理解?
云原生·容器·kubernetes
一眼万年0414 小时前
Redis Cluster模式
redis·微服务
guojl14 小时前
一网打尽分布式锁
架构
xinxiangwangzhi_14 小时前
pytorch底层原理学习--PyTorch 架构梳理
人工智能·pytorch·架构
真实的菜16 小时前
Kafka生态整合深度解析:构建现代化数据架构的核心枢纽
架构·kafka·linq