微服务 - 每个 CRUD 都是一项服务吗

Question

对微服务非常陌生......

如果我有一个处理客户和订单的 CRUD 的 API，这是否会转化为 2 个微服务，一个用于客户，一个用于订单？

客户API

CreateCustomer
ReadCustomer
UpdateCustomer
DeleteCustomer

订单接口

CreateOrder
ReadOrder
UpdateOrder
DeleteOrder

Answer 1

从纯粹的技术角度来看，微服务越小，就越容易更快地开发（敏捷）、更快地迭代（精益）和更频繁地部署（持续交付）。但在建模方面，重要的是要避免创建太小的服务。根据 Vaughn Vernon（IDDD 书的作者）的说法，我们不能任意减小有界上下文的大小，因为它的最佳大小是由业务上下文（域）决定的。我们对服务规模的技术需求有时可能与 DDD 建模所能促进的不同（较小）。这可能就是为什么 Sam Newman 非常谨慎地称限界上下文分析是一个很好的开始，但并不是确定微服务规模的唯一处方。有界上下文是一个很好的开始。

Answer 2

许多微服务从业者向您指出的要点之一是您应该通过以下因素来指导微服务隔离：

• 所有权：理想情况下，一个团队应该拥有一个微服务，并唯一负责开发它。那么，在您的场景中，这些微服务是由不同的团队拥有还是属于单个团队负责的部分？

• 服务关系：微服务单元应该是紧密相关/耦合的事物的边界，因此必须一起部署/监控/扩展。再说一次，在你的情况下，这是你的情况吗？

最后，您可能面临的问题之一是您的示例可能太简单。简单的 CRUD 本身通常无法证明真正的微服务架构的合理性，并且过度设计这些场景可能弊大于利。

如果您的场景更复杂，您可能需要考虑更复杂的用例的微服务边界，而不是这些支持场景。