微服务粒度：是否按域模型？

Question

在构建面向微服务的应用程序时，我想知道合适的微服务粒度是多少。

让我们想象一个包含以下内容的应用程序：

• 一组不同的资源类型，其中每个资源映射一个给定的业务模型。 （例如：在待办事项应用中，资源可以是 User、TodoList 和 TodoItem...）

• 这些资源中的每一个都保存在可以复制的 NoSQL 数据库中。

• 这些资源中的每一个都通过 REST Api 公开

• 应用程序管理内部聊天室。

• 用于收集聊天室和 REST api 交互的 Api 网关。

• 应用前端：连接API网关的SPA应用

---

在考虑微服务如何满足此应用程序的需求时，第一种（也是幼稚的）方法是：

1. 一个用于管理所有资源和业务逻辑的整体服务： 管理是指为所有这些资源提供 REST API 并处理这些资源在数据库中的持久性。
2. 每个数据库副本一个服务。
3. 一种使用 websocket 或其他方式提供内部聊天室的服务。
4. 一项身份验证服务。
5. api 网关的一项服务。
6. 为 SPA 前端提供静态资产的一项服务。

---

另一种方法是将服务 1 拆分为与系统中存在的业务模型一样多的服务。（我们将这些服务称为资源服务）

我想知道第二种方法有什么好处。 事实上，我看到这种方法有很多缺点：

• 需要设置服务间通信进程。
• 当请求代表资源 X 且与资源 Y 有关系的服务时，需要做更多的工作（即：服务间请求）
• 更多 devops 工作。
• 在资源服务之间共享公共代码更加困难。
• 把业务逻辑放在哪里？

---

当开始一个新项目时，第二种方法对我来说有点过度设计的工作。

我觉得从第一种方法开始，然后根据观察到的需求将单体资源服务拆分为几个特定的​​服务，这样可以最大限度地降低复杂性和风险。

您对此有何看法？ 有什么最佳做法吗？

非常感谢！

Answer 1

根据定义，第一种方法不是微服务方式。

是的，想法是拆分 - 每个服务用于限界上下文 - 一个用于用户，一个用于库存，待办事项等。

微服务的概念非常简单，假设：

1. 您想为模块化支付额外的开发运维工作，并完成/尽可能多地消除不同有界上下文之间的依赖关系（请参阅 dev/product/pjm 团队）。
2. 它的理念在于所有权、模块化，允许独立的团队开发自己的代码，而不要求他们了解系统的其余部分。只要存在通用语言（通用的约定/通信协议/术语/文档集），它们就可以以完全独立、自主的方式工作。
3. 维护、管理、测试和开发变得更快 - 在初始开发运营成本和复杂的架构工程投资方面。
4. 共享代码应该是最少的，如果需要，可以用来表示通用语言（通用通信接口/约定集）。共享记录良好的代码，充当集成/基础设施迷你框架，并附有特殊的开发/开发运营/团队，这可能是一件容易的事，只要它，正如我所说的，有据可查，并受到威胁独立的架构相关子项目。

适当设计的微服务架构可以大大减少维护和开发时间，但是使用它需要非常认真的理由（原因很多，并且有很多文章，我不会在这里开始）和非常认真的工程投资开始。

它带来了模块化、所有权概念以及应用程序不同上下文的解耦。

我个人的建议是检查你是否真的需要 MS 架构。如果您不能在一开始就投入 engenerring 和 dev-ops 工作，并且没有适当的理由来使用这样的系统 - 为什么还要麻烦？

如果您确实需要 MS，我真的建议您不要使用第一种方法。您将开发错误的东西，将错过 MS 的真正挑战，并且可能以巨大的重构结束，这可能比从头开始正确设计 MS 系统需要更多的工作。就像是做成方形，以便以后适合圆桶。

现在回答您的问题标题：粒度。（您的问题正文与您的帖子标题有点不同）。

将其附加到域模型/限界上下文。您可以在开始时制作大量服务，以避免复杂的分布式事务。

如果您在设计/架构中需要它们，请先回答问题？ 如果没有，可能你做了一个很好的设计。 在来自不同微服务的模型之间传递引用 ID 就足够了，如果没有，请尝试重新考虑是否可以避免更多复杂事务。

如果您的系统有不可避免的大量分布式事务，也许可以考虑使用/制作一些 CQRS 迷你框架作为您的“共享代码基础架构组件”/通信协议。

Answer 2

这是微服务或任何其他 SOA 方法的关键问题。这是理论与现实相遇的地方。一般来说，你不应该为了微服务架构而强行使用它。这应该很自然地来自功能分解（自上而下）和运营、技术、开发运营需求（自下而上）。第一种方法更接近您需要做的事情，但是在第一步不要过多关注技术方面。问问自己为什么需要为特定的业务功能实现单独的服务。将其视为具有所有技术资源的微应用程序。问问自己是否有理由将特定功能实现为全栈应用程序。

• 您在方案 1) 中提到的一些功能自然没问题，例如“身份验证”服务 - 这可能是不错的候选者。
• 对于业务功能分解成单独的服务，关注“依赖”问题，如果依赖太多，你看到你必须实现更大的数据块模式——这自然不再是微服务了。
• 尝试进行试金石，如果您可以“关闭”特定功能并且系统仍然有意义 - 它是服务或进一步分解的候选者