オーケストレーションマイクロサービス
マイクロサービスを編成する標準的なパターンは何ですか？
マイクロサービスが自分のドメインについてしか知らないが、複数のサービスが何らかの方法で相互作用することを要求するデータの流れがある場合、それをどうやって進めるのでしょうか。
このようなものがあるとしましょう。
- 請求書発行
- 出荷
そして議論のために、注文が出荷されたら、請求書を作成する必要があるとしましょう。
どこかで、誰かがGUIのボタンを押しました、 "私はした、これをやりましょう！"古典的なモノリスサービスアーキテクチャでは、これを処理するESBがあるか、またはShipmentサービスが請求書サービスの知識を持っていてそれを呼び出すだけのどちらかであると私は言いたいと思います。
しかし、この勇敢で新しいマイクロサービスの世界で、人々がこれにどう対処するのでしょうか。
私はこれが非常に意見に基づいていると考えられることができると思います。しかし、マイクロサービスは上記を実行することになっていないので、それに具体的な側面があります。そのため、意見に基づいたものではない「定義によって代わりに何をすべきか」があるはずです。
シュート。
本 Building Microservices は、@ RogerAlsingの回答で言及されたスタイルについて詳しく説明しています。
オーケストレーションvs振付の43ページに、この本はこう書いています。
より複雑なロジックのモデル化を開始するにつれて、個々のサービスの境界を越えて広がるビジネスプロセスの管理の問題に対処する必要があります。マイクロサービスでは、通常よりも早くこの制限に達します。 [...]このフローを実際に実装することになると、2つのスタイルのアーキテクチャに従うことができます。オーケストレーションでは、オーケストラの指揮者のように、中央の脳に頼ってプロセスを誘導および駆動します。振り付けでは、システムの各部分にその仕事を知らせ、ダンサーがバレエで周りの人に反応し、周囲の人に反応するように、詳細を練り上げます。
その後、本は2つのスタイルの説明に進みます。オーケストレーションスタイルは オーケストレーション/タスクサービス のSOAアイデアに対応しますが、コレオグラフィースタイルはMartinで言及されている ダムパイプとスマートエンドポイント に対応しますファウラーの記事。
オーケストレーションスタイル
このスタイルの下で、上記の本は次のように言及しています。
このフローでオーケストレーションソリューションがどのようになるかを考えてみましょう。ここで、おそらく最も簡単なことは、カスタマーサービスを中心的な頭脳として機能させることです。作成時に、一連の要求/応答呼び出しを通じて、ロイヤルティポイントバンク、メールサービス、郵便サービス[...]と通信します。顧客サービス自体は、このプロセスで顧客がどこにいるかを追跡できます。顧客のアカウントが設定されているか、メールが送信されたか、投稿が配信されたかを確認できます。フローチャート[...]を取得して、コードに直接モデル化します。おそらく適切なルールエンジンを使用して、これを実装するツールを使用することもできます。このまさに目的のために、ビジネスプロセスモデリングソフトウェアの形で市販ツールが存在します。同期の要求/応答を使用すると仮定すると、各段階が機能しているかどうかさえ知ることができます。[...]このオーケストレーションアプローチの欠点は、顧客サービスが中央管理機関になりすぎてしまうことです。 Webの真ん中にあるハブになり、ロジックが動作し始める中心点になります。このアプローチにより、CRUDベースの貧弱なサービスに何をすべきかを伝える少数のスマートな「神」サービスが得られました。
注：著者がツールについて言及しているとき、彼は BPM （例 Activity 、 Apache ODE 、 カムンダ ）。実際のところ、 Workflow Patterns Website には、この種のオーケストレーションを行うための素晴らしいパターンのセットがあり、この方法で実装するのに役立つさまざまなベンダーツールの評価の詳細も提供します。著者は、これらのツールのいずれかを使用してこのスタイルの統合を実装する必要があると示唆しているとは思いませんが、他の軽量のオーケストレーションフレームワークを使用することもできます。 Spring Integration 、 Apache Camel または Mule ESB
しかし、 他の本 Microservicesのトピックを読んだことがあり、一般にWebで見つけた記事の大部分は このアプローチを嫌います オーケストレーションの代わりに次のものを使用することをお勧めします。
振付スタイル
振り付けスタイルでは、著者は次のように述べています。
振り付けのアプローチでは、代わりに、カスタマーサービスにイベントが非同期的に発行され、Customerが作成されたと伝えることができます。電子メールサービス、郵便サービス、ロイヤルティポイントバンクは、これらのイベントにサブスクライブし、それに応じて対応します[...]このアプローチは、はるかに分離されています。顧客の作成に到達するために他のサービスが必要な場合は、イベントにサブスクライブし、必要に応じて仕事をするだけです。欠点は、[ワークフロー]に表示されるビジネスプロセスの明示的なビューがシステムに暗黙的に反映されることです[...]これは、適切なものがあることを監視および追跡できるようにするために追加の作業が必要であることを意味します起こりました。たとえば、ロイヤルティポイントバンクにバグがあり、何らかの理由で正しいアカウントが設定されなかったかどうかを知っていますか？私がこれに対処するための1つのアプローチは、[ワークフロー]のビジネスプロセスのビューに明示的に一致するモニタリングシステムを構築することです。より明示的なプロセスフロー。 [フローチャート] [...]は原動力ではなく、システムの動作を見ることができる1つのレンズです。一般に、振り付けのアプローチに向かう傾向があるシステムは、より疎結合であり、より柔軟で変化しやすいことがわかりました。ただし、システムの境界を越えてプロセスを監視および追跡するには、余分な作業を行う必要があります。私は、最も重度に組織化された実装が非常に脆弱であり、変更のコストが高いことを発見しました。それを念頭に置いて、私は、各サービスがダンス全体におけるその役割を理解するのに十分スマートな振り付けシステムを目指したいと強く望んでいます。
注：今日まで、振り付けが イベント駆動型アーキテクチャ （EDA）の単なる別の名前であるかどうかはまだわかりませんが、EDAがそれを行う1つの方法である場合、他の方法は何ですか？ （ 「イベント駆動型」とはどういう意味ですか？ および イベント駆動型アーキテクチャの意味 も参照してください）。また、CQRSやEvenSourcingのようなものは、このアーキテクチャスタイルに大きく共鳴しているようです。
さて、これからが楽しいです。マイクロサービスの本では、マイクロサービスがRESTで実装されることを想定していません。実際、本の次のセクションでは、RPCとSOAベースのソリューション、そして最後にRESTについて検討します。ここで重要な点は、MicroservicesはRESTを意味しないことです。
では、HATEOASについてはどうですか？
現在、RESTfulアプローチを採用したい場合、HATEOASを無視することはできません。さもなければ、Roy Fieldingは彼のブログで、ソリューションが本当にRESTではないことを喜んで言います。 REST APIはハイパーテキスト駆動である必要があります ：に関する彼のブログ投稿を参照してください。
HTTPベースのインターフェイスをREST APIと呼んでいる人の数にイライラしています。 RESTアーキテクチャスタイルをハイパーテキストが制約であるという概念で明確にするために、何をする必要がありますか？つまり、アプリケーション状態のエンジン（およびAPI）がハイパーテキストによって駆動されていない場合、RESTfulにすることもREST APIにすることもできません。期間。修正が必要な壊れたマニュアルがどこかにありますか？
ご覧のとおり、フィールディングは、HATEOASがなければRESTfulなアプリケーションを本当に構築していないと考えています。フィールディングの場合、HATEOASは、サービスをオーケストレーションする際の手段です。私はこれをすべて学んでいますが、HATEOASは、実際にリンクをたどる背後にある推進力が誰または何であるかを明確に定義していません。ユーザーになる可能性のあるUIではありますが、コンピューター間の対話では、それはより高いレベルのサービスによって行われる必要があると思います。
HATEOASによると、APIコンシューマーが本当に知る必要がある唯一のリンクは、サーバーとの通信を開始するリンクです（例：POST/order）。このエンドポイントの応答では、返されるリソースに次の可能な状態へのリンクが含まれるため、RESTがフローを実行します。次に、APIコンシューマーは、どのリンクをたどってアプリケーションを次の状態に移行するかを決定します。
どれほどクールに聞こえるかにかかわらず、クライアントはリンクをPOST、PUT、GET、PATCHなどする必要があるかどうかを知る必要があります。また、クライアントは渡すペイロードを決定する必要があります。クライアントは、失敗した場合の対処方法（リトライ、補正、キャンセルなど）を認識する必要があります。
私はこれらすべてにかなり慣れていませんが、私にとっては、HATEOAの観点からすると、このクライアントまたはAPIコンシューマーは高次サービスです。人間の観点から考えると、どのリンクをたどるかを決定するWebページのエンドユーザーを想像できますが、それでもWebページのプログラマーは、リンクを呼び出すために使用する方法と、渡すペイロード。したがって、私のポイントでは、コンピューター間の相互作用において、コンピューターがエンドユーザーの役割を果たします。これが、オーケストレーションサービスと呼ばれるものです。
オーケストレーションまたは振り付けのいずれかでHATEOASを使用できると思います。
API Gatewayパターン
別の興味深いパターンがChris Richardsonによって提案されています。ChrisRichardsonは、彼が API Gateway Pattern と呼んでいるものも提案しました。
モノリシックアーキテクチャでは、Webブラウザやネイティブアプリケーションなどのアプリケーションのクライアントは、ロードバランサーを介して、アプリケーションのN個の同一インスタンスの1つにHTTP要求を行います。しかし、マイクロサービスアーキテクチャでは、モノリスがサービスのコレクションに置き換えられました。その結果、私たちが答える必要がある重要な質問は、クライアントが何と対話するかです。
ネイティブモバイルアプリケーションなどのアプリケーションクライアントは、個々のサービスに対してRESTful HTTP要求を行うことができます[...]表面的には、これは魅力的に思えるかもしれません。ただし、個々のサービスのAPIとクライアントが必要とするデータとの間には、粒度の大きな不一致がある可能性があります。たとえば、1つのWebページを表示するには、多数のサービスの呼び出しが必要になる可能性があります。たとえば、Amazon.comでは、 describes 100+サービスへの呼び出しが必要なページがあります。低帯域幅、高遅延のモバイルネットワークは言うまでもなく、高速インターネット接続を介して多くの要求を行うことは非常に効率が悪く、ユーザーエクスペリエンスが低下します。
はるかに優れたアプローチは、クライアントがページごとに少数のリクエストを、おそらくは1つ程度、インターネット経由でAPIゲートウェイと呼ばれるフロントエンドサーバーに送信することです。
APIゲートウェイは、アプリケーションのクライアントとマイクロサービスの間に位置します。クライアントに合わせたAPIを提供します。 APIゲートウェイは、モバイルクライアントに粗粒度のAPIを提供し、高性能ネットワークを使用するデスクトップクライアントに細粒度のAPIを提供します。この例では、デスクトップクライアントは製品に関する情報を取得するために複数の要求を行いますが、モバイルクライアントは1つの要求を行います。
APIゲートウェイは、高性能LANを介していくつかのマイクロサービスに要求を行うことにより、着信要求を処理します。たとえば、Netflixは、 describes 各リクエストが平均6つのバックエンドサービスにファンアウトする方法です。この例では、デスクトップクライアントからのきめの細かい要求は対応するサービスに単純にプロキシされますが、モバイルクライアントからの各きめの細かい要求は、複数のサービスを呼び出した結果を集約することによって処理されます。
APIゲートウェイは、クライアントとアプリケーション間の通信を最適化するだけでなく、マイクロサービスの詳細もカプセル化します。これにより、クライアントに影響を与えることなくマイクロサービスを進化させることができます。たとえば、2つのマイクロサービスをマージできます。別のマイクロサービスが2つ以上のサービスに分割される場合があります。これらの変更を反映するには、APIゲートウェイのみを更新する必要があります。クライアントは影響を受けません。
APIゲートウェイがアプリケーションとそのクライアントの間を仲介する方法を確認したので、マイクロサービス間の通信を実装する方法を見てみましょう。
これは、上記のオーケストレーションスタイルと非常によく似ていますが、意図がわずかに異なります。この場合、パフォーマンスと対話の簡素化がすべてのようです。
さらに読む
NGINXブログ に最近公開された素晴らしいシリーズの記事があります。これらのすべての概念をさらに深く掘り下げることをお勧めします。
ここでさまざまなアプローチを集約しようとしています。
ドメインイベント
これに対する主なアプローチは、各イベントが何が起こったのかに関するイベントを発行し、他のサービスがそれらのイベントをサブスクライブできるドメインイベントを使用することのようです。これはスマートエンドポイント、ここで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つのサービスがあります。
- 請求書マイクロサービス
- 出荷マイクロサービス
現実の世界では、注文状態を保持する場所があります。それを注文サービスと呼びましょう。次に、注文処理のユースケースがあります。これは、注文がある状態から別の状態に移行したときの対処方法を知っています。これらすべてのサービスには特定のデータセットが含まれています。今、あなたには他に何かが必要です。それがすべての調整を行います。これはそうかもしれません：
- すべてのサービスを把握し、ユースケースを実装する単純なGUI（「完了しました」と出荷サービスを呼び出す）
- 「完了しました」イベントを待つビジネスプロセスエンジン。このエンジンはユースケースとフローを実装しています。
- オーケストレーションマイクロサービス、あなたのドメインのフロー/ユースケースを知っている注文処理サービス自体としましょう。
- 私はまだ考えていない他の何か
これに関する主な点は、コントロールが外部にあるということです。これは、すべてのアプリケーションコンポーネントが、疎結合の個々の構成要素であるためです。ユースケースが変わると、オーケストレーションコンポーネントである1つの場所で1つのコンポーネントを変更しなければなりません。別の注文フローを追加した場合、最初のものと干渉しない別のオーケストレータを簡単に追加できます。マイクロサービスの考え方は、スケーラビリティと空想的なREST APIの実行だけでなく、明確な構造、コンポーネント間の依存関係の削減、およびビジネス全体で共有される共通データと機能の再利用についてもです。
HTH、マーク
Stateを管理する必要がある場合は、CQRSによるイベントソーシングが理想的なコミュニケーション方法です。そうでなければ、非同期メッセージングシステム（ＡＭＱＰ）をマイクロサービス間通信に使用することができる。
あなたの質問から、それはCQRSとESが正しい組み合わせでなければならないことは明らかです。 Javaを使用している場合は、Axonフレームワークを見てください。または、KafkaまたはRabbitMQを使用してカスタムソリューションを構築してください。
元の質問に対する答えはSAGAパターンです。