redux - 如何实现 Redux + 微服务互通

Question

我们正在实现一个拍卖云服务，它将接收来自 外部 API 服务 的 订单 。每个收到的订单都是 1:1 到拍卖 。

我们每天可以有超过 2000 个订单(拍卖) 。
我们决定使用 微服务 + Redux 来分离订单和拍卖之间的关注点。

以下是对各项服务的说明。

外部 API

Enternal API 只是一个将订单推送到我们的 订单服务 并从我们的 订单服务 接收更新的网站，我们无法控制它。

订购服务

订单有一堆信息(属性)，客户端(移动应用程序)使用这些信息来获取信息来决定参加拍卖。例如，这就是订单的样子:

{
  id: 123,
  description: 'Some description',
  salePrice: 0,
  minPrice: 1000,
  openPrice: 500,
  status: 'active',
  address: 'Some address',
  file: '.../some-file.pdf',
  client: 'Joe Doe',
  notes: 'Some notes',
  createdAt: '12345678',
  pending: false,
  postpone: false,
  ...moreproperties
}

在订单服务中， 订单 可以在拍卖开始前 通过 操作_0x10956 _0x10456 _0x10456 _0x10456 随时由服务器随时更新(地址、名称、开盘价、minPrice、状态等)。

{ type: LOAD_ORDERS, orders }
{ type: PEND_ORDER, id }
{ type: POSTPONE_ORDER, id }
{ type: SET_ORDER_AUCTION, id, auction, salePrice }
{ type: UPDATE_ORDER, id, properties }

拍卖服务

此服务中的拍卖对象可能如下所示:

{
  id: 'abcd',
  orderId: 123456,
  increment: 1,
  outBid: { agentId: 'b1', price: 545 },
  bestBid:{agentId: 'b2', price: 550 },
  openPrice: 500,
  currentPrice: 550,
  status: 'started'
  startedByAgent: 'a1'
}

可以通过以下操作更新拍卖:

{ type: JOIN_AUCTION, id, agentId, type }
{ type: START_AUCTION, id, agentId }
{ type: PLACE_BID, id, agentId, price }
{ type: END_AUCTION, id, agentId }

API 服务

它就像前端应用程序和微服务之间的网关。以 Action 的形式接收和发送来自客户(手机)的请求到 Order Service 或 Auction Service 。

工作流程:

1 - 外部 API 将当天的订单推送到 订单服务 通过 LOAD_ORDERS 还将 CREATE_AUCTIONS 操作分派(dispatch)给 Action _0x1097204 的每个订单，以创建拍卖服务 _0x1094045。

2 - 用户打开移动应用程序并从 订单服务 获取包含详细信息的当天订单列表。

3 - 用户加入特定订单
- API 服务 创建了一个 投标人 代理，用于投标。
- API 服务 通过 JOIN_AUCTION 发送加入操作以加入 拍卖服务 上的拍卖

4 - 拍卖师 代理开始拍卖并开始出价。

5 - 加入 投标人 代理开始通过 PLACE_BID 操作对 拍卖服务 进行投标。

6 - 当拍卖结束时， 拍卖师 代理通过发送 END_AUCTION 结束拍卖。

7 - 当拍卖结束时，销售价格和拍卖详细信息(通过对象)通过 SET_ORDER_AUCTION 发送到 订单服务 。

8 - 订单服务 处理 SET_ORDER_AUCTION 并使用最终的 salePrice 和 付款对象更新订单状态，然后等待拍卖对象 20404056

9 - 一旦收到客户的付款信息，就会由 订单服务 将其提交给 外部服务

我的问题是:

上面的工作流是使用微服务 + Redux 并更新每个服务状态的合理方法吗？

使用 redux 微服务时可以将 Action 从一个微服务分派(dispatch)到另一个微服务吗？我的问题是因为在使用微服务 + 事件溯源 + CQRS 时，不推荐服务互通，而是使用作为将事件转换为命令的中间服务的 Sagas。

我的另一个问题是将业务逻辑(验证)放在哪里，例如，如果拍卖未开始或已经结束，则投标人无法发送出价，如果投标人尚未加入拍卖，则无法发送出价。是把这个逻辑？在行动中，中间件还是 reducer ？以及如何处理返回给客户的错误？

一般而言，微服务 + Redux 有哪些最佳实践？

使用 微服务 + Redux 与 微服务 + 事件溯源 + CQRS 的优缺点是什么？

很抱歉这篇长文章，我只需要在这里介绍一下，因为我找不到关于这个主题的任何文档，我不确定我是否正在接近这个问题。

任何意见，将不胜感激!!!

Answer 1

我认为这个问题与指导方针相去甚远。

尽管如此，我还是会说编写您自己的 redux 中间件来集成您的微服务； API 非常简单:

store => next => action => {
  let result = next(action)
  return result
}

在最外层的函数( store => )中，您可以通过存储引用添加微服务监听器和分派(dispatch) Action 。
在最里面的函数 ( action => ) 中，您可以通过向微服务发送请求来对 redux 应用程序中的操作使用react。