Dubbo に基づく Zhengcai Cloud のハイブリッドクラウドデータクロスネットワーク実践

*著者: Zhengcaiyun 上級開発エンジニア、Wang Xiaobin

プロジェクトの背景

Zhengcaiyun のビジネスは淘宝網と同様、政府向けのショッピングサイトです。政府調達は、Zhengcai Cloud上で企業調達および政府調達業務を行う。

Yundao の「クラウド」とは、弊社のクラウドプラットフォームを指します。クラウドプラットフォームは、弊社が展開する一連のショッピングウェブサイトであり、技術的には一連のマイクロサービスフレームワークに相当します。「島」については、例えば安徽省や山西省は独自のローカルエリアネットワークを持っており、そこにこのサービスフレームワーク一式を展開すると、それを「島」と呼びます。当社のクラウドプラットフォームは主に浙江省およびその他の関連地域で使用されています。

私たちのクラウドと島の間のデータ送信の問題があります。たとえば、今政府からの発表が届きましたが、この発表は全国的なものになる可能性があります。その後、クラウドプラットフォームの管理プラットフォームにアナウンスを記録してプッシュすることがありますが、このとき、クラウドとアイランドの間でデータの同期が行われます。

1. クラウドアイランドネットワーク

当社のクラウドプラットフォームでは、このLANは社内で完全に制御可能です。たとえば、ポートを開きたい場合、すぐに開くことができます。島側では、ローカルエリアネットワークかもしれないし、プライベートネットワークかもしれないし、例えば、以前に浙上銀行のプロジェクトをやりましたが、そこは完全な孤島です。セキュリティポリシーやポート開放はすべて自社で定義しており、これが当社クラウドアイランドのビジネス構造です。

2. ハイブリッドクラウドアイランドネットワーク

上の図は大まかなデータリンク図です。クラウドプラットフォームの下には支店や支店があり、これらが一連の業務システムに相当します。政府クラウドは、先ほど述べた省レベル (安徽省) または市レベル (無錫市) の対応するブロックおよび孤立した政府クラウドです。プライベート展開は、銀行、国有企業、軍、政府、企業などのための典型的なハイブリッドクラウドネットワークアーキテクチャです。

3. ハイブリッドクラウドアイランドネットワークの特徴

当社のハイブリッドクラウドネットワークアーキテクチャの特徴は次のとおりです。

プラットフォームの一貫性。 パブリッククラウド、クラウドプラットフォーム、ガバメントクラウド、プライベートクラウドに展開するコードのセットは同じです。一連のコードをさまざまな場所にデプロイすると、複数のプラットフォームになります。
ネットワーク接続と機能の再利用。 テキストメッセージングなどの一部のサードパーティの機能に依存しますが、プライベートクラウド上のネットワーク制御は比較的厳格であるため、サードパーティとポートやネットワークを交換するプロセスはさらに長くなります。複雑。現時点では、クラウドプラットフォームの機能を再利用したいと考えており、現時点ではクラウドプラットフォーム間でデータのやり取りが行われています。
クロスドメインアクセスの移行。 クロスドメイン相互アクセスのシナリオがあります。
統合プラットフォーム管理。 先ほどの例のように、アナウンスを発行する場合は、1 つのプラットフォームで管理できることが望ましいと考えられます。浙江省と安徽省に1台ずつ送る代わりに、維持コストが比較的高くなる。

4. 政府および企業ネットワークの問題点

多くの企業は政府と取引していますが、政府と企業のネットワークには次のような特徴があります。

ネットワークは複雑です。たとえば、銀行のネットワークはセキュリティや内部事情が非常に複雑で、ネットワークを開くために必要なプロセスが多く、頻繁に実行する必要があり、実行が終了すると新たな問題が見つかり、再度実行する必要があります。。

