微服务应该有多小？

Question

一个系统应该在哪些条件下拆分为微服务，一个微服务应该“小”到什么程度？

Answer 1

我们在多个项目中实施微服务架构，我将尝试与他们分享我的经验以及我们是如何做到的。

让我首先尝试解释我们如何将我们的域拆分为微服务。在此期间，还将解释微服务应该有多大或多大的标准。为了理解我们需要查看整个方法：

我们在微服务中拆分系统的条件：

我们根据 2 组环境拆分微服务：

1. 基于生产/暂存设置。这通常是系统如何在生产环境中运行以供我们的客户使用。
2. 基于开发（开发人员开发机器）设置。这是每个开发人员必须在他们的机器上进行的设置，以便运行/调试/开发整个系统或其中的一部分。

仅考虑生产/暂存设置：

1. 基于DDD (Domain Driven Design) Bounded Context：其中 Bounded Context = 1 微服务。这是我们最终拥有的最大的 ms。大多数情况下，限界上下文也被拆分为多个微服务。为什么？原因是我们的域非常大，所以将整个有界上下文作为一个微服务是非常低效的。低效我指的主要是扩展原因，但也包括开发扩展（让较小的团队负责一个微服务）和其他一些原因。

2. CQRS（命令查询分离原则）：在将某些微服务拆分为每个限界上下文的微服务或每个限界上下文的多个微服务后，我们将它们拆分为 2 个或多个微服务，而不是 1 个。一个命令/写入微服务，第二个是读取/查询微服务。例如，假设您有一个“用户微服务”和“用户读取微服务”。“用户微服务”负责用户的创建、更新、删除和综合管理。另一方面，“Users-Read 微服务”只负责检索用户（它是只读的）。我们遵循 CQRS 模式。

   一些极端情况下的Write/Domain微服务有多个Read微服务。有时，这些读取微服务非常小，以至于它们只有一个类似非规范化视图的表示，主要使用某种 No-SQL 数据库进行快速访问。在某些情况下，它非常小，以至于从代码的角度来看，它只有几个 C#/Java 类和 1,2 个表或 JSON 集合在它们的数据库中。

3. 提供领域不可知或静态工作或服务的服务

   • 示例 1 是一个非常小的微服务，负责从 html 模板生成 pdf 格式的特定报告。

   • 示例 2 是一个微服务，它只是根据某些特定用户的权限向其发送简单的文本消息。

考虑开发设置：

除了用于本地开发/运行目的的生产/暂存设置之外，我们还需要特殊的微服务来做一些工作以使本地设置工作。本地设置是使用 docker(docker-compose) 完成的。小型微服务的例子有：

1. 数据库、缓存、身份、Api 网关和文件存储。对于生产/暂存设置中的所有这些事情，我们使用云提供商为这些事情提供服务，因此我们不需要将它们放在微服务中。但是为了让整个系统运行以用于开发/测试目的，我们需要以 Docker 容器的形式创建小型微服务来替换这些云服务。

2. 将测试/播种数据添加到系统中。为了给本地的微服务开发系统提供数据，我们需要一个小的微服务，它的唯一目的是调用微服务公开的一些 API 并将一些数据发布到其中。通过这种方式，我们可以使用预定义的数据设置工作开发环境，以测试一些简单的业务场景。

   这样做的好处是您可以将此测试数据设置与本地开发设置结合使用，以创建集成和端到端测试。

微服务应该有多小？

• 在我们的一个案例中，最小的微服务有几个视图/只读微服务，它们只有一个非规范化视图（1 个表或 1 个 JSON 集合），从代码的角度来看，它们有几个 C#/Java 类它。因此，当涉及到代码时，我认为它不会小得多，那么这将是一个合理的选择。这又是主观看法。根据您可以在线阅读的有关微服务的一些建议，可以认为此大小“太小”。我们这样做是因为它帮助我们解决了性能问题。对这些数据的需求如此之大，以至于我们将其隔离，以便我们可以独立对其进行扩展。这使我们有可能根据其需求单独扩展此微服务/视图，并且独立于该域的其余部分。

• 小型微服务的第二种情况是 html-to-pdf 服务，它只是基于特定格式的 html 模板创建 pdf 文档。您可以想象这个功能子集有多么小。

建议：

我对每个设计微服务的人的建议是提出正确的问题：

1. 微服务应该有多大，以便我们不会出现单体拆分成多个单体的情况？这意味着创建的微服务的规模将太大且难以管理，因为这是单体应用的问题。除此之外，您还会看到分布式系统的缺点。

2. 微服务的大小会影响您的性能吗？对于您的客户来说，关键是系统性能好，因此将其作为微服务系统架构的标准可能是一个非常有效的观点。

3. 我们应该或者可以提取功能/逻辑的一些关键部分以隔离它吗？哪个关键逻辑如此重要，以至于您无法承受它的损坏或服务停机？这样您就可以保护系统中最关键的部分。

4. 我可以用这种微服务架构拆分来组织我的一个或多个团队吗？

5. 考虑到我已经完成了微服务架构并且我有“n”个微服务，我将如何管理它们？这意味着支持他们、协调部署、根据需要扩展、监控等等？如果您提出的这种架构对您的组织或团队来说具有挑战性并且无法管理，那么请重新考虑它们。没有人需要一个无法管理的系统。

还有更多可以引导您走向正确的方向，但这些是我们遵循的方向。

这些问题的答案将自动引导您找到适用于您的域/业务的最小/最大微服务。我上面关于微服务大小的示例现在可能适用于您的案例和我们使用的规则，但回答这些问题将使您更接近您自己的方法/规则来决定这一点。

结论

微服务应该尽可能小，以满足您的需求。名称“微型”表示它们可以非常小。请注意不要将此作为所有系统的规则。最小的微服务是解决某些特定问题（例如扩展或关键逻辑隔离）的例外，而不是在这种规模的微服务中设计/拆分整个系统的规则。如果您拥有许多非常小的微服务只是为了拥有它们并且它们很小，那么您将很难管理它们而没有真正的好处。小心你如何分割它。