20、微服务大小设计与领域建模实践

微服务大小设计与领域建模实践

1. 微服务大小问题

微服务过大或过小都会带来潜在问题。若微服务架构设计得与之前架构相似，就回到了微服务原本要解决的问题，甚至会形成分布式单体架构（也称为宏服务）。这就引发了一个问题：微服务应该多大或多小呢？

有人说，一个微服务应该小到一个团队用两个披萨就能养活（即小团队）在一周内完成开发。但这只是个难以遵循的准则。我们可以从上下界的角度来考虑微服务的大小。

• 下界 ：

  • 一个微服务应至少包含一个聚合（或至少一个独立实体）以及对该聚合实体进行操作的相关应用服务和领域服务。聚合是一组生命周期相互关联的实体，可视为一个内聚单元，例如订单/订单项关系就是典型的聚合示例。
  • 领域服务是一种不自然对应于任何特定实体或值对象的领域概念，如银行账户的“转账”操作。
  • 在设计微服务大小时，要非常仔细地考虑事务边界。不仅要考虑实体的创建、读取、更新和删除生命周期，还要考虑实体组的所有更新操作，包括批量更新和复杂查询等。
  • 即使这可能需要微服务有10个甚至20个独立的REST接口，如果领域特定区域足够复杂，这就是应发布的最小微服务单元。通常，一开始让微服务偏大比偏小更好，因为将一个较大的宏服务拆分为两个服务比将两个细粒度的微服务合并更容易。
  • 可以通过事件风暴来识别聚合和相关服务。

• 上界 ：

  • 一个微服务不应大于围绕领域建模的一组相关（