安全性の要件は高いです。例えば、ポートを開く際にはデータを送信する必要がありますが、内部でシリアル化されたプロトコルが仕様を満たしていなければ削除されてしまいます。今回私たちに与えられた業務は、実はタイムアウト、つまり一般例外です。そして何が起こったのか分からず、それが未知のリスクをもたらします。

ビジネス主導の運用と保守。用事があるときだけデプロイして実行します。私たちは複数の投資を繰り返し行うことになるため、人的コストと時間のコストが増加し、プライベート展開が増加します。

5. 既存のソリューション

上記の問題点に基づいて、2 つの計画を立てました。

最初のソリューションは、Dubbo フィルターに基づく一方向のソリューションです。 このソリューションには長い歴史があり、2 つの特徴があります。

1つ目の特徴は片方向送信です。「アイランド」から「クラウド」への一方向のみですが、なぜDubbo Filterをベースにしているかというと、社内のマイクロサービスはすべてDubbo経由で呼び出されるため、Dubboへの依存度が高いからです。したがって、ネットワークを越えたデータのソリューションは、間違いなく Dubbo の特性に基づいたものとなるでしょう。

2 つ目の特徴は、ビジネスプロバイダーフィルターをローカルに展開するのに運用と保守の負担がかかることです。アイランドがデータをクラウドに同期する必要がある場合、データはアイランドのビジネス Web からクラウドのビジネスプロバイダーに送信されます。現時点では、一連のビジネスプロバイダーも島に配置する必要があります。これをデプロイする理由は、リクエストをインターセプトし、クラウドプラットフォームにデプロイされた Dubbo ゲートウェイにリクエストを転送するためです。

しかし、今度は私たちに負担がかかることになる。プロバイダーがすでに存在するため、アイランドのデータベースにデータが保存されている場合は問題ありません。ただし、一部の企業はネットワーク経由でのみ使用され、ローカルデータベースが保存されていません。その場合、企業によって展開されたプロバイダーは冗長になります。この時。

2 番目のソリューションは、メッシュポイントツーポイントソリューションです。 アイランド間ではネットワークの相互運用性が必要なため、このポイントと送信が必要なポイントの間のポートが個別に開かれます。アクティブ化した後、それを呼び出すことができます。呼び出し方法は Dubbo またはその他の方法で可能です。

このソリューションには明らかな欠陥があり、線が多すぎるため、ポイント間を開く複雑さも非常に高く、その後の拡張にも非常に悪影響を与える可能性があります。

上記のソリューションの問題には、一方向の送信、ホワイトリストのアクティブ化のコストの高さ、プラットフォームのメンテナンスのコストの高さ、およびパブリック機能の欠如が含まれます。

上記の問題に基づいて、私たちは高速道路と呼ばれる新しい計画を立てました。

なぜ高速道路と呼ばれるのですか？

なぜ高速道路と呼ばれるのですか？なぜなら、私たちが達成したい効果は次のようなものだからです。

一度ビルドするだけで再利用可能

たとえば、北京から上海までの高速道路は幅が十分であれば1本で十分です。上海から北京へ、または杭州から北京へ行く場合は再利用でき、別途構築する必要はありません。
トンネリング機構

高速道路が建設される場所は平地とは限らず、川や海、山などの近くにある場合もあります。高速道路の下にトンネルを建設すると、現時点ではドライバーの感覚が鈍くなります。私たちの目的も同じで、政府や企業のネットワークが複雑だと思われる場合は、混乱しないようにネットワークをブロックするお手伝いをします。
伝送性能を考慮する

各事業部門が独自に伝送回線を構築する場合、必ずしも他の部門で使用する必要がない、または他の部門で使用されている場合でも伝送性能が確保できるため、自部門の業務が遂行できれば十分な伝送性能が得られます。小規模でのみ使用されます。ただし、再利用可能なリンクを構築している場合は、伝送パフォーマンスを考慮する必要があります。

道路工事の実習

次に、高速道路を建設する際に遭遇した問題点とその具体的な方法を紹介します。クライアントアクセスに関して次の問題が発生しました。

