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

Question

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

此时，我对模型的实现有疑问，以便能够获得Kafka主题和分区的好处。我的模型需要满足一些要求：

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

嗯，考虑到这些要求，我已经尝试了一个模型：

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

我的问题：

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

修改

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

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

Answer 1

  

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

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

  

所有读取请求均由＆＃34;微服务网关＆＃34;

处理

如果确实如此，您的系统根本没有域分离。事实上，你有一个需要了解所有域名的神 - 网关。

网关应该被限制为特定于域的服务无法实现的非常专用的目的（例如安全性，路由/代理，负载平衡，整合，弹性等）。

  

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

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

  

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

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

*为了您的编辑：

  

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

关于这一点很少：

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