Dubbo3 features | cloud-native three-center architecture

Dubbo3 は新しいアプリケーションレベルのサービスディスカバリモデルを提供します。これは設計と実装の両面において、Dubbo2 のインターフェイクレベルのサービスディスカバリモデルとは異なるものです。
まとめると、Dubbo3 で導入されたアプリケーションレベルのサービスディスカバリには、主に以下の利点があります。
クラウドネイティブマイクロサービスの変化に適応します。クラウドネイティブ時代のインフラストラクチャの機能は継続的に上位レイヤーに公開されており、Kubernetes などのプラットフォームはマイクロサービスの概念的な抽象化を統合しています。Dubbo3 のアプリケーションレベルのサービスディスカバリは、さまざまなマイクロサービスシステムに適応する汎用モデルです。
パフォーマンスとスケーラビリティを向上させます。超大規模クラスターをサポートするサービスガバナンスは、常に Dubbo の強みでした。アプリケーションレベルのサービスディスカバリモデルの導入により、レジストリのアドレスデータの保存とプッシュの負荷を本質的に解決し、コンシューマー側の対応するアドレス計算負荷も桁違いに低下します。クラスターサイズも予測可能で評価しやすくなりました（RPC インターフェイスの数とは無関係で、インスタンスの展開規模のみに依存します）。
次の図は Dubbo2 のサービスディスカバリモデルを示しています。Provider がサービスアドレスを登録し、Consumer がレジストリと連携してサービスアドレスを検出し、そのアドレスとの通信を開始します。これは、ほとんどのマイクロサービスフレームワークで採用されている古典的なサービスディスカバリプロセスです。Dubbo2 の特徴は、RPC インターフェイスの情報もアドレス検出プロセスに統合している点で、この情報は特定のビジネス定義と密接に関連しています。
クラウドネイティブインフラストラクチャに接続すると、インフラストラクチャ側でマイクロサービスの概念の抽象化が取り込まれ、コンテナ化されたマイクロサービスのオーケストレーションとスケジューリングのプロセスがインフラストラクチャレベルで登録を完了します。次の図に示すように、インフラストラクチャはレジストリの役割を担うだけでなく、サービス登録アクションも完了しますが、RPC インターフェイスの情報は特定のビジネスに関連するため、インフラストラクチャが管理することは不可能であり、適していません。
このようなシナリオでは、Dubbo3 のサービス登録・検出メカニズムに対して 2 つの要件が提示されます。Dubbo3 は、元のサービスディスカバリプロセスからビジネスロジックとは無関係な汎用アドレスマッピングモデルを抽象化し、このモデルがアドレスの登録動作と保存を基盤インフラストラクチャに委譲できる十分な合理性を備えていることを保証する必要があります。Dubbo3 独自のビジネスインターフェイス同期メカニズムは保持すべき強みであり、Dubbo3 で定義された新しいアドレスモデルに基づき、フレームワーク内の独自のメカニズムで解決する必要があります。
このように設計された新しいサービスディスカバリモデルは、アーキテクチャの互換性とスケーラビリティの両面で Dubbo3 に大きな利点をもたらします。
アーキテクチャの互換性に関しては、前述のように、Dubbo3 が基盤インフラストラクチャのサービス抽象化機能を活用できるようになります。さらに、ユーザーが Dubbo を使用してヘテロジニアスマイクロサービスシステムの接続を検討することも可能になります。
Dubbo3 のサービスディスカバリモデルは、スケーラブルなサービスシステムの構築により適しています。これをどのように理解すればよいでしょうか。Dubbo2 と Dubbo3 のアドレス検出プロセスにおけるデータフローの変化を直感的に比較する簡単な例を示します。あるマイクロサービスアプリケーションが 100 のインターフェイス（Dubbo のサービス）を定義し、このアプリケーションを 100 台のサーバーに展開すると仮定します。Dubbo2 では、レジストリに 100 のサービスを登録する必要があり、これらの 100 のサービスは合計 100 × 100 = 10000 の仮想ノードを生成します。一方、同じアプリケーションに対して Dubbo3 では、新しい登録・検出モデルは 1 つのサービス（インターフェイスではなくアプリケーションのみに関連）のみを必要とし、レジストリに登録する仮想ノードはマシンインスタンス数に等しい 1 × 100 = 100 のみです。この簡単な例では、Dubbo が登録するアドレスの数は元の 1/100 に削減され、レジストリとサブスクライバーのストレージ負荷を大幅に軽減します。さらに重要なのは、アドレス検出の容量がビジネス RPC の定義から完全に切り離され、クラスター全体の容量評価が運用保守にとってより透過的になることです。展開されるマシンの数だけが大負荷として現れ、Dubbo2 のようにビジネス RPC の変更がクラスター全体のサービスディスカバリの安定性に影響を与えることはありません。
Dubbo3 のデプロイメントアーキテクチャ
この記事では、主にクラウドネイティブ環境でのデプロイメントアーキテクチャに焦点を当てます。主な特徴は、インフラストラクチャ（Kubernetes、Service Mesh (ASM) など）がより多くの責務を担うようになり、レジストリセンター、メタデータセンター、コンフィグセンターなどの 3 つのセンターアーキテクチャの責務が統合されることで、アーキテクチャがより洗練され、リソースの最適化がより徹底的に行われる点です。これらのセントラライズドコンポーネントを分析することで、クラウドネイティブモードに対応する Dubbo3 の動作原理をより理解しやすくなります。
上記の図から、Dubbo RPC フレームワーク全体において、従来から定義されている Consumer、Provider、Registry に加え、多くのセントラライズドコンポーネントが存在することがわかります。コンフィグセンターとメタデータの 2 つのセンターがあります。
Dubbo3 の 3 センターアーキテクチャ
マイクロサービスフレームワークとして、Dubbo SDK はマイクロサービスコンポーネントとともに分散クラスターの各所に展開され、さまざまなマイクロサービスコンポーネント間の連携を実現するために、Dubbo3 はセントラライズドコンポーネントを拡張しています。具体的には以下の通りです。
レジストリ
Consumer と Provider 間のアドレス登録とディスカバリを連携します。
コンフィグセンター
Dubbo 起動フェーズのグローバル設定を保存し、設定の環境間共有とグローバル整合性を確保します。
サービスガバナンスルール（ルーティングルール、動的構成など）の保存とプッシュを担当します。
メタデータセンター
Provider サーバーから報告されるサービスインターフェイスメタデータを受信し、Admin などのコンソール向けの運用機能（サービステスト、インターフェイスメタデータなど）を提供します。
サービスディスカバリメカニズムの補完として、追加のインターフェイス/メソッドレベルの設定情報の同期機能を提供し、レジストリの追加拡張に相当します。
注：上記の 3 つのセンターは Dubbo を実行するための必須条件ではありません。ユーザーは自身のビジネス状況に応じて 1 つ以上のセンターのみを有効にすることができ（センターなしの直接接続モードも可能ですが、本番環境では推奨されません）、デプロイメントの簡素化を実現できます。
次に、これら 3 つのセンターについて詳しく説明します。
レジストリセンター
ほとんどの場合、独立したレジストリセンターを使用して Dubbo サービス開発を開始し、コンフィグセンターとメタデータセンターはマイクロサービスの進化に応じて必要に応じて段階的に導入されます。
レジストリセンターは非常に重要な役割を担っており、サービス登録とサービスディスカバリの責務を果たします。現在、Dubbo はインターフェイクレベルとアプリケーションレベルの 2 つの粒度でのサービスディスカバリとサービス登録をサポートしており、レジストリセンターは必要に応じて展開できます。
直接接続モード
Dubbo SDK の初期使用時に、直接接続モードの RPC サービスのみを提供する場合は、レジストリセンターを展開する必要はありません。
登録モード
インターフェイクレベルまたはアプリケーションレベルのいずれにおいても、Dubbo SDK 自体でサービス登録とサービス検出を行う必要がある場合は、レジストリセンターの展開を選択し、Dubbo で対応するレジストリセンターを統合できます。
メッシュモード
Dubbo + Mesh のシナリオでは、Dubbo のサービス登録機能の弱化に伴い、Dubbo のレジストリセンターは必須ではなくなり、その責務はコントロールプレーンに置き換えられつつあります。Dubbo + Mesh のデプロイメント方式を採用する場合、ThinSDK の Proxyless メッシュ方式でもサイドカーメッシュ方式でも、レジストリセンターを個別に展開する必要はありません。
レジストリセンターはコンフィグセンターとメタデータセンターに依存しません
構成として、レジストリセンターはコンフィグセンターとメタデータセンターに完全には依存しません。次の図に示す通りです。
コンフィグセンターとメタデータセンターが展開されていない場合、Dubbo ではデフォルトでレジストリセンターのインスタンスがコンフィグセンターとメタデータセンターとしても同時に使用されます。これは Dubbo のデフォルト動作です。コンフィグセンターまたはメタデータセンターの機能が本当に不要な場合は、設定で無効にできます。レジストリセンターの設定には use-as-config-center と use-as-metadata-center の 2 つの設定があり、これらを false に設定します。