最初の問題は、Dubbo への依存度が高いことです。

2 番目の問題である透過的な送信は、Dubbo の使用方法を変更しません。つまり、Dubbo を置き換えるために自分でアノテーションを書いたり、Dubbo を呼び出すための API を書いたりする必要はありません。なぜなら、書いてみても初心者の中には理解できなかったり慣れなかったり、どんな落とし穴があるかも分からない人もいるからです。したがって、オリジナルのダボを使用すると、ユーザーにとってはさらに不便になる可能性があります。

3 番目の問題は、複数のフォームへの柔軟なアクセスとサポートです。私たちは Dubbo に強く依存しており、Dubbo をサポートする必要がありますが、HTTP などの他の形式もサポートする必要があります。ただし、アクセスする前に、アクセスの柔軟性の問題を考慮する必要があります。

まずはダボ法をご紹介します。 Dubbo に客観的にアクセスするには、主に 3 つの方法があります。

最初の方法はアノテーションです。 @DubboReference によって提供される一般パラメータパラメータを使用して、メソッド粒度のルーティングを実現するルーティングターゲットを設定します。中央のパラメータにはルーティング情報が記述されており、パラメータはDubboから提供された共通パラメータを当社に転送するものです。

普通にこの情報を書いても意味がないのでダボは何も処理しません。しかし、ハイウェイ SDK を導入したので、これを書いた後、解析して Dubbo のリクエストをインターセプトし、parameters でパラメータを取得してルーティング処理を行うことになりますが、この形式は実際には Dubbo の使用方法を変更するものではありません。

2 番目のタイプは、構成センターによって指定されます。 たとえば、アクセス方法を完全に置き換えることができる Apollo の構成センターを使用します。SDK がサポートできる限り、パラメータ情報も構成センターで構成できます。実際、このメソッドのコードは完全に非侵入的です。つまり、ネットワークを通過する前後で違いはありません。しかし、最終的には、私たちのビジネスはこの方法を好まないことがわかりました。第一に、人々は Apollo を使用することを好まなかったし、第二に、理解するのが難しかったのです。初心者がこのコードを見ると、ローカルインターフェイスを調整していると思うでしょう。

3 番目のタイプはスレッド指定です。 スレッドでルーティング情報を指定して再度呼び出すと、この呼び出しではそのルートが使用されます。再度呼び出されると、ローカルに転送されます。 Dubbo の拡張機能ではスレッドに基づいているため、呼び出しが完了した後にスレッド情報がクリーンアップされます。したがって、複数回呼び出したい場合は、複数回記述する必要があることに注意してください。何度も書きたくない場合は、上記の方法で現在のBeanに注入すれば上海にルーティングされます。

次に、高速道路のアーキテクチャを紹介します。 先ほどポイントツーポイント方式を紹介しましたが、この方式の欠点は、ホワイトリストの作成がより複雑になることです。現在、高速道路のアーキテクチャは新しいアーキテクチャであるため、ホワイトリストを開く複雑さは軽減されます。

たとえば、上の図に示すように、一番左のノードが上海、一番上のノードが安徽省で、安徽省から上海に行きたいのですが、このとき、中央ゲートウェイはホワイトリストを開く必要があります。開いた後、このリンクを直接渡すことができます。合計で 6 行しかないため、複雑さが軽減されていることがわかります。

上の写真は高速道路の核となる構造図です。

たとえば、山西省クラスタの APP1 が APP2 を調整する場合、上海 APP2 を調整したいのですが、何もしなければデフォルトで山西省クラスタの APP2 が調整されます。 APP を呼び出すときにルーティング情報を追加すると、山西省クラスター APP1 に配置された SDK は、山西省クラスターの Dubbo ゲートウェイへのトラフィックをカットします。

