微服务 - 它是每个CRUD一个服务

Question

微服务很新......

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

客户API

CreateCustomer
ReadCustomer
UpdateCustomer
DeleteCustomer

订购API

CreateOrder
ReadOrder
UpdateOrder
DeleteOrder

Answer 1

我们通常会在总体边界上削减服务。 Domain Driven Design非常适合微服务，因为它有助于设计松散耦合的聚合体。我建议先做这个，不要在客户中引用订单，反之亦然。仅通过域事件进行通信。这样，在另一个进程或服务器上运行一个聚合的决定只是一个实现细节，可以在以后完成。

如果您将它们分成两个服务，则必须实现某种形式的通信。实现这一过程通常比在同一进程上运行它们更昂贵，但在扩展方面可以获得更大的灵活性。在您只有两个聚合的情况下，我会将它们保留在一个服务上。微服务的一大优点应该是它们非常小，你可以删除，重写和替换它。我认为有两个聚合，这仍然是可能的，因此不值得麻烦。

但同样，做一个mircorservice架构应该是一个实现细节。您的域名必须先设计好，否则将服务转移到服务中将是一场噩梦。

预先创建微服务的唯一好处是，你已经开始考虑事实的设计，你不能只引用另一个聚合并阅读一些事情来决定一些东西。如果您的团队不习惯DDD或松散耦合，那么这可能很有价值。

Answer 2

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

Answer 3

许多微服务从业者会向您指出的一个关键点是，您应该通过某些因素指导您的微服务隔离：

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

• 服务关系：微服务单元应该是密切相关/耦合的事物的边界，因此必须部署/监控/缩放。再次，在您的方案中，这是您的情况吗？

最后，您可能遇到的一个问题是您的示例可能过于简单。简单的CRUD本身通常不能证明真正的微服务架构是合理的，而且过度工程设计这些场景可能会给你带来更多弊大于利。

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

Answer 4

我想说这取决于这些服务的使用方式。以下是我想到的两个选项

opt 1）每个端点一个Lambda方法

您甚至可以为每个端点设置一个lambda函数（因此在您的情况下为6），并且可以为每个函数选择最佳内存大小和超时（适用于计费和性能）。

此外，您可以在这种情况下分离每个功能的权限（例如，每个功能一个IAM角色），并允许每个功能仅以完成任务所必需的方式访问资源。

opt 2）两个lambda函数

在这种情况下，我将分为 customer 和 order 服务，因为它们都处理不同的数据模型。

2个Lambda函数共享相同的内存和超时设置。

...

在任何情况下，您当然可以将代码方式与函数处理程序组合在一个类中，并为每个CRUD事件组合多个处理程序。或者检查HTTP方法并重定向到相应的逻辑。

使用SAM可以轻松部署这两个选项。

有关进一步信息的一些好文档：

Serverless architecture with AWS Lambda