微服务、REST、事件溯源和数据一致性

Posted 2023-03-08

【中文标题】微服务、REST、事件溯源和数据一致性

【英文标题】：Microservices, REST, event sourcing and data consistency

【发布时间】：2018-08-04 10:14:36

【问题描述】：

我正在规划一个使用事件溯源的微服务模型。为了实现高可扩展性和高吞吐量处理能力，我将使用 Kafka 作为微服务的消息代理。

在这一点上，我对模型的实现有疑问，以便能够拥有 Kafka 主题和分区的好处。我的模型需要满足一些要求：

微服务必须从消息代理中提取数据 (POST/PATCH/PUT/DELETE) 数据一致性是强制性的，如果实体 A 需要实体 B 的先前存在，则必须只存在指向实体 B 的有效记录的实体 A 的记录 微服务无法耦合其域（参考 DDD） 系统必须处理高吞吐量的读写操作

嗯，考虑到这个要求，我最终得到了一个模型：

使用具有当前有效状态的 Elasticsearch 数据库 所有写入请求都由“微服务网关”接收，该“微服务网关”：
验证请求和请求的新状态 在消息代理中产生写入操作 从消息代理接收状态更改事件 用新的状态改变响应请求者
所有写入操作都由“微服务处理器”使用，该“微服务处理器”：
处理所有业务逻辑和数据非规范化 更新 Elasticsearch 数据库中的状态 在消息代理中生成状态更改事件
所有读取请求都由“微服务网关”处理：
在 Elasticsearch 数据库中搜索所请求资源的记录 用结果回复请求者

我的问题：

此模型是否对域进行了一些耦合？网关正在验证子资源 ID，以确保一个 Elasticsearch 数据库中的数据一致性（A 指向 B 的情况）。 我不知道这个模型是否适合报告请求，有一些复杂的报告处理大量数据，用户输入参数，从他的角度来看，操作必须是“同步的”（请求/响应休息） 请求/新状态的验证是否是业务逻辑的一部分（与 DDD 相关）？如果是这样，我的模型将它们分成两个微服务是不正确的？

编辑

我为我的客户提出的新建议：

不让网关充当微服务的一部分，让网关仅用于：路由（微服务注册表）、平衡和身份验证（调用专用微服务进行身份验证/授权） 微服务拥有自己的数据/数据库，通过事件溯源架构确保一致性 报告：如果是关于一个域，可以是微服务中保存数据的资源，如果需要多个域，另一个微服务将提供报告

【问题讨论】：

我在回答中添加了一些 cmets。

【参考方案1】：

这个模型做了一些领域的耦合吗？网关正在验证子资源 ID，以确保一个 Elasticsearch 数据库中的数据一致性（A 指向 B 的情况）。

您用以下句子回答了您自己的问题：

所有读取请求都由“微服务网关”处理

如果是这样，您的系统根本就没有域分离。事实上，您有一个需要了解所有域的上帝网关。

应将网关限制在特定领域的服务无法实现的非常专用的用途（例如安全性、路由/代理、负载平衡、整合、弹性等）。

我不知道这个模型是否适合报告请求，有一些复杂的报告处理大量数据，用户输入参数，从他的角度来看，操作必须是“同步的”（请求/响应休息）

我将报告视为一项单独的服务，理想情况下使用现有服务来获取所需的任何信息。根据您的域和要求，您可能希望在您的服务中为此设置一些专用的非公共端点，或者您可能希望直接访问数据库（例如，对图形数据库进行专门的查询）。

请求/新状态的验证是否是业务逻辑的一部分（与 DDD 相关）？如果是这样，我的模型将它们分成两个微服务是不正确的？

这取决于验证的类型。为了从域的角度验证正确性，您需要相应的服务。如果您想验证系统的其他部分可能负责的其他事情（记录、授权、阻止恶意尝试……）

*供您编辑：

不让网关充当微服务的一部分，让网关仅用于：路由（微服务发现）、平衡和身份验证（调用专用微服务进行身份验证/授权）

关于这个的几件事：

通常您不会在 API 网关上执行实际的服务发现。相反，它应该是集群编排的一个功能（参见how kubernetes does it for you）。网关只会使用服务注册表来正确代理（例如使用正确的 DNS 条目）。 发明微服务架构风格是为了让大型组织能够扩展快速增长的服务器应用程序。它确实有缺点，尤其是在为需要快速获得结果的小型项目设置时。来自那些大型组织的大多数人会告诉您最初从单体开始，并在团队变得太大时分离（通过绘制组件边界，您可以在初始开发中为这种分离做好准备）。即使使用“单体”服务，您仍然可以使用 CICD 拥有现代化的构建/测试/部署基础架构，并且该服务仍然可以具有水平可扩展性。由于我不知道您的域/项目规模，我只是想将其作为一个总体思路。

【讨论】：

太棒了！我对模型不满意，所以我审查了要求并为我的客户提出了新的建议。新提案在问题的编辑中。有时不是关于如何满足需求，而是需求如何满足客户对系统功能的期望。

模型真正做的是：服务本身用私钥连接到网关，网关只允许已知的公钥。所以这不是“服务发现”，而是服务注册。我会编辑我的问题。我同意你关于微服务解决问题的所有观点。我的情况是：客户已经有一家大型金融公司存在团队隔离问题，他们开发的一堆技术不是核心业务，而且绝对不可扩展。 “过早的优化是万恶之源”，但在这种情况下，是时候去做了。