その後、Dubbo ゲートウェイは HTTP プロトコルを通じて統合ゲートウェイに移動し、次に HTTP プロトコルを通じて上海クラスターの Dubbo ゲートウェイに移動します。ここでは、呼び出されたサービス、メソッド、バージョン番号、パラメータなどを含むルーティング情報を取得します。次に、一般化を通じて上海クラスターの APP1 を調整し、最後に戻ってこのクロスネットワーク呼び出しを完了します。

では、なぜ Dubbo Proxy の役割があるのでしょうか? APP1 からユニファイドゲートウェイに直接切り替えてみてはいかがでしょうか?一歩飛ばした方が良いんじゃないでしょうか？それには次の 3 つの理由があります。

この図では APP1 が 1 つだけ描かれていますが、実際には山西クラスター内に多数のコールがあります。数百のアプリケーションがユニファイドゲートウェイに直接接続されている場合、ゲートウェイは多くの長いリンクを確立する必要があり、ユニファイドゲートウェイのリソースは制限されます。

セキュリティの問題のため、セキュリティを確保するために電話をかけるたびにホワイトリストを確認する必要がある場合があります。このとき、Dubbo Proxyを追加するとIPを集約できます。島内の Dubbo Proxy は同じ環境にあるため、やり取りする必要がなく、セキュリティの問題を考慮する必要もありません。 Dubbo Proxy がゲートウェイを要求すると、ゲートウェイとユニファイドゲートウェイの間にリンクが 1 つしかないため、IP が統合されます。

もう1つは機能の集約で、後からバージョンアップが必要になった場合、SDKを更新するとアプリケーションごとにバージョンアップする必要があり、業務のバージョンアップを進める必要があり、手間がかかります。したがって、すべてのアップグレード機能を 1 つのアプリケーションにまとめ、SDK をアップグレードする必要もなく、ビジネス機能に影響を与えないようにすることを目指しています。もちろん、SDK はルートの切り替えという 1 つのことを実行するため、基本的に更新する必要はありません。

したがって、ビジネスにとっても解放的なものになります。それは機能的なメリットとして理解しています。このモデルは分散ランタイムと呼ばれ、現在非常に人気があります。これは、一般的で面倒な操作の一部をパブリックの独立したプロセスに置き、ビジネス向けの SDK を非常に純粋なものにする Dapr として理解できます。

さらに、なぜ HTTP プロトコルを使用するのでしょうか?また、これはあまり効率的なプロトコルでもありません。 Dubbo プロトコルの Dubbo2 は、実際には比較的合理化されていますが、いくつかの共通フォーマットを除き、すべてデータです。この場合、パフォーマンスを高速化するために、後で HTTP をアップグレードすることを実際に検討できます。

現在 HTTP プロトコルが使用されている理由は、HTTP プロトコルが標準プロトコルであるためです。 ここでは 1 つだけ示していますが、多くのデバイスが通過する可能性があります。 HTTP プロトコルには障害はありませんが、Dubbo プロトコルを使用する場合は、やはり障害を 1 つずつ通過する必要があります。

このアーキテクチャを実装するには、Dubbo 自体を直接使用することはできません。 Dubbo はクロスネットワーク機能を提供していないため、遭遇する問題を Dubbo レベルで解決する必要があります。

動的 IP スイッチングに関しては、Dubbo が実際にサポートしていますが、この機能は比較的新しいため、いくつかの問題が発生します。 Dubbo2 は当初サポートしていませんでしたが、Dubbo3 ではサポートするなど、サポートレベルは部分的です。さらに、いくつかのバグも発生します。

HTTP の 404 拡張に関しては、インターフェイスを調整する必要があるが、そのインターフェイスが存在しない場合、404 エラーがフロントエンドに返されます。たとえば、トラフィックを APP1 から Dubbo Proxy に切り替えると、Dubbo Proxy は実際には Dubbo のアプリケーションであり、Dubbo の空のアプリケーションである Dubbo jar パッケージが導入されます。このトラフィックが Dubbo のゲートウェイに到達しても、ゲートウェイはそれを認識できず、その機能はトラフィックを転送することです。現時点では、この拡張機能を追加する必要があります。

