複数のアプリケーションを含む Spring Cloud クラスタが Alibaba Cloud にデプロイされている場合は、アプリケーションを Serverless App Engine (SAE) に移行できます。このトピックでは、アプリケーションを SAE にスムーズに移行し、サービスの登録と検出を実行する方法について説明します。
データ移行プロセス
必須: アプリケーションを移行します。
ほとんどの場合、移行されるアプリケーションはステートレスであり、最初に移行する必要があります。
オプション。Server Load Balancer (SLB) インスタンスを移行するか、ドメイン名構成を変更します。
アプリケーションの移行後、アプリケーションにバインドされている SLB インスタンスを移行するか、ドメイン名構成を変更する必要があります。
SLB インスタンス
移行前に SLB インスタンスを使用している場合は、移行後に SLB インスタンスを再利用できます。ビジネス要件に基づいて、SLB インスタンスのバインドポリシーを選択できます。詳細については、「CLB をアプリケーションにバインドし、アプリケーションのパブリックまたはプライベートアクセス IP を生成する」をご参照ください。
移行前に SLB インスタンスを使用していない場合は、前の図に示すように、移行後に SLB インスタンスを作成し、API ゲートウェイなどのイングレスアプリケーションにバインドすることをお勧めします。
アプリケーションを移行する場合は、Elastic Compute Service (ECS) の使用コストを削減するために、デュアル登録とデュアルサブスクリプションを有効にすることをお勧めします。特定の原因(たとえば、ECS インスタンスに構成されている元のポートが使用されているなど)により既存の ECS インスタンスを使用できない場合は、トラフィック分割移行ソリューションを使用して新しい ECS インスタンスを追加する必要があります。アプリケーションの移行後、ビジネス要件に基づいて、既存の SLB インスタンスを再利用するか、SLB インスタンスを作成して移行済みアプリケーションにバインドします。
ドメイン名
移行後に SLB インスタンスを再利用できる場合は、ドメイン名を変更する必要はありません。
SLB インスタンスを作成して移行済みアプリケーションにバインドする場合は、新しい SLB インスタンスをドメイン名構成に追加し、不要になった SLB インスタンスを削除する必要があります。詳細については、「ドメイン名の DNS サーバーを変更する」をご参照ください。
オプション: ストレージとメッセージキューを移行します。
アプリケーションが Alibaba Cloud にデプロイされており、ApsaraDB RDS や ApsaraMQ などの Alibaba Cloud サービスを使用している場合は、ストレージまたはメッセージキューを移行する必要はありません。
アプリケーションが Alibaba Cloud にデプロイされている場合は、DingTalk グループ (ID: 32874633) に参加してテクニカルサポートを受けてください。
このトピックでは、デモアプリケーションを SAE にスムーズに移行する方法の例を示します。デモアプリケーションのダウンロード URL については、「デモ」を参照してください。
移行ソリューション
トラフィック分割、デュアル登録とデュアルサブスクリプションのいずれかのソリューションを使用して、アプリケーションを移行できます。どちらのソリューションも、ビジネスを中断することなく、アプリケーションのスムーズな移行を保証します。
このセクションでは、デュアル登録とデュアルサブスクリプションの移行ソリューションについて説明します。
トラフィック分割移行
Spring Cloud Alibaba を使用して、元のサービスレジストリを Nacos に切り替えます。アプリケーションを開発して SAE にデプロイし、SLB インスタンスとドメイン名を設定してトラフィックを切り替えます。
詳細については、「Spring Cloud アプリケーションを SAE にホストする」をご参照ください。
デュアル登録とデュアルサブスクリプション
デュアル登録とデュアルサブスクリプションソリューションとは、移行中に元のサービスレジストリと SAE サービスレジストリの両方にアクセスすることを指します。これにより、移行済みアプリケーションと移行されていないアプリケーションが相互に呼び出すことができます。
次の図は、デュアル登録とデュアルサブスクリプションの移行ソリューションのアーキテクチャを示しています。
初期状態
ステップ 1
ステップ 2
ステップ 3
ステップ 4
移行済みアプリケーションと移行されていないアプリケーションは、相互に検出して呼び出すことができます。これにより、業務の継続性が確保されます。
依存関係を追加し、少量のコードを変更するだけで、デュアル登録とデュアルサブスクリプションを実装できます。
コンシューマーサービス呼び出しの詳細を表示し、移行の進捗状況をリアルタイムで表示できます。
アプリケーションを繰り返し再起動することなく、サービス登録とサブスクリプションのポリシーを動的に変更できます。移行プロセスでは、アプリケーションを1回だけ再起動する必要があります。
ステップ 1: 最初のアプリケーションを移行する
SAE に移行するアプリケーションの優先順位を割り当てます。
移行の優先順位が高いアプリケーションを選択します。下位のプロバイダーから移行を開始することをお勧めします。トレースが複雑で分析が難しい場合は、移行するアプリケーションをランダムに選択できます。
アプリケーションに依存関係を追加し、その構成を変更します。
spring-cloud-starter-alibaba-nacos-discovery
依存関係を pom.xml ファイルに追加します。<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId> <version>{Version}</version> </dependency>
Nacos サーバーの IP アドレスを application.properties に追加します。
spring.cloud.nacos.discovery.server-addr=127.0.0.1:8848
複数のレジストリの
edas-sc-migration-starter
依存関係を追加します。デフォルトでは、Spring Cloud では、pom.xml ファイルに依存関係として1つのレジストリのみを追加できます。複数のレジストリを追加しようとすると、エラーが返されます。Spring Cloud で複数のレジストリをサポートするには、
edas-sc-migration-starter
依存関係を追加します。<dependency> <groupId>com.alibaba.edas</groupId> <artifactId>edas-sc-migration-starter</artifactId> <version>1.0.2</version> </dependency>
RibbonClients のデフォルト構成を変更します。
アプリケーションが複数のレジストリからサービスをサブスクライブできるようにするには、ロードバランシングに使用される Ribbon の構成を変更する必要があります。アプリケーション起動のメインクラスで、RibbonClients を
MigrationRibbonConfiguration
に設定します。次のコードは、元のメインクラスコードです。
@SpringBootApplication public class ConsumerApplication { public static void main(String[] args) { SpringApplication.run(ConsumerApplication.class, args); } }
次のコードは、変更されたメインクラスコードです。
@SpringBootApplication @RibbonClients(defaultConfiguration = MigrationRibbonConfiguration.class) public class ConsumerApplication { public static void main(String[] args) { SpringApplication.run(ConsumerApplication.class, args); } }
説明オンプレミス環境のマシンでアプリケーションが変更された後、または SAE にデプロイされた後、アプリケーションを管理できます。たとえば、特定のレジストリにアプリケーションを登録したり、特定のレジストリからサービスをサブスクライブしたりできます。要件を満たすには、Spring Cloud Config または Nacos Config を使用してアプリケーションの構成を動的に調整します。この場合、アプリケーションを再起動する必要はありません。詳細については、「サービス登録ポリシーとサービスサブスクリプションポリシーを動的に調整する」をご参照ください。
Spring Cloud Config または Nacos Config を使用するには、構成管理の依存関係をアプリケーションに追加し、関連する構成を変更する必要があります。Spring Cloud Config を使用する場合は、オープンソースドキュメントを参照してください。Nacos Config を使用する場合は、「構成管理を実装する」をご参照ください。
アプリケーションを SAE にデプロイします。
ビジネス要件に基づいて、アプリケーションを SAE にデプロイします。詳細については、「アプリケーションのデプロイ」をご参照ください。
次のいずれかの方法を使用して、結果を確認します。
ビジネスが想定どおりに実行されているかどうかを確認します。
サービスサブスクリプションのモニタリングデータを表示します。
Spring Boot 1.x: http://ip:port/dubboRegistry
Spring Boot 2.x: http://ip:port/actuator/dubboRegistry
アプリケーションで Spring Boot Actuator が有効になっている場合は、Actuator にアクセスして、アプリケーションがサブスクライブしている各サービスの RibbonServerList 情報を表示できます。次の図は、Actuator にアクセスするために使用できる URL を示しています。metaInfo の
serverGroup
フィールドは、ノードのサービスレジストリを示します。
ステップ 2: 他のアプリケーションを移行する
すべてのアプリケーションを SAE に順番に移行します。詳細については、「ステップ 1: 最初のアプリケーションを移行する」をご参照ください。
ステップ 3: 移行構成を削除する
移行後、元のサービスレジストリ構成と、移行中に使用された edas-sc-migration-starter
依存関係を削除します。
edas-sc-migration-starter
は、移行専用のスターターです。スターターを長期間使用する場合、スターターはサービスの安定性に影響を与えませんが、Ribbon のロードバランシング効果を制限します。移行後にスターターを削除し、オフピーク時にアプリケーションをバッチで再起動することをお勧めします。
サービス登録ポリシーとサービスサブスクリプションポリシーを動的に調整する
SAE の構成管理機能を使用して、移行中にサービス登録ポリシーとサービスサブスクリプションポリシーを動的に調整できます。
サービスサブスクリプションポリシーを動的に調整する
デフォルトのサブスクリプションポリシーでは、SAE が関連するすべてのレジストリからサービスデータをサブスクライブして集約できます。
特定のレジストリからデータをサブスクライブするには、SAE の構成管理機能を使用して、
spring.cloud.edas.migration.subscribes
プロパティを変更します。spring.cloud.edas.migration.subscribes=nacos,eureka # Eureka と Nacos からサービスをサブスクライブします。 spring.cloud.edas.migration.subscribes=nacos # Nacos からのみサービスをサブスクライブします。
サービス登録ポリシーを動的に調整する
デフォルトの登録ポリシーでは、SAE が関連するすべてのレジストリに登録できます。
SAE の構成管理機能を使用して、サービスレジストリを調整できます。
spring.cloud.edas.migration.registry.excludes
プロパティを使用して、無効にするレジストリを指定します。spring.cloud.edas.migration.registry.excludes= # デフォルトでは、値は空です。これは、すべてのサービスレジストリに登録されることを示します。 spring.cloud.edas.migration.registry.excludes=eureka # Eureka への登録を無効にします。 spring.cloud.edas.migration.registry.excludes=nacos,eureka # Nacos と Eureka への登録を無効にします。
この例では、アプリケーションの実行中にアプリケーションが登録されているレジストリを動的に変更する必要がある場合は、Spring Cloud の構成管理機能を使用してプロパティを変更できます。