23

マイクロサービスは、継続的な配信をより適切にサポートし、迅速な展開と関心の分離のモデルを提供するソフトウェア アーキテクチャ スタイルとして勢いを増しています。

Vert.x 3 と Vert.x-Apex は、マイクロサービスを構築するための興味深いモデルを提供します。例の 1 つが示すように、単純なバーティクルは HTTP サービスを公開できるため、REST サービスを利用できます。verticle は独自の TCP ポートをバインドします。

完全なアプリケーションをサポートするために複数のマイクロサービスにスケールアップする場合、多くの選択肢があります。最終的に継続的デリバリーをサポートし、アップグレードのダウンタイムを最小限に抑えることができるスタイルについて何か考えはありますか?

オプション

  1. 複数のバーティクルを実行すると解決策になる可能性があり、すべてに独自のルーティングが含まれているため、http 処理はバーティクルに含まれています。リクエスト/レスポンスは、バーティクルで完全に処理できます。これは、すべての verticle が独自の tcp ポートで実行されることを意味する可能性があります。
  2. ルーターを使用すると、単一のポートですべてのパスを公開し、それに応じて処理できます。データはルーターを含むバーチクルによって処理され、他のバーチクルに渡すことができます。これは、よりモノリシックなアプローチのように見え始めます。
  3. サービスを含む vert.x の個別のインスタンスを実行します (それらをクラスター化する可能性があります)。全体が自己完結型であるため、これにより継続的デリバリーの使用が容易になる可能性があります。
  4. 他の可能なオプション？

展開

展開側では、アプリケーション全体をダウンさせることなく、新しいサービスを迅速に展開することが望ましいでしょう。

  • オプション 3. はこれを実現する方法を提供できますが、特にすべてのバーティクルで DB バーティクルが実行されている場合に、オーバーヘッドが発生する可能性があります。
  • オプション 1. の方が簡単かもしれませんが、新しいバーティクルと更新されたバーティクルのリロードはどうでしょうか。

個別のマイクロサービスは興味深い開発方法を提供しますが、オーケストレーションと展開にはいくつかの課題があります。

何かご意見は？

4

3 に答える 3

14

用語から始めましょう。

  • Aは、通常はstart(..) メソッドを拡張して実装するverticleJava クラスです。AbstractVerticleバーティクルは、1 つ以上の HTTP エンドポイントを公開し、1 つ以上のエンドポイントを公開できeventbusます。
  • Verticle は Vert.x application(以前は「モジュール」と呼ばれていました) 内で実行されます。アプリケーションには、1 つ以上の頂点を含めることができます。物事を小さくシンプルに保つために、通常は 1:1 にします。
  • Vert.x アプリケーションは Vert.x 内で実行されますinstance。アプリケーションの複数のインスタンスを実行して、並列化を増やすことができます。
  • Vert.x インスタンスは Vert.x 内で実行されますcontainer。コンテナーは、アプリケーションの 1 つ以上のインスタンスを持つ実行中のプロセスです。
  • Vert.x コンテナーは JVM 内で実行されます。

Vert.x を使用してマイクロサービス スタイルのアプリケーションを構築するときは、通常、小さな独立した論理的な作業単位が必要であり、それらをサービスと呼びます。このようなサービスは、理想的には独自のプロセスで実行され、自己完結型であり、独立してアップグレードできる必要があります。これを上記の用語に当てはめます。サービス ロジックを備えた単一の Verticle を含む Vert.x アプリケーションとしてサービスを構築します。

Vert.x アプリケーションは、Hazelcast で構築された分散イベントバスを使用して相互に通信します。これは、同じサーバーまたは複数のサーバーで実行されている複数の JVM が、Vert.x イベントバスを介して相互に通信できることを意味します。

Vert.x で構築された Web アプリケーションは通常、(内部) イベントバス エンドポイントを公開する 1 つまたは複数の Vert.x アプリケーションとイベントバスを介して通信する REST エンドポイントを公開する 1 つまたは複数の Vert.x アプリケーションで構成されます。

あなたの質問に答えるには: オプション 3 は Vert.x セットアップで最も一般的であり、マイクロサービス アーキテクチャに最も近いままです。そこでは 2 つのオプションから選択できます。すべての HTTP 呼び出しを処理し、イベントバスを介して他のアプリケーションに要求処理を委任する REST エンドポイントを使用して 1 つのアプリケーションを実行するか、各サービス (ま​​たは少なくともエンド ユーザーに機能を提供する各サービス) を提供します。 ) 独自の REST エンドポイント。後者は、フロントエンドから接続する HTTP エンドポイントが複数あるため、セットアップが少し複雑ですが、スケーラビリティが高く、単一障害点が少なくなります。

于 2016-02-28T12:51:14.023 に答える
0

サービスを分割するには、スケーラビリティの確かな理由が必要だと思います。また、ライフサイクルを処理し、それらのサービスを相互にやり取りさせる際に遭遇する問題に対処するための画一的なアプローチはありません。 . 「バーチクル」またはその他のものがソケットでリッスンしているかどうかに関係なく、エンドポイント/アドレスの数を制限することで、その方向での頭痛の種が最も少なくなると考えていました。いずれにせよ、特定のバーティクルをそのソケットに関連付けるコード エンティティは、ライフサイクル コントロールを何らかのオーケストレーション フレームワークに何らかの方法で公開する必要があります。

于 2015-11-04T14:30:22.580 に答える