微服务之松耦合

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

相关推荐
真实的菜1 小时前
Kafka生态整合深度解析:构建现代化数据架构的核心枢纽
架构·kafka·linq
guojl1 小时前
营销客群规则引擎
架构
Natsume17102 小时前
嵌入式开发:GPIO、UART、SPI、I2C 驱动开发详解与实战案例
c语言·驱动开发·stm32·嵌入式硬件·mcu·架构·github
DemonAvenger2 小时前
深入理解Go的网络I/O模型:优势、实践与踩坑经验
网络协议·架构·go
伤不起bb3 小时前
Kubernetes 服务发布基础
云原生·容器·kubernetes
鹏程十八少5 小时前
7.Android 设计模式 享元模式 在商业项目中的落地
架构
老周聊大模型5 小时前
《ChatGLM/Llama调优实战:从指令微调到RLHF的工业级对齐方案》
人工智能·程序员·架构
weixin_437398216 小时前
转Go学习笔记
linux·服务器·开发语言·后端·架构·golang
别骂我h6 小时前
Kubernetes服务发布基础
云原生·容器·kubernetes
要开心吖ZSH6 小时前
微服务架构的演进:迈向云原生
java·微服务·云原生