硬件故障和服务间通信的 Saga 模式
Saga Pattern on hardware failure and inter services communication
我正在构建一个 Spring 引导微服务应用程序。我打算采用 Saga 模式来解决分布式事务问题。以下是我面临的问题列表。
为了便于说明，这里是上下文。
客户端 -> 服务 A -> 服务 B
- 处理因失败而导致的非活动微服务
- 假设服务B由于硬件/软件故障不存活，A应该如何反应？
- 异步通信
- 建议我们对saga模式进行异步通信。假设那段时间是client -> A < A -> B，那之后Client是如何接收到A从B处接收到的数据的呢？是不是 A 必须 return 一个 Async 对象返回给客户端？像 CompletableFuture class?
这样的东西
- 服务从其他服务请求资源。
- 假设服务 A 需要向服务 B 请求一些资源，A 应该怎么做呢？我能想到的就是使用 HTTP / gRPC（消除了来自消息代理的通信）。
- 如果您碰巧有一些经验/建议，请分享:)
如有任何关于 Saga 模式的帮助或建议，我们将不胜感激！
SAGA用于分布式事务。它可以通过使用 Orchestration 或 Choreography based 来实现。它主要（更喜欢）通过使用异步通信方式实现。 Message Broker 在这里起着重要的作用。
有很多查询。让我尝试回答这些问题。
- 如果一项服务出现故障 - 您可以为 SAGA 设置一个监控系统。如果任何服务关闭或 SAGA 在某个阈值时间内未处理，则您可以发出警报。
- Async Communication - 它主要用于处理一些命令（不是查询）。每当客户端调用服务 A 时，它都会启动 SAGA 并回复当前状态。它还 return 一个 id（你可以说工作 id）。现在有两种方式可以让客户端获得更新的状态。一个是轮询（客户端在 N 秒后请求状态更新），第二个是推送（服务器在状态发生变化时推送更改。）
- 来自其他服务请求资源 - 是的，首选方式是 REST 或 gRPC。此外，如果数据是常量类型，则可以使用缓存。
建议 - SRE（监控等）在微服务架构中扮演着重要的角色。因此，如果您设置得很好，那么您可以轻松应对微服务的其他挑战。
我正在构建一个 Spring 引导微服务应用程序。我打算采用 Saga 模式来解决分布式事务问题。以下是我面临的问题列表。
为了便于说明，这里是上下文。
客户端 -> 服务 A -> 服务 B
- 处理因失败而导致的非活动微服务
- 假设服务B由于硬件/软件故障不存活，A应该如何反应？
- 异步通信
- 建议我们对saga模式进行异步通信。假设那段时间是client -> A < A -> B，那之后Client是如何接收到A从B处接收到的数据的呢？是不是 A 必须 return 一个 Async 对象返回给客户端？像 CompletableFuture class? 这样的东西
- 服务从其他服务请求资源。
- 假设服务 A 需要向服务 B 请求一些资源，A 应该怎么做呢？我能想到的就是使用 HTTP / gRPC（消除了来自消息代理的通信）。
- 如果您碰巧有一些经验/建议，请分享:)
如有任何关于 Saga 模式的帮助或建议，我们将不胜感激！
SAGA用于分布式事务。它可以通过使用 Orchestration 或 Choreography based 来实现。它主要（更喜欢）通过使用异步通信方式实现。 Message Broker 在这里起着重要的作用。
有很多查询。让我尝试回答这些问题。
- 如果一项服务出现故障 - 您可以为 SAGA 设置一个监控系统。如果任何服务关闭或 SAGA 在某个阈值时间内未处理，则您可以发出警报。
- Async Communication - 它主要用于处理一些命令（不是查询）。每当客户端调用服务 A 时，它都会启动 SAGA 并回复当前状态。它还 return 一个 id（你可以说工作 id）。现在有两种方式可以让客户端获得更新的状态。一个是轮询（客户端在 N 秒后请求状态更新），第二个是推送（服务器在状态发生变化时推送更改。）
- 来自其他服务请求资源 - 是的，首选方式是 REST 或 gRPC。此外，如果数据是常量类型，则可以使用缓存。
建议 - SRE（监控等）在微服务架构中扮演着重要的角色。因此，如果您设置得很好，那么您可以轻松应对微服务的其他挑战。