事件驱动架构——具有两种接口(接口类型)的后端服务

Event Driven Architecture - backend services with two interfaces (interface types)

关于事件驱动架构的几篇文章推荐了一个事件代理(例如通过主题的 Kafka)来集成后端服务,此外 RESTful 这些后端服务的接口(这里有一个来自 Guido Schmutz 的例子:使用 Apache Kafka 构建事件驱动的(微)服务,2019 年,第 19 页)。

RESTful 接口提供对 GUI 外部服务 的访问。这些 GUI 和外部服务通过 API 网关 访问 RESTful 服务。所以每个后端服务都有两种接口类型:RESTful接口和通道接口(事件代理)。

我的问题是:通过事件代理提供 RESTful API 和 并行 后端服务集成有什么好处?这个问题的原因是事件代理可以提供相同的功能(同步请求响应)。

你是对的,事件代理可以提供相同的功能:API 网关的目的之一是执行 'protocol translation'。

为您的 'frontline' 微服务使用 RESTful API 的优势在很大程度上取决于您的具体情况。有趣的是,没有什么可以阻止您通过事件代理 (REST is explicitly protocol agnostic). However, if by RESTful you mean over HTTP, then there may be benefits to using this protocol. As an example, if you intend for your microservices to be consumed by 'other' clients, then (despite the rise in event-driven architecture) 提供 RESTful API。HTTP 客观上仍然是现存最普遍的协议。

这是非常主观的,但是 'request-response' 是 event-based 框架的事后想法。如果您想遵循该模型,最好使用专为该模型设计的框架和技术。

如您所述,您当然可以并行提供 RESTful API 。这是否合适真的取决于你的 use-cases.

我的两分钱:使用任何最简单且对您最有意义的体系结构您的API网关之后。 Gateway provides abstraction,因此,如果您采用的方法不起作用,您可以进行更改,影响不大。