[解決済み】マイクロサービスのオーケストレーション

質問

マイクロサービスのオーケストレーションの標準的なパターンは何ですか？

マイクロサービスは自分のドメインしか知らないが、複数のサービスが何らかの形で相互作用する必要があるデータの流れがある場合、どのような方法でそれを行うべきか？

例えば、こんなものがあるとします。

• 請求書発行
• 出荷

そして、議論のために、注文が出荷されたら、請求書を作成することにしましょう。

どこかで、誰かがボタンを押し GUI もういいや、これでいこう！」。 古典的なモノリスサービスアーキテクチャでは、「Security」と「Monolith」のどちらかが存在すると思います。 ESB または、Shipmentサービスがinvoiceサービスを知っていて、それを呼び出すだけです。

しかし、この新しいマイクロサービスの世界では、人々はどのように対処しているのでしょうか。

しかし、マイクロサービスでは上記のようなことはできないとされているため、具体的な側面もあります。 だから、意見に基づかない、「代わりに何をすべきか」という定義が必要です。

撃つ。

解決方法は？

本 マイクロサービス構築 は、@RogerAlsing さんの回答で言及されたスタイルについて詳しく説明しています。

43ページの「Orchestration vs Choreography」にこう書かれています。

複雑なロジックをモデル化するようになると、そのロジックに対応するために をまたぐビジネスプロセスの管理という問題があります。 個々のサービスの境界 そして、マイクロサービスでは、次のような問題に直面することになります。 この限界は、通常よりも早くやってきます。[中略）実際に このフローを実現するために、2つのアーキテクチャのスタイルがあります。 に従います。オーケストレーションでは、中央の頭脳に頼ることになります。 オーケストラの指揮者のようなものです。そして 振り付けは、システムの各パーツに自分の仕事を伝え、各パーツに任せます。 ダンサーが自分の道を見つけるように、細部にまでこだわる。 バレエでは、周りの人に合わせて反応します。

そして、この本では、2つのスタイルについて説明がなされています。オーケストレーションスタイルは、よりSOAの考え方に対応したものであり、以下のようなものです。 オーケストレーション/タスクサービス これに対し、コレオグラフィースタイルは ダムパイプとスマートエンドポイント Martin Fowlerの記事で言及されています。

オーケストレーションのスタイル

このスタイルのもとで、上記の本が言及している。

オーケストレーションソリューションはどのようなものかを考えてみましょう。 という流れになります。ここで、おそらく一番シンプルなのは カスタマーサービスが中心的な頭脳として機能します。作成時に、カスタマーサービスは ポイントバンク、メールサービス、郵送サービスなど という一連のリクエスト/レスポンスコールを行います。この その結果、顧客サービス自身が、顧客がどのような状況にあるのかを把握することができます。 プロセスです。お客様のアカウントが設定されたかどうかを確認することができます。 メールや郵便物の配達など、様々なシーンで活躍します。私たちはその フローチャート [...] を、直接コードにモデル化します。さらに を実装してくれるツールです。 ルールエンジンです。このような目的のために、市販のツールが ビジネスプロセスモデリングソフトウェアの 同期を使用すると仮定した場合 リクエスト/レスポンスがあれば、各ステージがうまくいったかどうかまでわかるかもしれない〔。 このオーケストレーション・アプローチの欠点は、カスタマー サービスは、中央集権的になりすぎてしまいます。それは ウェブの真ん中のハブ、ロジックの中心点になってしまう。 が生き始める。私は、このアプローチによって、少数の スマートな「神」サービスは、貧弱なCRUDベースのサービスに何をすべきかを教えてくれるのです。

注：著者がツーリングに言及したのは、次のようなものを指しているのでしょう。 BPM (例) アクティビティ , アパッチODE , カムンダ ). 実のところ、この ワークフローパターンサイト は、この種のオーケストレーションを行うための素晴らしいパターン集で、この方法の実装に役立つさまざまなベンダーのツールの評価詳細も提供しています。著者は、このスタイルの統合を実装するために、これらのツールのいずれかを使用する必要があるとは考えていません。 Springとの統合 , アパッチキャメル または Mule ESB

しかし 他の本 私が読んだMicroservicesの話題や、一般的にウェブで見つけた記事の大半は、以下のようなものだったようです。 この方法を好まない のオーケストレーションの代わりに、次のものを使用することをお勧めします。

振付スタイル

choreography styleのところで、著者はこう言っている。

コレオグラフィックアプローチを使用すれば、単にカスタマー サービスは、非同期でイベントを発行します。 を作成しました。メールサービス、郵便サービス、ポイントバンクは は、これらのイベントをサブスクライブして、それに応じて反応するだけです[...]。 この方法は、より非連続的です。もし 他のサービスが顧客の誕生を知るために必要なのは、そのサービスだけです。 イベントをサブスクライブして、必要なときに仕事をする必要があるのです。しかし 欠点は、ビジネスプロセスの明示的なビューを見ることができることです。 [ワークフロー]が暗黙的にしかシステムに反映されなくなった[...]のです。 このため、次のような監視を確実に行うには、さらなる作業が必要になります。 を確認し、正しいことが起こったかどうかを追跡することができます。例えば ポイントバンクにバグがあり、何らかの理由でポイントがつかなかったとしたら、それは は、正しいアカウントを設定するのでしょうか？私が好きなのは、この問題に対処するための一つのアプローチです。 のビューに明示的に一致する監視システムを構築することです。 ワークフロー]のビジネスプロセスを追跡しつつ、それぞれのビジネスプロセッ を見ることができます。 例外は、より明示的なプロセスの流れにマッピングされます。フローチャート】は [原動力ではなく、あくまでも一つのレンズです。 システムがどのように動作しているかを見ることができます。一般に、私が発見したのは コレオグラフィックアプローチの傾向が強いシステムは、より多くの 疎結合であり、より柔軟で変更に応じやすい。ただし システム間のプロセスを監視し、追跡するために余分な作業が必要になります。 しかし、その境界線は 私は、オーケストレーションに重きを置いた の実装は非常にもろく、変更にかかるコストも高くなります。 その点、私は振り付けのある実装を目指した方がいいと思います。 各サービスが自分の役割を理解するのに十分な賢さを持っているシステムです。 全体のダンス

注：コレオグラフィーが、単に イベント駆動型アーキテクチャ (EDA)ですが、EDAが一つの方法だとすると、他の方法は何でしょうか？(以下も参照 イベントドリブンとはどういう意味ですか？ と イベント駆動型アーキテクチャの意味 ). また、CQRSやEventSourcingといったものも、このアーキテクチャスタイルとよく共鳴しているように思えますが、いかがでしょうか？

さて、この後が楽しみです。マイクロサービスの本では、マイクロサービスをRESTで実装することは想定していません。実はこの本の次の節で、RPCやSOAベースのソリューションの検討を進め、最後にRESTを紹介しているのです。ここで重要なのは、マイクロサービスはRESTを意味しない、ということです。

では、HATEOASはどうなのか？ (ハイパーメディア・アズ・ザ・エンジン・オブ・アプリケーション・ステート)

もし、RESTfulなアプローチを取りたいのであれば、HATEOASを無視するわけにはいきません。彼のブログの記事を参照してください。 REST APIはハイパーテキスト駆動型でなければならない :

HTTPベースのものを何でもかんでも "perfect "と呼ぶ人が多くて、イライラしています。 インターフェースはREST APIです。REST APIを作るために必要なことは何でしょう？ ハイパーテキストは、そのアーキテクチャーのスタイルが明確である。 制約？言い換えれば、アプリケーションの状態のエンジン（そして APIがハイパーテキストによって駆動されていないのであれば、そのAPIは RESTfulであり、REST APIではありえない。時代ですね。何か壊れたマニュアルがあるのでしょうか？ どこかを修正する必要があるのでしょうか？

このように、Fieldingは、HATEOASなしでは真の意味でのRESTfulアプリケーションを構築できないと考えます。Fieldingにとって、サービスをオーケストレーションするためには、HATEOASが最適なのです。私はまだ勉強中ですが、私にとってHATEOASは、誰が、何が、実際にリンクをたどる原動力なのかを明確に定義していません。UIではユーザーかもしれませんが、コンピュータ間のインタラクションでは、より高いレベルのサービスがそれを行う必要があるのでしょう。

HATEOASによれば、APIコンシューマが本当に知る必要のあるリンクは、サーバとの通信を開始するリンク（例：POST /order）だけであるとのこと。このエンドポイントのレスポンスでは、返されるリソースに次の可能な状態へのリンクが含まれるため、この時点からRESTがフローを実施することになる。APIコンシューマは、次にどのリンクをたどればよいかを決定し、アプリケーションを次の状態に移行させる。

どんなにかっこよく聞こえても、クライアントはリンクがPOSTされなければならないのか、PUTされなければならないのか、GETされなければならないのか、PATCHされなければならないのか、などを知っておく必要があるのです。そして、クライアントはどのペイロードを渡すかを決める必要があります。クライアントは、それが失敗した場合にどうするか（再試行、補填、キャンセルなど）を知っておく必要があります。

私はこの件に関してはかなり初心者ですが、HATEOAsの観点からすると、このクライアント、つまりAPIコンシューマは高次のサービスだと思います。人間の視点で考えると、ウェブページ上でエンドユーザがどのリンクをたどるかを決定することが想像できますが、それでも、ウェブページのプログラマは、リンクを呼び出すためにどのメソッドを使用するか、どのペイロードを渡すかを決定しなければなりませんでした。つまり、コンピュータとコンピュータのインタラクションでは、コンピュータがエンドユーザーの役割を担っているのです。もう一度言いますが、これがオーケストレーション・サービスと呼ばれるものです。

HATEOASは、オーケストレーションとコレオグラフィーのどちらにも使えるということですね。

APIゲートウェイパターン

もう一つの興味深いパターンは、クリス・リチャードソンが提案したもので、彼もまた APIゲートウェイパターン .

モノリシック・アーキテクチャでは、アプリケーションのクライアント、たとえばWeb ブラウザやネイティブ・アプリケーションは、HTTPリクエストをロード バランサーは、アプリケーションのN個の同一インスタンスのうちの1つに接続します。しかし マイクロサービスアーキテクチャは、モノリスに代わって サービスの集合体です。その結果、私たちが答えなければならない重要な質問 は、クライアントが何と対話するのか？

ネイティブのモバイルアプリケーションのようなアプリケーションクライアントから 個々のサービスに対してRESTfulなHTTPリクエストを行う [...] 表面的には これは魅力的に見えるかもしれません。しかし 個々のAPI間の粒度のミスマッチが大きい。 サービスやクライアントが必要とするデータ 例えば、あるサービスを表示する場合 ウェブページは、潜在的に多数のサービスの呼び出しを必要とする可能性があります。 例えば、Amazon.com。 説明 一部の のページでは、100以上のサービスを呼び出す必要があります。それだけ多くのリクエストを行うと、たとえ 高速インターネット接続はもちろんのこと、低帯域幅のインターネット接続も可能です。 モバイルネットワークでは、非常に非効率的であり、結果的に高い遅延が発生します。 ユーザーエクスペリエンスが損なわれる。

より良い方法は、クライアントが少量の 1ページあたり、おそらく1回程度のリクエストを、インターネット経由で行います。 APIゲートウェイと呼ばれるフロントエンドサーバーです。

APIゲートウェイは、クライアントとアプリケーションの間に位置する。 マイクロサービス クライアントに合わせたAPIを提供します。そのため APIゲートウェイは、モバイルクライアントには粗視化されたAPIを提供し 高性能なデスクトップのクライアントには、より細かなAPIを提供します。 ネットワークに接続します。この例では、デスクトップクライアントが複数のリクエストを行い ある商品に関する情報を取得するために、モバイルクライアントが は1回のリクエストで済む。

APIゲートウェイは、受信したリクエストを処理するために、ある種の のマイクロサービスを高性能LANで接続します。例えば、Netflixは を例として挙げます。 説明する 1つのリクエストが平均6つのバックエンド・サービスへファンアウトしていく様子。この場合 この例では、デスクトップクライアントからの細かなリクエストは単純に 対応するサービスにプロキシされます。 モバイルクライアントからのリクエストは、その結果を集約して処理されます。 複数のサービスを呼び出す。

APIゲートウェイは、クライアント間の通信を最適化するだけでなく とアプリケーションの詳細をカプセル化します。 マイクロサービス これによって、マイクロサービスを進化させることができます。 クライアントに影響を与えます。例えば、2つのマイクロサービスが マージされます。また、別のマイクロサービスは2つ以上に分割されるかもしれません。 サービスです。これらのサービスを反映させるには、APIゲートウェイのみを更新する必要があります。 を変更します。クライアントは影響を受けません。

ここまでで、APIゲートウェイがどのように アプリケーションとそのクライアントの間で、どのように実装するかを見てみましょう。 マイクロサービス間の通信を行うことができます。

これは前述のオーケストレーションのスタイルとかなり似ていますが、ただ少し意図が異なり、この場合、パフォーマンスとインタラクションの簡略化が目的だと思われます。