对微服务非常陌生...
如果我有一个为客户和订单处理 CRUD 的 API，这是否会转化为 2 个微服务，一个用于客户，一个用于订单？
客户 API
CreateCustomer
ReadCustomer
UpdateCustomer
DeleteCustomer
订单 API
CreateOrder
ReadOrder
UpdateOrder
DeleteOrder
【问题讨论】：
标签： node.js amazon-web-services aws-lambda microservices
从纯粹的技术角度来看，微服务越小，就越容易开发得更快（敏捷）、迭代得更快（精益）和更频繁地部署（持续交付）。但在建模方面，重要的是要避免创建太小的服务。根据 Vaughn Vernon（IDDD Book 的作者）的说法，我们不能随意减小有界上下文的大小，因为它的最佳大小是由业务上下文（域）决定的。我们对服务大小的技术需求有时可能与 DDD 建模可以促进的不同（更小）。这可能就是为什么 Sam Newman 非常谨慎地将有界上下文分析称为一个很好的开始，但不是如何调整微服务大小的唯一处方。限界上下文是一个很好的开始。
【讨论】：
我会说这取决于如何使用这些服务。这里有两个我会想到的选择
您甚至可以为每个端点设置一个 lambda 函数（在您的案例 6 中），并受益于为每个函数选择最佳内存大小和超时（有利于计费和性能）。
此外，在这种情况下，您可以分离每个函数的权限（例如，每个函数一个 IAM 角色），并允许每个函数仅以完成任务所需的方式访问资源。
在这种情况下，我将分为 customer 和 order 服务，因为它们都处理不同的数据模型。
这 2 个 Lambda 函数共享相同的内存和超时设置。
...
在任何情况下，您当然可以将函数处理程序以代码方式组合在一个类中，并且您可以为每个 CRUD 事件使用多个处理程序。或者检查HTTP方法和重定向到相应的逻辑。
使用SAM 可以轻松部署这两个选项。
一些很好的文档以获得更多信息：
【讨论】：
我们通常在聚合边界上削减我们的服务。领域驱动设计非常适合微服务，因为它有助于设计具有松散耦合的聚合。我建议先这样做，永远不要参考客户的订单，反之亦然。仅通过域事件进行通信。这样，在另一个进程或服务器上运行一个聚合的决定只是一个实现细节，可以在以后完成。
如果您将它们分成两个服务，您将不得不实现某种形式的通信。这通常比在同一进程上运行它们更昂贵，但在扩展方面您可以获得更大的灵活性。在您只有两个聚合的情况下，我会将它们保留在一项服务上。微服务的一大优点应该是它们太小了，你可以删除、重写和替换它。我认为使用两个聚合这仍然是可能的，因此不值得麻烦。
但同样，做一个 mircorservice 架构应该是一个实现细节。您的域必须首先设计好，否则将聚合门切割成服务将是一场噩梦。
预先创建微服务的唯一好处是，您已经开始设计时考虑到这一事实，您不能仅仅参考另一个聚合并阅读一些属性来决定某事。如果您的团队不习惯 DDD 或松散耦合，这可能会很有价值。
【讨论】：
许多微服务从业者会向您指出的一个关键点是，您应该通过一些因素来指导您的微服务隔离：
所有权：理想情况下，一个团队应该拥有一个微服务并独自负责发展它。那么，在您的场景中，这些微服务是由不同的团队拥有，还是属于某个团队将负责的事情？
服务关系：微服务单元应该是密切相关/耦合的事物的边界，因此必须一起部署/监控/扩展。同样，在您的情况下，这是您的情况吗？
最后，您可能面临的问题之一是您的示例可能过于简单。简单的 CRUD 通常无法证明真正的微服务架构是合理的，过度设计这些场景可能弊大于利。
如果您的场景更复杂，您可能需要考虑使用更复杂的用例而不是这些支持场景的微服务边界。
【讨论】：