微服务、REST、事件源和数据一致性
我正在计划一个使用事件源的微服务模型。为了实现高可伸缩性和高吞吐量处理能力，我将使用Kafka作为微服务的消息代理。
在这一点上，我有问题的实现模型，以能够拥有Kafka主题和分区的好处。我的模型需要满足一些要求：
- 微服务必须从message broker获取数据(post/patch/put/delete)
- 数据一致性是强制性的，如果实体A需要实体B的先前存在，则必须只存在实体A的指向实体B的有效记录的记录
- 微服务无法耦合它们的域（引用DDD)
- 系统必须处理大量读写操作
-
null
-
null
- 在Elasticsearch数据库中搜索请求资源的记录
- 用结果响应请求者
我的问题：
- 这个模型有一些域的耦合吗？网关正在验证子资源ID，以确保Elasticsearch数据库中的数据一致性（A指向B的情况）。
- 我不知道这个模型是否适合报表请求，有些复杂的报表处理大量来自用户的输入参数的数据，从用户的角度来看，操作必须是“同步的”（请求/响应REST）
- 请求/新状态的验证是否是业务逻辑的一部分（与DDD相关）？如果是这样，我的模型将它们分成两个微服务？
-
null
共有1个答案
-
null
-
null
-
我想知道你是否能帮忙。我正在编写一个订单系统，目前已经实现了一个订单微服务来处理下订单。我正在使用DDD与事件源和CQRS。 订单服务本身接收生成事件的命令，实际的订单服务侦听自己的事件以创建读取模型（这里的想法是使用CQR，因此用于写入的命令和用于读取的查询） 在执行上述操作后，我遇到了一个问题，可能只是我没有完全理解正确的方法。 一个订单实际上有依赖项，这意味着一个订单需要一个客户和一个产品。
-
虽然每个微服务通常都有自己的数据，但某些实体需要在多个服务之间保持一致。 对于高度分布式环境（如微服务体系结构）中的这种数据一致性要求，设计的选择是什么？当然，我不想要共享数据库体系结构，即单个数据库管理所有服务的状态。这违反了孤立和不共享的原则。 我明白，微服务可以在创建、更新或删除实体时发布事件。对该事件感兴趣的所有其他微服务可以相应地更新各自数据库中的链接实体。 这是可行的，但是它会导致跨服
-
假设我们有一个用户、Wallet REST微服务和一个将事情粘合在一起的API网关。当Bob在我们的网站注册时，我们的API网关需要通过用户微服务创建一个用户，通过钱包微服务创建一个钱包。 下面是一些可能出错的场景： > 用户Bob创建失败：没关系，我们只需向Bob返回一个错误消息。我们使用的是SQL事务，所以没有人在系统中看到Bob。一切都很好：） 创建了用户Bob，但在创建钱包之前，我们的AP
-
脚本 我正在使用微服务构建快递服务系统。我不确定一些事情，这是我的场景 预订API-这是客户下订单的地方 付款API-这是我们处理预订付款的地方 通知API-有服务负责在一切完成后发送通知。 系统采用事件驱动架构。当客户下预订订单时，我在预订应用编程接口中提交本地交易并发布事件。支付应用编程接口和通知应用编程接口订阅了各自的事件。一旦完成，支付和通知应用编程接口需要向预订应用编程接口确认。 我的问
-
我们正在设计我们的新系统，它很可能是从头开始编写的，因为旧系统非常非常旧。对我们的系统来说，保留系统中发生的所有事情的审计跟踪日志非常重要。 由于审计跟踪的重要性，我们决定遵循事件源架构以获得它的所有好处。另一个关键因素是我们有多个团队在不同的“域”上工作。也就是说，我们想将每个域拆分为自己的服务（微服务架构），这样每个团队都可以独立工作。 我们面临的最大问题是谁将负责微服务之间的事件共享。例如，
-
事件源和CQR如何帮助实现微服务的解耦架构。 我们可以让微服务拥有自己的数据，其他人通过服务访问数据，即使是通过传统的持久性手段。不是吗？