简体繁体 English

不同的微服务永远不应该耦合？

[英]Different microservices should NEVER be coupled?

原文 2022-09-18 16:36:24 3 1 architecture/ microservices/ software-design/ decoupling

I'm doing the design of a shopping application, I've decided to use the micro services approach but in the way I'm designing the services I'm struggling with some decisions.我正在设计一个购物应用程序，我决定使用微服务方法，但是在我设计服务的方式上，我正在为一些决定而苦苦挣扎。

For example, I have a "shop-service" which will be the entry point for the user to start shopping and when calling this service we obviously need different information, being the products catalogue and inventory information the most important ones.例如，我有一个“shop-service”，它将作为用户开始购物的入口点，当调用此服务时，我们显然需要不同的信息，产品目录和库存信息是最重要的。 These 2 other services are separate with each other and have their own databases.这两个其他服务是相互独立的，并且有自己的数据库。

The problem here is that "shop-service" makes no sense without these other 2, and for me it makes sense to communicate them through asynchronous calls for shop to wait both the catalogue information and the inventory information with the stock of each product and its location instead of using events, since it shouldn't be reactive if there's no movement in the catalogue or inventory services.这里的问题是，如果没有其他 2 个，“商店服务”就没有意义，对我来说，通过异步调用商店来等待目录信息和库存信息以及每种产品的库存及其库存信息是有意义的。位置而不是使用事件，因为如果目录或库存服务中没有移动，它不应该是反应性的。 (Note that I'm planning on putting events when something is changed to update the shop service with the newest information, but for this question's purpose think we assume there are no changes) （请注意，我计划在更改某些内容时放置事件以使用最新信息更新商店服务，但出于此问题的目的，认为我们假设没有更改）

However, I feel like they are becoming too coupled even though it makes no sense to have a working shop without any of the other services working fine.但是，我觉得它们变得过于耦合，即使在没有任何其他服务正常工作的情况下拥有一个工作车间是没有意义的。

Would you happen to have any suggestion from an architectural point of view?你会从建筑的角度有什么建议吗？ Is it really bad to have 2 or 3 coupled micro services if they are very dependant with each other?如果它们之间非常依赖，那么拥有 2 或 3 个耦合的微服务真的很糟糕吗？

1 个解决方案

Is it really bad to have 2 or 3 coupled micro services if they are very dependant with each other?如果它们之间非常依赖，那么拥有 2 或 3 个耦合的微服务真的很糟糕吗？

Yes, and your system it trying to tell you something.是的，你的系统试图告诉你一些事情。

It's not obvious at the beginning of design what the boundaries of your microservices should be.在设计之初，微服务的边界应该是什么并不明显。

When you separate two service endpoints into separate microservices you often need to implement asynchronous communication or data replication between them.当您将两个服务端点分离为单独的微服务时，您通常需要在它们之间实现异步通信或数据复制。

At some point the complexity and performance cost of that outweighs the benefit of having a separately deployed microservice.在某些时候，其复杂性和性能成本超过了单独部署微服务的好处。

This is how you group operations into microservices.这就是您将操作分组到微服务中的方式。 Strong coupling within a microservice, and loose coupling between microservices.微服务内强耦合，微服务间松耦合。

An over-atomized, over-distributed microservice application is infinitely worse than a monolith.过度原子化、过度分布的微服务应用程序比单体应用程序更糟糕。