10

外部APIサービスからオンデマンドで受注するオークションクラウドサービスを実装しています。受け取った各注文は、オークションに対して 1 対 1 で行われます。

1 日あたり 2000 件以上の注文 (オークション) を処理できます。マイクロサービス+ Reduxを使用して、注文とオークションを分離することにしました。

以下、各サービスの説明です。

外部 API

Enternal API は、注文を注文サービスにプッシュし、注文サービスからの更新を受信するWeb サイトにすぎません。これを制御することはできません。

オーダーサービス

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 - LOAD_ORDERS を介して注文サービスへのその日の外部 APIプッシュ注文も、各注文のオークションを作成するために CREATE_AUCTIONS アクションがアクション サービスにディスパッチされます。

2 - ユーザーがモバイルアプリを開き、その日の注文のリストと注文サービスからのオープン価格を含む詳細を取得します。

3 - ユーザーが特定の注文に参加 - API サービスは、入札を行うビッダーエージェントを作成します。- API サービスは、JOIN_AUCTION を介して参加アクションを送信し、オークション サービスのオークションに参加します。

4 -競売人エージェントがオークションを開始し、入札が開始されます。

5 - 参加した入札者エージェントは、オークション サービスの PLACE_BID アクションを介して入札を開始します。

6 - オークションが終了すると、競売人エージェントは END_AUCTION をディスパッチしてオークションを終了します。

7 - オークションが終了すると、販売価格とオークションの詳細 (オブジェクト経由) がSET_ORDER_AUCTION 経由で注文サービスに送信されます。

8 - Order Serviceは SET_ORDER_AUCTION を処理し、最終的なsalePriceとオークションオブジェクトで注文状態を更新してから、支払いを待ちます。

9 - クライアントから支払い情報を受け取ると、オーダー サービスによって外部サービスに送信されます。

私の質問は次のとおりです。

  • 上記のワークフローは、マイクロサービス + Redux を使用して各サービスの状態を更新するための合理的なアプローチですか?

  • redux マイクロサービスを使用する場合、マイクロサービスから別のマイクロサービスにアクションをディスパッチしても問題ありませんか? 私の質問は、マイクロサービス + イベント ソーシング + CQRS を使用する場合、サービス相互通信は推奨されず、代わりにイベントをコマンドに変換する中間サービスとして機能する Sagas を使用するためです。

  • 私のもう 1 つの質問は、ビジネス ロジック (検証) をどこに置くかということです。たとえば、オークションが開始されていないか、既に終了している場合、入札者は入札を送信できません。また、オークションに参加していない場合、入札者は入札を送信できません。このロジックを置くことでしたか？実際に、ミドルウェアまたはレデューサーですか? また、クライアントに返されるエラーを処理する方法は?

  • 一般的に、マイクロサービス + Redux に関するベスト プラクティスは何ですか?

  • Microservices + Redux vs Microservices + Event sourcing + CQRSを使用することの長所と短所は何ですか?

長い投稿で申し訳ありませんが、このトピックに関するドキュメントが見つからず、この権利に近づいているかどうかわからないため、ここでオリエンテーションが必要です。

アドバイスをいただければ幸いです!!!

4

1 に答える 1