如何接近Redux+；微服务互通

我们正在实施一项拍卖云服务，该服务将根据需求从外部API服务接收订单。每个收到的订单都是拍卖的1:1

我们每天可以有超过2000个订单（拍卖）。 我们决定使用微服务+Redux来区分订单和拍卖之间的关系

下面是每项服务的说明

外部API

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

订购服务

Orders有一系列信息（属性），客户端（移动应用程序）使用这些信息获取信息，以决定是否加入拍卖。例如，订单可以是这样的：

{
  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
}

在订单服务中，服务器可以在拍卖开始前的任何时间通过下面的操作更新订单（地址、名称、openPrice、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服务

它就像前端应用程序和微服务之间的网关。以行动的形式接收和发送客户（手机）的请求到订单服务或拍卖服务

工作流：

1-外部API通过加载订单将当天的订单推送到订单服务，同时向操作服务发送创建拍卖操作，为每个订单创建拍卖

2-用户打开移动应用程序，从订单服务获取当天的订单列表，包括开盘价格

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

3-用户加入特定订单 -API服务创建一个将进行投标的投标人代理。 -API服务通过加入拍卖发送加入动作，加入拍卖服务上的拍卖

4-拍卖师开始拍卖，开始竞价

5-加入的投标人代理开始通过拍卖服务上的place_出价动作进行出价

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

6-拍卖结束后，拍卖商代理人通过发送END_拍卖结束拍卖

7-当拍卖结束时，通过SET_Order_拍卖将销售价格和拍卖详情（通过object）发送到订单服务

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

9-从客户处收到付款信息后，通过订单服务提交给外部服务

我的问题是：

• 上述工作流是否是使用MicroService+Redux和更新每个服务状态的合理方法

• 使用redux微服务时，可以将操作从一个微服务分派到另一个微服务吗？我的问题是，当使用微服务+事件源+CQR时，不建议使用服务内部通信，而是使用Sagas作为将事件转换为命令的中间服务

• 我的另一个问题是将业务逻辑（验证）放在何处，例如，如果拍卖尚未开始或已经结束，则投标人无法发送投标；如果投标人尚未加入拍卖，则投标人无法发送投标。我们应该把这个逻辑放在哪里？在实际操作中，是中间件还是还原器？以及如何将错误处理回客户端

• 一般来说，当涉及到微服务+Redux时，有哪些最佳实践

• 使用微服务+Redux与微服务+事件源+CQR的优缺点是什么

很抱歉，这篇文章太长了，我只需要在这里做一些介绍，因为我找不到关于这个主题的任何文档，我不确定我是否正确地处理了这个问题

---

任何建议都将不胜感激

我认为这些问题偏离了指导原则

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

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

在most外部函数（

store=>

）中，您可以通过store引用添加microservice listerner和分派操作。

---

在最里面的函数（

action=>

）中，您可以通过向微服务发送请求来对redux应用程序中的操作做出反应。

这是如何实现的？？