次に、トンネルメカニズムを紹介します。 トンネルメカニズムの機能は、ネットワークの複雑さを保護し、中間プロトコル変換を保護し、統一された透過的な呼び出し方法をユーザーに提供することです。

中間HTTPプロトコルのボディはオリジナルのボディを持ちます。梱包後、開梱し、一般化して調整します。現時点では、トンネルによってこれらの違いを保護できます。

さらに、トンネルメカニズムでは Dubbo プロトコルのサポートが強化されています。たとえば、APP1 とローカル APP 3 が最終的に APP2 に転送されると、バイナリストリームが同じであることがわかります。何もしていないので、ただ梱包してやっと開梱しました。途中の小さなルーティング情報を除いて、他はすべてまったく同じです。

このメカニズムの利点は、基本的に Dubbo のすべての機能をサポートできることです。ただし、トークンやネットワーク関連のメカニズムなど、個別のケースもいくつかあります。

これからの計画

ネットワーク階層型アーキテクチャを借りて、高速道路についていくつかの計画を立てました。

最初の層は物理ネットワーク層です。ポートを開くことだと私は理解しているので、これは実際には私たちとはほとんど関係がありませんが、これだけ多くのことをオープンした後、この問題をスピードアップするためにいくつかの経験や方法論を要約することができます。

2 番目の層は通信プロトコル層の高速化です。中間の HTTP プロトコル転送を高速化できます。たとえば、Triple プロトコルも HTTP2 に基づいてネットワークデバイスを識別し、問題を解決します。したがって、通信プロトコル層での調査と最適化も検討できます。

3 番目の層は言語層のコンパイルの高速化です。私たちも以前にGraalVMを調査し、実際に試してみたことがあります。まだ実装されていませんが、コンパイルの高速化が可能です。特にゲートウェイ層はトラフィックが大きいのが特徴ですが、各トラフィックは非常に小さく、言語自体のパフォーマンス要件が比較的高くなります。 Go で実装すると、実際にさらに高速化されるでしょう。

4層目はフレームワーク層の機能アップグレードです。ミドルウェア層でも多くのことを行っています。

5 番目の層は、一般的なタスクのスケジューリングとオーケストレーションです。実際には、通話は a ～ b ～ c ～ d ～ e のように多くのノードを経由するため、ビジネスがより複雑になるにつれて、より多くのルートが存在する可能性があります。例えばaをcに、cとdを合わせてdにするなども将来的には予定されています。

レベル 6: カスタマイズされたタスクのスケジュール設定とオーケストレーション。

レイヤ 7: 監視、警報、可観測性。

レイヤ 8: 標準、プロセス、セキュリティ。

最後にまとめをします。

なぜこのプロジェクトをやりたいのですか？以前のソリューションは数多くあり、コストは比較的高かったです。したがって、もっと公共的なものを考えた上でこの計画を推進していくという統一的な計画が必要であると考えております。現在、多くのアプリケーションを接続し、社内の政務データをネットワーク上で統合したソリューションとなっています。

実現したい効果やプロジェクトの仕組み、今後の予定については、すでにご紹介したとおりですので割愛させていただきます。

オープンソースとコミュニティの協力に焦点を当てましょう。先ほどのソリューションは実際に弊社社内でも使用されており、Dubboもかなりカスタマイズされています。通常、開発にはプライベートバージョンを選択しますが、オープンソースでありたいため、最初に Dubbo コミュニティと連絡を取り、オープンソースレイヤーで実装できるかどうかを確認しました。一方で、コミュニティはこれらの機能をレビューし、セキュリティ制御を行うのに役立ちます。一方で、私たちが行っている活動の一部、特に公共的なものを取り出して、コミュニティに還元することもできます。