API 网关应该通过队列通信还是直接与其他 μServices 通信?
Should an API Gateway Communicate via a Queue or directly to other μServices?
我想知道我的两种方法哪种更合适,或者还有另一种方法?
(1) 直接
GATEWAY
和 μSERVICE A
之间的直接通信
UI
发送 HTTP
请求到 GATEWAY
GATEWAY
发送 HTTP
请求到 μSERVICE A
μSERVICE A
returns SUCCESS
或 ERROR
- 事件存储在
EVENT STORE
并发布到 QUEUE
PROJECTION DATABASE
已更新
- 其他
μSERVICES
可能会消耗事件
(2) 事件
通过消息队列进行基于事件的通信
UI
发送 HTTP
请求到 GATEWAY
GATEWAY
已将活动发布到 QUEUE
μSERVICE A
消耗事件
- 事件存储在
EVENT STORE
并发布到 QUEUE
PROJECTION DATABASE
已更新
- 其他
μSERVICES
可能会消耗事件
GATEWAY
消费事件并将响应(SUCCESS
或 ERROR
)发送到 UI
如果我误解了一些概念,我真的很抱歉,我对这种架构风格比较陌生。
在此先感谢您的帮助! :)
第二种方法是首选方法并且是异步方法。
直接
首先,您的 microsvc B 和 C 等待事件发布。这个系统的可扩展性直接依赖于 microsvc A。如果 microsvc A 宕机或落后于写入事件到队列怎么办?这就像单点故障和瓶颈。您无法轻松扩展系统。
事件
在微服务中,我们保持系统异步,以便它们可以扩展。
网关应该使用 pub/sub 写入队列,所有这些微服务都可以同时使用事件。总体而言,系统更强大并且可以扩展。
我想知道我的两种方法哪种更合适,或者还有另一种方法?
(1) 直接
GATEWAY
和 μSERVICE A
UI
发送HTTP
请求到GATEWAY
GATEWAY
发送HTTP
请求到μSERVICE A
μSERVICE A
returnsSUCCESS
或ERROR
- 事件存储在
EVENT STORE
并发布到QUEUE
PROJECTION DATABASE
已更新- 其他
μSERVICES
可能会消耗事件
(2) 事件
UI
发送HTTP
请求到GATEWAY
GATEWAY
已将活动发布到QUEUE
μSERVICE A
消耗事件- 事件存储在
EVENT STORE
并发布到QUEUE
PROJECTION DATABASE
已更新- 其他
μSERVICES
可能会消耗事件 GATEWAY
消费事件并将响应(SUCCESS
或ERROR
)发送到UI
如果我误解了一些概念,我真的很抱歉,我对这种架构风格比较陌生。
在此先感谢您的帮助! :)
第二种方法是首选方法并且是异步方法。
直接
首先,您的 microsvc B 和 C 等待事件发布。这个系统的可扩展性直接依赖于 microsvc A。如果 microsvc A 宕机或落后于写入事件到队列怎么办?这就像单点故障和瓶颈。您无法轻松扩展系统。
事件
在微服务中,我们保持系统异步,以便它们可以扩展。 网关应该使用 pub/sub 写入队列,所有这些微服务都可以同时使用事件。总体而言,系统更强大并且可以扩展。