微服务之松耦合

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

相关推荐
MrWho不迷糊2 小时前
企业级权限系统怎么设计四 —— ABAC模型统一功能权限与数据权限
后端·微服务
阿里云云原生2 小时前
对比测评:为什么AI编程工具需要 Rules 能力?
云原生
小马爱打代码2 小时前
Kafka生产者架构深度剖析
架构·kafka
李剑一3 小时前
别再用HTTP/1这个老古董了,两招帮你升级HTTP/2
前端·架构
郝同学的测开笔记4 小时前
云原生探索系列(十七):Go 语言sync.Cond
后端·云原生·go
lczdyx4 小时前
从Flask到智能体:装饰器模式在AI系统中的架构迁移实践
人工智能·python·语言模型·架构·flask·装饰器模式
kill bert5 小时前
第33周JavaSpringCloud微服务 分布式综合应用
微服务·云原生·架构
ErizJ5 小时前
Golang|分布式索引架构
开发语言·分布式·后端·架构·golang
阿里云云原生5 小时前
通义灵码 CCF 算法大会首秀,解码研发智能落地「黄金三角」| 文末领取PPT
云原生
weisian1515 小时前
云原生--核心组件-容器篇-7-Docker私有镜像仓库--Harbor
docker·云原生·容器