在构建面向微服务的应用程序时，我想知道什么是合适的微服务粒度。
让我们想象一个应用程序包含以下内容:
一组不同的资源类型，其中每个资源都映射一个给定的业务模型。 (例如:在待办事项应用程序中，资源可以是 User、TodoList 和 TodoItem...)
每个资源都保存在可复制的 NoSQL 数据库中。
每个资源都通过 REST Api 公开
该应用程序管理内部聊天室。
用于收集聊天室和 REST API 交互的 Api 网关。
应用程序前端:连接到 API 网关的 SPA 应用程序
在考虑微服务如何满足此应用程序的需求时，第一个(也是天真的)方法是:
- 一个用于管理所有资源和业务逻辑的整体服务: 我所说的管理是指为所有这些资源提供 REST API 并处理数据库中这些资源的持久性。
- 每个数据库副本都有一项服务。
- 一项服务使用 websocket 或其他方式提供内部聊天室。
- 一项身份验证服务。
- API 网关的一项服务。
- 一项为 SPA 前端提供静态 Assets 的服务。
另一种方法是将服务 1 拆分为与系统中存在的业务模型一样多的服务。(我们将这些服务称为资源服务)
我想知道第二种方法有什么好处。 事实上，我发现这种方法有很多缺点:
- 需要设置服务间通信流程。
- 当请求表示与资源 Y 有关系的资源 X 的服务时，需要做更多的工作(即:服务间请求)
- 更多 DevOps 工作。
- 资源服务之间共享通用代码更加困难。
- 业务逻辑放在哪里？
当开始一个新项目时，第二种方法对我来说有点过度设计。
我觉得从第一种方法开始，然后根据观察到的需求将整体资源服务拆分为几个特定的服务，这样可以最大限度地降低复杂性和风险。
您对此有何看法？ 有没有最佳实践？
非常感谢!
最佳答案
根据定义，第一种方法不是微服务方式。
是的，想法是拆分 - 每个服务用于有界上下文 - 一项用于用户，一项用于库存、待办事项等。
微服务的想法非常简单，假设:
- 您希望为模块化付出额外的开发运营工作，并完全/尽可能地消除不同有界上下文之间的依赖关系(请参阅开发/产品/pjm 团队)。
- 它的想法在于所有权、模块化，允许不同的团队开发自己的代码，而不要求他们了解系统的其余部分。只要有无处不在的语言(通用的约定/通信协议(protocol)/术语/文档)，它们就可以以完全隔离、自主的方式工作。
- 维护、管理、测试和开发变得更快 - 降低了初始开发运营成本和复杂的架构工程投资。
- 共享代码应该最少，如果需要，可以用来表示通用语言(通用通信接口(interface)/约定集)。共享记录良好的代码，充当集成/基础设施迷你框架，并附加特殊的开发/开发操作/团队，这可能是一件容易的事，只要它，正如我所说，记录良好，并威胁到单独的与架构相关的子项目。
正确设计的微服务架构可以大幅减少维护和开发时间，但使用它需要相当严肃的理由(有很多理由，也有很多文章，我不会在这里开始)和相当严肃的工程投资在开始时。
它带来了模块化、所有权概念、应用程序不同上下文的解耦。
我个人的建议是检查一下你是否真的需要 MS 架构。如果您不能在开始时投入工程和开发运营工作，并且没有适当的理由建立这样的系统 - 为什么还要麻烦呢？
如果您确实需要 MS，我真的建议不要使用第一种方法。您将开发出错误的东西，将错过 MS 的真正挑战，并可能以巨大的重构而告终，这可能比从一开始就正确设计 MS 系统需要更多的工作。就像先把它做成正方形，然后再装进圆桶里一样。
现在回答您的问题标题:粒度。(您的问题正文与帖子标题略有不同)。
将其附加到域模型/限界上下文。您可以在开始时提供丰富的服务，以避免复杂的分布式事务。
首先回答问题，您的设计/架构中是否需要它们？ 如果没有，可能你的设计很好。 在不同微服务的模型之间传递引用 ID 就足够了，如果不够，请尝试重新考虑是否可以避免更多复杂的事务。
如果您的系统有不可避免的大量分布式事务，也许可以考虑使用/制作一些 CQRS 迷你框架作为您的“共享代码基础设施组件”/通信协议(protocol)。
关于web-services - 微服务粒度: Per domain model or not?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/42595302/