将应用程序逻辑拆分为微服务的最佳方式是什么

Question

我们考虑将整体应用程序转移到微服务，我们正处于研究阶段，因为这是我们第一次体验微服务。

目前我们认为有 3 种类型的微服务：

1. API网关-使用rpc与域服务通信
2. 领域服务——封装不同部分逻辑的服务，通过api与网关通信，以及异步事件相互通信。每个人都有自己的数据库
3. 基础设施服务 - 例如电子邮件、短信等。

到目前为止，我有一些关于如何正确分割域逻辑的问题，一些最佳实践和有用的资源值得赞赏。我还将提供一些逻辑示例以及我认为如何划分它的几种不同方式。

应用程序逻辑：我们有两个用于最终用户前端管理 api 的网关 api。

应用程序是一种社交网络，每个用户都有自己的个人资料，可以通过不同的标准（地理位置、爱好、总兼容性百分比）搜索其他人的添加到朋友、实时聊天、重新计算与其他人的兼容性。该应用程序的主要特点是计算人与人之间兼容性的算法，它考虑了出生日期和地点以及用户注册和更改用户帐户类型时收集的其他一些标准。并且根据用户帐户类型（可以由管理员购买或设置），他具有不同级别的兼容性计算。

所以我们有：用户、个人资料、用户搜索、地理位置、朋友、付款、帐户类型和权限（acl 的类型）、兼容性计算、聊天。

我不确定上一段中列出的每一项是否应被视为独立的微服务，或者例如我可以将用户、个人资料、帐户类型/权限和朋友分组到一个微服务中，并将用户搜索和地理分组到另一个微服务中。

Answer 1

开发微服务架构时的一般目标：

• 您应该能够独立地交付和部署服务。
• 开发团队应该能够独立于其他服务来实现一项服务。

现在肯定没有一种“正确”的方法可以实现这一目标，因此这里有一些我发现有用的资源和最佳实践：

• 如何将整体架构分解为微服务和限界上下文
• 微服务、有界上下文、内聚力。他们有什么共同点？
• 使用领域分析对微服务进行建模

根据您问题中的信息，在不了解更多细节的情况下，我认为您可以合理地将一些实体分组到一个微服务中，但这实际上是领域专家应该做出的决定。