マイクロサービスのオーケストレーションの標準パターンは何ですか？
マイクロサービスが自身のドメインのみを認識しているが、複数のサービスが何らかの方法で相互作用することを必要とするデータの流れがある場合、それについてどうするのですか？
次のようなものがあるとします。
そして議論のために、注文が発送されたら、請求書を作成する必要があるとしましょう。
どこかで、誰かがのボタンを押したGUI、「完了しました、これをやりましょう！」古典的なモノリスサービスアーキテクチャでは、これをESB処理するか、出荷サービスが請求書サービスの知識を持っていて、それを呼び出すだけだと思います。
しかし、人々がこの勇敢な新しいマイクロサービスの世界でこれに対処する方法は何ですか？
これは非常に意見に基づいたものと考えることができると思います。しかし、マイクロサービスは上記を行うことを想定していないため、具体的な側面があります。したがって、意見に基づくものではない「定義上、代わりに何をすべきか」が必要です。
シュート。
回答:
Book Buildingマイクロサービスは、@ RogerAlsingが彼の回答で述べたスタイルを詳細に説明しています。
43ページの「オーケストレーションvsコレオグラフィー」で、この本はこう書いています：
ますます複雑なロジックのモデリングを開始するにつれ、個々のサービスの境界にまたがるビジネスプロセスの管理の問題に対処する必要があります。マイクロサービスを使用すると、通常より早くこの制限に達します。[...]このフローを実際に実装することになると、従うことができるアーキテクチャの2つのスタイルがあります。オーケストレーションでは、オーケストラの指揮者のように、中央の脳を使用してプロセスをガイドおよび駆動します。振付では、システムの各部分にその仕事を通知し、ダンサー全員が自分の道を見つけ、バレエの周りの他の人に反応するように、詳細を計算させます。
次に、本は2つのスタイルを説明します。オーケストレーションスタイルは、オーケストレーション/タスクサービスというSOAのアイデアにより対応していますが、コレオグラフィスタイルは、Martin Fowlerの記事で言及されているダムパイプとスマートエンドポイントに対応しています。
オーケストレーションスタイル
このスタイルで、上記の本は次のように述べています：
このフローのオーケストレーションソリューションがどのようになるかを考えてみましょう。ここで、おそらく最も簡単なことは、カスタマーサービスを中心的な脳として機能させることです。作成時には、一連のリクエスト/レスポンスコールを通じて、ポイントポイントの銀行、メールサービス、郵便サービスと通信します[...]。その後、顧客サービス自体が、顧客がこのプロセスのどこにいるかを追跡できます。お客様のアカウントが設定されているか、メールが送信されているか、投稿が配信されているかを確認できます。フローチャート[...]を取得して、コードに直接モデル化します。これを実装するツールを使用して、適切なルールエンジンを使用することもできます。ビジネスプロセスモデリングソフトウェアの形で、まさにこの目的のための商用ツールが存在します。同期リクエスト/レスポンスを使用すると仮定すると、各段階が機能しているかどうかを知ることもできます[...]このオーケストレーションアプローチの欠点は、カスタマーサービスが中央の統治機関になりすぎる可能性があることです。これは、Webの真ん中のハブになり、ロジックが機能し始める中心点になります。このアプローチの結果、少数のスマートな「神」サービスが貧血のCRUDベースのサービスに何をすべきかを指示するのを見てきました。
注：著者がツールについて言及するとき、彼はBPMのようなもの（例：Activity、Apache ODE、Camunda）について言及していると思います。実際のところ、Workflow Patterns Webサイトには、この種のオーケストレーションを行うための素晴らしい一連のパターンがあり、この方法での実装に役立つさまざまなベンダーツールの評価の詳細も提供されています。著者がこれらのツールのいずれかを使用してこの統合スタイルを実装する必要があることを示唆しているとは思わないが、他の軽量オーケストレーションフレームワーク、たとえばSpring Integration、Apache CamelまたはMule ESBを使用することもできる
ただし、マイクロサービスのトピックについて私が読んだ他の本、および一般にWebで見つけた記事の大部分は、このオーケストレーションのアプローチを嫌い、代わりに次のものを使用することを提案しているようです。
振付スタイル
振付スタイルの下で著者は言う：
振り付けのアプローチでは、代わりに、カスタマーサービスが非同期でイベントを発行するようにできます。次に、電子メールサービス、郵便サービス、およびポイントサーバーは、これらのイベントをサブスクライブし、それに応じて対応します[...]このアプローチは、さらに分離されています。他のサービスが顧客の作成に到達する必要がある場合は、イベントをサブスクライブし、必要に応じてその仕事を行うだけです。欠点は、[ワークフロー]に表示されるビジネスプロセスの明示的なビューが暗黙的にシステムにのみ反映されることです[...]これは、適切なものがあることを監視および追跡できるようにするために追加の作業が必要であることを意味します起こりました。例えば、ポイントポイントの銀行にバグがあり、何らかの理由で正しいアカウントが設定されなかったかどうかを知っていますか？これに対処するために私が好む1つのアプローチは、[ワークフロー]のビジネスプロセスのビューに明示的に一致する監視システムを構築することですが、各サービスが独立したエンティティとして実行することを追跡し、奇数の例外がより明示的なプロセスフロー。[フローチャート] [...]は駆動力ではなく、システムの動作を確認できる1つのレンズです。一般に、振付アプローチに向かう傾向のあるシステムは、より疎結合であり、より柔軟で変更が可能であることを発見しました。ただし、システムの境界を越えてプロセスを監視および追跡するには、追加の作業を行う必要があります。最も調整が進んだ実装は非常に壊れやすく、変更のコストが高くなることがわかりました。それを念頭に置いて、各サービスがダンス全体での役割を理解するのに十分なほど賢い振付システムを目指すことを強く好みます。
注：今日まで、コレオグラフィーがイベント駆動型アーキテクチャー（EDA）の別名にすぎないかどうかはまだわかりませんが、EDAがその1つの方法に過ぎない場合、他の方法は何ですか？（も参照してくださいあなたは、「イベントドリブン」とはどういう意味ですか？とイベント駆動型アーキテクチャの意味）。また、CQRSやEventSourcingのようなものは、このアーキテクチャスタイルに大きく共鳴しているようですね。
さて、これからが楽しみです。マイクロサービスの本は、マイクロサービスがRESTで実装されることを想定していません。本の次のセクションの実際の問題として、彼らはRPCとSOAベースのソリューションを検討し、最後にRESTを検討します。ここで重要な点は、マイクロサービスはRESTを意味しないということです。
それで、HATEOASはどうですか？ （アプリケーション状態のエンジンとしてのハイパーメディア）
RESTfulなアプローチを採用したい場合、HATEOASを無視することはできません。RoyFieldingは彼のブログで、私たちのソリューションが本当にRESTではないことを非常に喜んで言っています。REST APIに関する彼のブログ投稿を参照してください。ハイパーテキスト駆動である必要があります。
HTTPベースのインターフェースをREST APIと呼ぶ人々の数に不満を感じています。ハイパーテキストが制約であるという概念でRESTアーキテクチャスタイルを明確にするために何をする必要がありますか？言い換えると、アプリケーション状態のエンジン（つまりAPI）がハイパーテキストによって駆動されていない場合、RESTfulにすることもREST APIにすることもできません。限目。どこかに修正が必要な壊れたマニュアルはありますか？
ご覧のとおり、FieldingはHATEOASなしではRESTfulアプリケーションを本当に構築していないと考えています。フィールディングにとって、HATEOASは、サービスのオーケストレーションについての道のりです。私はこれらすべてを学んでいるだけですが、HATEOASは実際にリンクをたどる背後にある原動力は誰であるか、または何であるかを明確に定義していません。ユーザーの可能性があるUIでも、コンピューター間の対話では、より高いレベルのサービスで実行する必要があると思います。
HATEOASによると、APIコンシューマが本当に知る必要がある唯一のリンクは、サーバーとの通信を開始するものです（例：POST / order）。この時点から、RESTはフローを実行します。これは、このエンドポイントの応答で、返されるリソースに次の可能な状態へのリンクが含まれるためです。次に、APIコンシューマーはどのリンクをたどるかを決定し、アプリケーションを次の状態に移行します。
それがいかにクールに聞こえても、クライアントはリンクがPOSTされ、PUTされ、GETされ、PATCHされる必要があるかどうかを知る必要があります。また、クライアントは渡すペイロードを決定する必要があります。それでもクライアントは、失敗した場合の対処方法（再試行、補正、キャンセルなど）を認識する必要があります。
私はこれらすべてにかなり慣れていませんが、HATEOAの観点から見ると、このクライアントまたはAPIコンシューマーは高次のサービスです。人間の観点から考えると、Webページのエンドユーザーがどのリンクをたどるかを想像できますが、それでも、Webページのプログラマーは、リンクを呼び出すために使用する方法を決定する必要がありました。渡すペイロード。つまり、私の指摘では、コンピュータ間の相互作用では、コンピュータがエンドユーザーの役割を果たします。もう一度、これをオーケストレーションサービスと呼びます。
HATEOASはオーケストレーションまたは振付のどちらでも使用できると思います。
APIゲートウェイパターン
別の興味深いパターンが、API Gatewayパターンと呼ばれるものを提案したChris Richardsonによって提案されています。
モノリシックアーキテクチャでは、Webブラウザやネイティブアプリケーションなどのアプリケーションのクライアントが、ロードバランサを介して、アプリケーションの同一のインスタンスの1つにHTTPリクエストを送信します。しかし、マイクロサービスアーキテクチャでは、モノリスはサービスのコレクションに置き換えられました。したがって、私たちが回答する必要がある重要な質問は、クライアントが何と対話するかです。
ネイティブモバイルアプリケーションなどのアプリケーションクライアントは、個々のサービスに対してRESTful HTTPリクエストを作成できます[...]表面的には、これは魅力的に思えるかもしれません。ただし、個々のサービスのAPIとクライアントが必要とするデータとの間には、細分性に大きなミスマッチがある可能性があります。たとえば、1つのWebページを表示するには、多数のサービスの呼び出しが必要になる可能性があります。たとえば、Amazon.comは、 一部のページが100以上のサービスへの呼び出しを必要とする方法を説明しています。高速インターネット接続であっても、それだけ多くの要求を行うと、低帯域幅で待機時間が長いモバイルネットワークはもちろん、非常に非効率になり、ユーザーエクスペリエンスが低下します。
はるかに優れたアプローチは、クライアントがページごとに少数のリクエスト（おそらく1つ）を、インターネット経由でAPIゲートウェイと呼ばれるフロントエンドサーバーに要求することです。
APIゲートウェイは、アプリケーションのクライアントとマイクロサービスの間にあります。クライアントに合わせたAPIを提供します。APIゲートウェイは、モバイルクライアントに粗粒度のAPIを提供し、高性能ネットワークを使用するデスクトップクライアントに細粒度のAPIを提供します。この例では、デスクトップクライアントは製品に関する情報を取得するために複数の要求を行いますが、モバイルクライアントは単一の要求を行います。
APIゲートウェイは、高性能LAN経由でいくつかのマイクロサービスにリクエストを送信することにより、着信リクエストを処理します。たとえば、Netflixは、 各リクエストが平均して6つのバックエンドサービスにファンアウトする方法を説明しています。この例では、デスクトップクライアントからのきめ細かいリクエストは対応するサービスにプロキシされるだけですが、モバイルクライアントからのきめ細かいリクエストはそれぞれ、複数のサービスを呼び出した結果を集約することによって処理されます。
APIゲートウェイはクライアントとアプリケーション間の通信を最適化するだけでなく、マイクロサービスの詳細もカプセル化します。これにより、クライアントに影響を与えることなくマイクロサービスを進化させることができます。たとえば、2つのマイクロサービスがマージされる場合があります。別のマイクロサービスが2つ以上のサービスに分割されている可能性があります。これらの変更を反映するには、APIゲートウェイのみを更新する必要があります。クライアントは影響を受けません。
APIゲートウェイがアプリケーションとそのクライアントの間で仲介する方法を確認したので、マイクロサービス間の通信を実装する方法を見てみましょう。
これは、上記のオーケストレーションスタイルに非常に似ていますが、意図が少し異なります。この場合、パフォーマンスとインタラクションの簡素化がすべてのようです。
ここでさまざまなアプローチを集約しようとしています。
これに対する主なアプローチはドメインイベントを使用しているようです。各サービスは発生したイベントに関するイベントを発行し、他のサービスはそれらのイベントにサブスクライブできます。これは、Martin Fowlerがhttp://martinfowler.com/articles/microservices.html#SmartEndpointsAndDumbPipesで説明しているスマートエンドポイント、ダムパイプの概念と連動しているようです。
一般的に思われるもう1つのアプローチは、ビジネスフローを独自のサービスにラップすることです。次の図に示すように、プロキシがマイクロサービス間の相互作用を調整する場所：
。
このページには、さまざまな構成パターンが含まれています。
では、マイクロサービスのオーケストレーションは、「マイクロ」ではない古いSOAサービスのオーケストレーションとどう違うのでしょうか。それほど多くはありません。
マイクロサービスは通常、http（REST）またはメッセージング/イベントを使用して通信します。オーケストレーションは、多くの場合、オーケストレーションプラットフォームに関連付けられており、サービス間のスクリプト化された相互作用を作成してワークフローを自動化できます。SOAの昔は、これらのプラットフォームはWS-BPELを使用していました。今日のツールはBPELを使用しません。最新のオーケストレーション製品の例：Netflix Conductor、Camunda、Zeebe、Azure Logic Apps、Baker。
オーケストレーションは、サービスの複雑な構成を作成するためのいくつかの機能を提供する複合パターンであることを覚えておいてください。マイクロサービスは、多くの場合、複雑な構成に参加してはならず、より自律的なサービスとして見なされます。
マイクロサービスがオーケストレーションされたワークフローで呼び出されて簡単な処理を実行しているのを確認できますが、マイクロサービスがオーケストレーターサービスであることはわかりません。
つまり、2つのサービスがあります。
実際には、注文状態を保持するものがあります。それを注文サービスと呼びましょう。次に、注文処理のユースケースがあります。これは、注文がある状態から別の状態に遷移したときに何をすべきかを知っています。これらのすべてのサービスには特定のデータセットが含まれており、すべての調整を行う別のサービスが必要です。これは：
これの主なポイントは、コントロールが外部であることです。これは、すべてのアプリケーションコンポーネントが疎結合の個別のビルディングブロックであるためです。ユースケースが変更された場合、オーケストレーションコンポーネントである1つのコンポーネントを1か所で変更する必要があります。別の注文フローを追加すると、最初のオーケストレーターを妨害しない別のオーケストレーターを簡単に追加できます。マイクロサービスの考え方は、スケーラビリティと豪華なREST APIの実行だけでなく、明確な構造、コンポーネント間の依存関係の削減、ビジネス全体で共有される共通のデータと機能の再利用についても考慮します。
HTH、マーク
私はこのトピックについていくつかの投稿を書いています：
多分これらの投稿も役立つかもしれません：
APIゲートウェイパターン-コースグレインAPIとファイングレインAPI
https://www.linkedin.com/pulse/api-gateway-pattern-ronen-hamias/ https://www.linkedin.com/pulse/successfulapi-ronen-hamias/
粗粒度のサービスAPIと細粒度のサービスAPI
用語は相対的ではありますが、粗粒度のサービス操作は細粒度のサービスよりも広い範囲を定義しています。大まかに設計が複雑になりますが、タスクを完了するために必要な呼び出しの数を減らすことができます。マイクロサービスアーキテクチャでは、粗粒度のAPIゲートウェイ層に常駐し、いくつかのマイクロサービスを調整して特定のビジネスオペレーションを完了することができます。粒度の粗いAPIは、専門知識の異なるドメインを管理することで単一のAPIに懸念が混在し、上記のルールに違反するリスクがあるいくつかのマイクロサービスを含むため、慎重に設計する必要があります。粒度の粗いAPIは、他に存在しないビジネス機能に対して、新しいレベルの細分性を提案する場合があります。たとえば、従業員の雇用には、従業員IDを作成するためのHRシステムへの2つのマイクロサービス呼び出しと、ユーザーアカウントを作成するためのLDAPシステムへの別の呼び出しが含まれる場合があります。または、クライアントが同じタスクを実行するために2つの細かいAPI呼び出しを実行した可能性があります。粗粒度はビジネスユースケースのユーザーアカウント作成を表し、細粒度APIはそのようなタスクに関連する機能を表します。さらにきめの細かいAPIには、さまざまなテクノロジーや通信プロトコルが含まれる場合がありますが、大まかな場合は、統合されたフローに抽象化されます。システムを設計するときは、すべてを解決する黄金のアプローチはなく、それぞれにトレードオフがあるため、両方を検討してください。粗粒度は、他のアプリケーションなどの他のビジネスコンテキストで使用されるサービスとして特に適しています。
元の質問に対する答えはSAGAパターンです。