微服务粒度：是否为每个域模型？

Question

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

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

• 一组各种资源类型，其中每个资源映射给定的业务模型。 （例如：在todo app资源中可能是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. 它的主意在于所有权，模块化，允许独立的团队开发自己的代码，而不需要他们知道系统的其余部分。只要存在Umbiqutious Language（通用协议/通信协议/术语/文档），它们就可以以完全独立的，自动的方式工作。
3. 维护，管理，测试和开发变得更快 - 初始开发成本和复杂的架构投资。
4. 共享代码应该是最小的，并且如果需要，可以用来表示Umbiqutious Language（公共通信接口/约定集）。共享记录良好的代码，充当集成/基础架构的迷你框架，并且附加了特殊的dev / dev-ops /团队，这应该是简单的业务，只要它，正如我所说，有充分记录，并作为独立的与建筑相关的子项目。

适当地改进微服务架构可以大幅度减少维护和开发时间，但它需要非常严重的理由使用它（有很多原因，很多文章，我不会在这里开始）和非常严重的投资在开始。

它带来了模块化，所有权概念，应用程序不同上下文的分离。

我的个人建议检查您是否真的需要MS架构。如果你不能投资engenerring并开始努力，并没有适当的理由这样的系统 - 为什么要打扰？

如果你确实需要MS，我会建议不要使用第一种方法。您将开发错误的东西，将错过MS的真正挑战，并可能以巨大的重构结束，这可能比开始正常的MS系统需要更多的工作。它喜欢制作正方形以使其适合圆桶。

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

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

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

如果您的系统具有不可避免的分布式传输量，可能会考虑使用/制作一些CQRS迷你框架作为您的共享代码基础架构组件＆＃34; /通信协议。

Answer 2

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

• 在场景1）中提到的某些功能自然是可以的，例如“身份验证”服务-这可能是不错的选择。
• 对于将业务功能分解为单独的服务的情况，请关注“依赖项”问题，如果依赖项过多，您会发现必须实现更大的数据模式块-自然，这不再是微服务。
• 尝试进行石蕊测试，如果您可以“关闭”特定功能，并且系统仍然有意义-它是进行服务或进一步分解的候选人