微服务应该有多小？

Posted 2023-03-08

【中文标题】微服务应该有多小？

【英文标题】：How small a micro service should be?

【发布时间】：2019-10-23 20:51:23

【问题描述】：

一个系统应该根据哪些条件拆分成微服务，一个微服务应该有多“小”？

【问题讨论】：

这是一个非常好的主意。很多时候我都处于类似的情况。对于像微服务这样的主题，一些已知和记录在案的解决方案对于我们的案例/应用程序并不总是足够好，了解其他方法和解决方案（其他人如何解决或接近它）会很好。以这种方式记录它是一个好主意，因为这可以帮助社区。​​span>

我投票决定将此问题作为题外话来结束，因为这是一个关于询问社区我们是否应该接受有关启发式的问题的元问题。元问题属于 meta.***.com

@GeorgeStocker 你是对的！我在提交问题时就知道可能会被关闭。由于这个问题有一个很好的详细答案，我修改了问题的内容以便重新打开它

【参考方案1】：

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

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

我们将系统拆分为微服务的条件：

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

基于生产/暂存设置。 这通常是系统在要使用的生产环境中运行的方式 由我们的客户提供。 基于 Development（Developers 开发机器）设置。 这是每个开发人员必须在他们的机器上进行的设置 运行/调试/开发整个系统或部分系统。

---

仅考虑生产/登台设置：

基于DDD（领域驱动设计）有界上下文： 其中有界上下文 = 1 个微服务。 这是我们最终拥有的最大的毫秒数。大多数时候 限界上下文也被拆分为多个微服务。 为什么？ 原因是我们的域非常大，所以保留了整个有界上下文 因为一项微服务效率很低。我所说的低效主要是指扩展原因，但是 还有开发扩展（让较小的团队负责一项微服务）和其他一些原因 也是。

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

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

提供与领域无关或静态工作或服务的服务

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

示例 2 是一个微服务，它只是向某些特定用户发送简单的文本消息 基于他们的权限。

---

考虑开发设置：

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

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

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

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

---

微服务应该有多小？

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

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

建议：

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

微服务应该有多大，这样我们就不会遇到将单体拆分成多个单体的情况？ 这意味着创建的微服务的大小将太大且难以管理，因为这就是问题所在 对于巨石。除此之外，您还会发现分布式系统的缺点。

微服务的大小会影响您的性能吗？ 对于您的客户来说，关键是系统性能好，所以考虑到这一点 微服务系统架构的标准可能是一个非常有效的观点。

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

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

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

还有更多可以引导您走向正确方向的方法，但这些都是我们所关注的。

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

结论

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