微服务之松耦合

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