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 に移行できます。
