如何根据业务能力将单体分解为微服务？

Question

我有一个使用一个数据库的单体应用程序，在我的公司，我们决定重写应用程序并在后端使用微服务。

此时，我们决定不拆分数据库，因为其他应用程序和进程正在使用它，并且需要两年时间才能更改。

这个过程的难点在于分解和识别正确的微服务。

我将尝试通过描述 UI 来解释我们的系统。 请仔细阅读，因为我正在尝试详细解释它。

系统显示股市数据。 市场上的公司或基金或基金经理每天发布有关公司活动的报告，例如状态、投资者信息等。

“突发公告”页面显示今日优先报道列表。 每行包含公司正在发布的 pdf 文档（报告）中的主题以及属于该报告的公司：

当用户点击该行时，我们将重定向到“报告页面”，其中包含报告详细信息：

在数据库中，我们有report 、 company 、 company_report 、 event 、 public_offers 、 upcoming_offering等实体。

因此，为了获取列表，我们运行一个内部连接查询，如下所示：

Select ... From report r inner join
company_report cr on r.reportid=cr.reportid
inner join company c on cr.company_cd=c.company_cd
Where ....

我们的大多数服务器端点都没有改变任何东西，只是用于检索数据。

因此，我将创建此端点/reports/breaking-announcement以获取列表，它返回一个 object，如下所示：

[{ reportId, subject, createAt, updateAt, pdfUrl, company: { id, name } }]

今天的公司报告页面就像“突发公告”页面。 但该页面显示了今天的所有报告（不一定具有优先级）。

披露是报告

在此页面上，我们还可以搜索以获取 cretiria 的所有报告，例如按公司名称获取报告。 为此，我们有自动完成功能，因此用户可以键入公司名称或 ID。

另一方面，我们认为它应该是 API 端点/companies/by-autocomplete并且响应将是[{ companyId, companyName, isCompany }] 。

eft 页面与以前相同，但这次我们显示基金报告（不是公司报告）。 该列表包含基金名称和报告主题。 每次点击该行都会进入报告详细信息页面（同一页面）。

在此页面上，我们通过自动完成功能按标准进行搜索，例如从日期到日期、名称或基金 ID。 和端点（ /funds/by-autocomplete返回[{ fundId, fundName, ...}] ）。

外国 etf 页面与以前相同，项目列表。 每个项目都像以前一样：

<fund name>
<subject of the report>

查询是不同的。

---

好的，这是一个很长的描述。 感谢您的阅读。

现在我想检测这个应用程序的微服务是什么。

我最终得到：

• 报表微服务——负责获取和处理系统中的所有报表。 它有一个端点，如 getall、getbyid、get breakingannouncement、getcompanytodayreports、getfunds、getforeignfunds。 报告微服务将向公司或基金微服务发出请求，以加入来自公司的数据并构建响应。

• 公司微服务：处理所有公司数据。 我指的是getall 、 getByIds （用于报告服务）、 getByAutocomplete等端点。

• 资金微服务：处理所有资金数据。 我指的是getall 、 getByIds （用于报告服务）、 getByAutocomplete等端点。

还有其他服务，例如通知服务或 email 服务。 但那些不是商业服务。 我想将我的业务逻辑拆分成微服务，以便轻松部署和维护它们。

---

我不确定我分解得对不对。 也许我会。 但是否契合微服务思想？ 它符合模式：按业务能力分解？ 如果不是，我系统中的业务能力是什么？

Answer 1

此时，我们决定不拆分数据库，因为其他应用程序和进程正在使用它，并且需要两年时间才能更改。

我会试着在这里阻止你。 在一般情况下，共享数据库是微服务架构中的一个巨大的反模式，应该尽可能避免。 这里存在多个问题——服务之间的依赖性不那么透明，这会导致高度耦合以及开发和部署中的所有后果，增加最终以分布式单体而不是微服务结束的机会，等等。

使用它的其他应用程序和进程不应阻止您远离它 - 有些事情可以减轻这种情况 - 您只需在服务和“遗留”数据库之间同步数据（异步使用与您将在微服务中使用的方法基本相同的方法- 例如事务日志拖尾，例如使用debezium 之类的东西）。 它有它自己的成本，但我认为通常先支付它们比支付更大比例的技术债务更好。

我最终得到：....

我认为这种拆分看起来更像是按子域分解，然后按业务能力分解。 这实际上可以很好并且也适合微服务架构。

根据您的描述，我至少看到您的系统中可以定义以下业务功能：

• 查看（管理？）突发公告
• 查看（管理？）报告
• 搜索（报告？）

潜在的“今天的报告”和“资金报告”可以被视为单独的业务功能。

我想将我的业务逻辑拆分成微服务，以便轻松部署和维护它们。

话又说回来——我强烈建议重新考虑不要离开共享数据库。

我不确定我分解得对不对

如果没有系统的整体概览，包括数据量、数据流、可用于开发的资源和团队的能力、传入的新业务需求量、潜在的变化向量等，就很难真正说出来。

聚苯乙烯

请注意，尽管微服务架构非常受欢迎，但对于 go 成熟微服务的具体项目而言，它并不总是正确的解决方案。 如果您的团队很小和/或不处理具有各种访问模式的高负载/大量数据，那么您可能不需要微服务。 不过，您仍然可以利用微服务架构中使用的许多方法。

Answer 2

我不认为对当前应用程序整体进行面向查询的分解会导致良好的微服务 (MS) 设计。 您提议的两个微服务具有相同的端点查询 API，这向我表明您正在将第一代微服务视为实体服务器。

您对跨 MS 查询操作执行连接的想法表明这些第一代“微服务”紧密耦合，因此不符合真正的 MS 架构。

验证 MS 设计的一种技术是问自己，“如果一个 MS 不可用 3 分钟，整个系统将如何处理？”。 解决该设计挑战会导致微服务之间实现解耦的基于消息的交互。 这反过来导致微服务之间的交互被表示为业务操作，其中一个 MS 发出消息，触发另一个 MS 的 state 中的突变。

也许你应该减少 scope 的 MS 野心，而是看看 GraphQL 中的模式拼接。阅读你的问题的两行之间，我认为朝着分布式系统迈出的更现实的第一步是创建具有 GraphQL 端点的专门查询服务。