21

マイクロサービス アーキテクチャのコンテキストでは、同期(おそらくRESTベース）メカニズム。

以下に示すように、そのコンテキストを使用して、非常に単純化された注文システムを想像してください。

注文システム

および次のメッセージ フロー:

  • 注文は何らかのソース (Web/モバイルなど) から行われます。
  • 注文サービスは注文を受け付け、CreateOrderEvent
  • InventoryService は に反応し、CreateOrderEventいくつかの在庫作業を行い、完了したら を発行しInventoryUpdatedEventます。
  • 次に、Invoice サービスは に反応しInventoryUpdatedEvent、請求書を送信して、EmailInvoiceEvent

すべてのサービスが稼働しており、喜んで注文を処理しています。誰もが満足しています。その後、Inventory サービスが何らかの理由でダウンします

イベントバス上のイベントが「ノンブロッキング」方式で流れていると仮定します。つまり、メッセージは中央のトピックに発行されており、サービスがそれから読み取られていない場合はキューに積み上げられません (私が伝えようとしているのはイベントバスです。イベントがバスで発行された場合、それはこの時点で使用されているメッセージング プラットフォーム/テクノロジは無視してください)。これは、Inventory サービスが 5 分間ダウンした場合、CreateOrderEventその間にイベント バスを通過する が「なくなった」か、Inventory サービスに表示されないことを意味します。それらのイベント。

私の質問は次のとおりです: 在庫サービス (およびシステム全体) は、どのようにして注文が取りこぼされたり処理されなかったりしないように状態を復元しますか?

4

3 に答える 3

11

良い質問！したがって、ここでは基本的に 3 つの力が働いています。

  1. サービスがダウンした場合、見逃した可能性のあるイベントを再生して一貫性を保つ必要があります
  2. 「時間」内に発生するイベントには、「これはその前に発生した」という順序があります。
  3. 特定の状態が達成されることを確認するために、一連のイベントを監視することに関心のある別の当事者が存在する可能性があります (ただし、存在する必要はありません)。

#1 と #2 の両方で、ある種の永続的なイベント ログが必要です。従来のメッセージ キュー/トピックはこれを提供する場合がありますが、メッセージがトランザクション/例外/障害の動作に関して順不同で処理される可能性がある場合を考慮する必要があります。Apache Bookkeeper、Apache Kafka、AWS Kinesis などのより単純なログは、これらのタイプのイベントを順番に保存/保持し、コンシューマーに任せて順番に処理/重複を除外/パーティション ストリームなどを行うことができます。

私にとって3番目はステートマシンです。ただし、ステートマシンを実装するかどうかはあなた次第です。基本的に、このステート マシンは、他のシステムのイベントに基づいて、発生したイベントと許可された状態への遷移 (および潜在的にイベント/コマンドの発行に参加する) を追跡します。

たとえば、実際のユースケースは、家を閉めようとしているときの「エスクロー」のように見えるかもしれません。エスクロー会社は金融取引を処理するだけでなく、通常、不動産業者と協力して書類の手配、書類への署名、送金などを調整します。各イベントの後、エスクローは「買い手の署名待ち」から状態を変更します。 「売り手の署名を待っている」から「資金を待っている」から「クローズされた成功」まで…これらのイベントが発生するまでの期限さえあります。未完成」とか。

この例のステート マシンは、pub/sub チャネルでリッスンし、この状態をキャプチャし、タイマーを実行し、関連するシステムをさらに進めるために他のイベントを発行します。進行し、必要に応じてタイムアウトと補償を実施します。これは、ストリーム プロセッサ、プロセス エンジン、または単純な「エスクロー」サービスとして実装できます。

実際には、「エスクロー」サービスがダウン/失敗した場合に何が起こるか、重複をどのように処理するか、状態に応じて予期しないイベントをどのように処理するか、イベントの重複にどのように寄与するかなど、追跡する必要があるものは他にもあります...しかしうまくいけば、始めるのに十分です。

于 2016-06-10T20:05:10.390 に答える
2

詳細にドリルダウンするのではなく、アーキテクトの回答を提供します。気にしないでください。

最初の提案は、すべての概念 (イベント、メッセージ、バス、キュー、および非同期) を切り離すことです。バスの実装に使用するソフトウェアをまだ決定していない場合は、これによって可能性が広がります。

アーキテクチャの観点から、「配信する必要がある」タイプのシナリオが必要な場合は、サービスが失敗したときにメッセージを永続化します。はい、問題が発生すると、システムで何らかのクリーンアップが必要になる可能性がありますが、最初に保証された配信の問題に焦点を当てます. 拡張可能な 2 つの基本的なオプションがすぐに見つかります (他にもある可能性がありますが、問題について考え始めるにはこれらで十分です)。

  • インベントリ サービスは、キューからのメッセージのプルを処理します。このメソッドでは、サービスがスピンアップしてメッセージを見つけます。
  • 「バス」は配達を保証します。障害が発生した場合、サービスがバックアップされるまで待機します (ping を実行して、サービスが再びアップするか、サービスがサブスクライバーとして再登録できるかを確認できます (エンタープライズ サービス バス タイプのシナリオ)。

システムが非同期でイベント ベースであるからといって、ある種の保証付き配信を実装できないわけではありません。キューはオプションですが (このアイデアを破棄するようですか?)、障害が発生しても持続し、サブスクライバーが再び立ち上がったときに再試行するバスは別のものです。また、ブロックせずに持続できます。

もう 1 つの問題は、メッセージを手元のビジネス機能に同期させるためにメッセージが使用するトークンですが、これはシステムで何らかの形で処理されていると思います。あなたが持っていないかもしれない唯一の概念は、すべてのシステムがトークンを尊重し、失敗した場合にメッセージを返す際に他のシステムを尊重することです。

ビジネスの観点から見た非同期通信は、接点でのファイア アンド フォーゲットを意味するものではないことに注意してください。情報のすべてのビットに対して非同期メソッドを使用しなくても、メッセージを返すことができます。ここで私が言いたいのは、起動中の在庫システムがメッセージを処理し、UI 側でアプリケーションに送信する可能性があり、「忘れてください。遅すぎた」というメッセージが返される可能性があるため、トランザクションは元の状態 (存在しない?) に戻るということです。 .

詳細がまだ少し高すぎるため、アーキテクチャに最適な方法を提案するのに十分な情報 (または時間?) がありませんが、これがいくつかの考えをかき立てることを願っています.

私は基本的にADHD状態で脳からキーボードへの操作を行ったので、これが理にかなっていることを願っています. ;-)

于 2016-06-10T18:15:09.530 に答える
-1

まず第一に、私たちが構築しているシステムには目的があります。通常、顧客を満足させて戻ってくることで収益と利益を増やすことです。そのため、顧客の行動から発生したメッセージ/イベントを処理する必要があります (問題の会社が顧客体験を優先していると仮定して..それにお金を投資する意思があるとします)。

ところで、顧客と企業の関係は、社内の他のすべての関係とは異なり、システム全体で緊密に結合したい関係です。したがって、これらの場合、それは自律性ではなく「権限」の例です。ブランドに代表されるSLAを保証します。

ただし、メッセージの重要度の範囲は、優先順位を反映するのではなく、「配信する必要がある」かどうかよりもきめ細かくする必要があります。機能がよりきめ細かくなるのと同様 (マイクロサービス)。これについては後で詳しく

したがって、メッセージ/イベントがサブスクライバーによって確実に処理されるようにするという目標は、サービスがダウンしないようにすること (MS Orleans の「仮想アクター」の概念など) によって達成するか、配信メカニズムにエラー処理ロジックを追加することによって達成できます。

後者のオプションは、自律的/分離型ではなく、集中型/結合型のようです。ただし、サービスが常に利用可能であるとは限らないと想定している場合は (当然のことですが)、「一時的な」メッセージに関する他の想定を取り除くことを検討する必要があります。

最初のオプションでは、サービスの可用性を保証する方法の決定は、サービスを所有するアジャイル チームに委ねられますが、パフォーマンスは出力メトリックによって測定されます。

さらに、カプセル化された機能としてのサービスが高いサービス レベル (「停止しない」) を保証する場合、システム全体 (= エンタープライズ) の結果の制御は、メッセージの優先度を調整し、新しいサービスとイベントをシステムに注入することによって、継続的に適応させることができます。システム。

もう 1 つの重要な側面は、同期アーキテクチャ (= コール スタック ベース) が、非同期アーキテクチャ (イベント駆動型) が依存関係の削減のために示さない 3 つの機能を提供するという事実です。コール スタック」、2006 年）。

これらの機能は、ビジネス レベルで顧客にまだ必要であるため、他の場所でカバーする必要があります。Hohpe は、疎結合システムの動作の構成と監視には、中核となるビジネス機能 (イベント間の関係を理解するための複雑なイベント処理) と同じくらい重要な追加のコード層が必要であると示唆しています。

大量のデータ、さまざまな速度、構造、および正確性レベルを処理する必要があるこれらの最新の CEP システムは、最新のデータ処理およびビッグデータ システム (Spark など) の上に実装され、両方によって理解、意思決定、および最適化に使用される可能性があります。アジャイルチーム（サービスを改善するため）と管理チームのレベル。

于 2016-07-17T12:00:22.807 に答える