Microservices 微型服务应该有多小？

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

我们在多个项目中实施微服务体系结构，以及 我将尝试与他们分享我的经验，以及我们在哪里做这件事

首先让我来解释一下我们是如何将我们的领域划分为微型服务的。在此期间 微服务应该有多小或多大的标准也将被解释。为了 了解我们需要了解整个方法：

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

我们将基于两组环境拆分微服务：

基于生产/暂存设置。 这通常是系统在要使用的生产环境中运行的方式 由我们的客户提供

基于开发（开发者开发机器）设置。 这是每个开发人员必须在其机器上进行的设置 运行/调试/开发整个系统或部分系统

---

仅考虑生产/分段设置：

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

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

在某些极端情况下，写/域微服务具有多个读微服务。有时，这些读取微服务的位置非常小，以至于它们只有一个非规范化视图，比如 表示主要使用某种无SQL数据库进行快速访问。在某些情况下，它是如此之小，以至于 从代码的角度来看，它只需要几个C#/Java类和1,2个表或JSON集合 在他们的数据库中

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

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

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

---

考虑开发设置：

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

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

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

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

---

微服务应该有多小？

• 在我们的一个案例中，最小的微服务 View/Read only mircro服务，其中只有一个非规范化视图（1个表或1个JSON集合），该视图来自代码 里面有几个C#/Java类。所以当涉及到代码时，我不认为它会比这个小很多 这是一个合理的选择。这也是主观的观点。 根据一些关于微服务的建议，这种规模可能被认为“太小” 你可以在线阅读。我们这样做是因为它帮助我们解决了性能问题。 对这些数据的需求如此之大，以至于我们将其隔离开来，以便能够独立扩展。 这使我们能够根据其需求独立地扩展此微服务/视图 来自该领域的其他部分

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

建议：

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

微服务的规模应该有多大，这样我们就不会出现将一块巨石分割成多块巨石的情况？ 这意味着创建的微服务的规模将太大，难以像t一样管理