9.3. クラスターの移行

コードベースの移行ストラテジーを決定することが重要です。これは、以下の理由により、Eclipse Vert.x 3.x ノードおよび Eclipse Vert.x 4 ノードを単一のクラスターに追加できないためです。

  • クラスターマネージャーのアップグレード - クラスターマネージャーのメジャーバージョンのアップグレードにより、後方互換性が回避されます。
  • サブスクリプションデータの変更 - Eclipse Vert.x は、クラスターマネージャーに保存されている EventBus サブスクリプションデータの形式を変更しました。
  • トランスポートプロトコルの変更 - Eclipse Vert.x は、クラスターのメッセージトランスポートプロトコルのフィールドを変更しました。

単一アプリケーションまたは密接に関連するマイクロサービスに Eclipse Vert.x クラスターがある場合は、コードベースを一度に新しいクラスターに移行できます。

ただし、一度にコードベースを移行できない場合は、本セクションの推奨事項を使用して Eclipse Vert.x 3.x コードベースを Eclipse Vert.x 4 に移行します。

9.3.1. クラスターの分割

アプリケーションごとに異なるチームが verticle をデプロイしたクラスターがある場合、Eclipse Vert.x 3.x クラスターを小規模なものに分割することを検討してください。クラスターを分割すると、分離されたコンポーネントはクラスタリング機能を使用して通信できなくなることに注意してください。以下のコンポーネントを使用してクラスターを分割できます。

  • EventBus 要求および応答 - HTTP または RESTful Web サービス、gRPC
  • EventBus 送信および公開 - メッセージングシステム、Postgres LISTEN および NOTIFY、Redis Pub および Sub
  • 共有データ - Redis、Infinispan

クラスターの分割後に、各チームの準備が整ったら、または必要に応じて Eclipse Vert.x 4 に移行できます。