[Apifox 新規サポート] Dubbo プロジェクトを管理およびデバッグするにはどうすればよいですか?

1. Dubbo3の紹介

Dubbo の使用方法については紹介しません。Dubbo についてのみ説明し、その後で Dubbo サービスをテストする方法について説明します。 2.x の古典的なアーキテクチャを維持することに加えて、Dubbo3 はマイクロサービスのプロセス通信を主な役割としており、豊富なサービスガバナンス機能を使用してマイクロサービスサービスクラスターをより適切に管理および制御します。機能はまだあります。
Dubbo の呼び出しプロセスは次のとおりです。
ここに画像の説明を挿入します全体のプロセスは次の 11 ステップに大別できます (デフォルトの通信Netty メソッドの概要は以下にまとめられています。コンテンツ):

まずサービスプロバイダーが開始され、次にサービスをサービス登録センターに登録します (この時点で、サービスのホスト、ポート、その他のメタデータが登録されています) netty サービスを除くセンター情報に加えて、@DubboService でマークされたインターフェイスもサービスとして登録されます);
サービス利用者は定期的にサービスプロバイダーのリストを取得します。
サービスコンシューマがサービスプロバイダインターフェイスを呼び出す必要がある場合、プロバイダのインターフェイスをリモートで直接呼び出すことができないため、動的プロキシオブジェクトを生成し、このプロキシオブジェクトを通じてリモートインターフェイスを呼び出す必要があります。
プロキシオブジェクトを生成した後、クラスタ層に進み、そこでサービスプロバイダーリストのデータが取得され、現在呼び出すことができるサービスプロバイダーが検出されます。
その後、クラスタは指定されたアルゴリズムに基づいて負荷分散を実行し、呼び出されるサービスプロバイダを選択します;
Exchange は、指定されたプロトコル形式に従って要求データをカプセル化し、それを要求要求にカプセル化します。
リクエストがカプセル化された後、リクエストはネットワーク通信フレームワーク (TCP、長い接続、誰もが知っている) を通じて送信されます。 ;
通常、サービスプロバイダーにはネットワーク通信フレームワークがあり、指定されたポート番号をリッスンし、リクエストを受信した後にリクエストを逆シリアル化します。
逆シリアル化後、Exchange に従って指定されたプロトコル形式に従ってリクエストが解析されます。
10. 次に、サービスプロバイダーの対応するインターフェイスが、ダイナミックプロキシオブジェクトを通じて呼び出されます。

2. Dubboインターフェースのデバッグ方法一覧

ネット上で見つかる Dubbo サービスのデバッグ方法はおそらく 2 つだけですが、強いて言うなら次の 3 つが挙げられます。

Telnet
ジェイメーター
テスト用にサービスのコンシューマ側を作成する

彼についての私の個人的な感情について話しましょう。

Telnet ツールは使い方が非常に簡単です。Windows 自体に搭載されています。コマンドを直接入力して、対応するサービスをテストすることができます。ただし、登録センターと組み合わせることはできません。私の個人的な使用の観点からは、サービスガバナンスは、実際の開発から切り離されることがよくあります。重要なのは視覚化ではありません。！！
Jmeter: Jmeter は間違いなく強力なテストツールです。Dubbo 自体をテストすることはできませんが、github にあるオープンソースの Jmeter-plugins-for-apache-dubbo プラグインを使用できます。何が残念ですか?ただし、3.x には対応しておらず、公式 Web サイトでは次のように説明されています (もちろん私もテストしました)。
うーん、ダボサービスのコンシューマ側を書いてテストしてみよう、これ…二つのサービス間の処理はテスト前に書いたほうがいいですよね？私のコーディング能力はまだそれほど高くないので、部分を書いて部分をテストすることを好みますが、複数人での開発ではテストが容易ではありません。

しかし、私は幸運でした。昨夜は何もすることがなかったので、他の人の技術的なブログ投稿を読み、見た内容を確認したいと思いました。
ここに画像の説明を挿入します最後にその中で言及されていた内容を見てください。夜ご覧のとおり、今日時間があるときにテストした後、これを共有しました:
(最近サポートされるはずです。apifox のバージョンイテレーションが見つかりません。最新のものは 2.3 です) .24. 、公式 Web サイトには、apifox をサポートするには >=2.3.10 が必要であると記載されています）

何はともあれ、まずは使ってみましょう。

3. Apifox デバッグ Dubbo プロジェクト

テストに重点を置き、テスト用の登録センターとして nacos を使用します。Apifox で Dubbo サービスをデバッグする方法:

サービスプロバイダーコード

設定ファイル

server:
  port: 8082


spring:
  application:
    name: dubbo-provider-test

  datasource:
    password: 123456
    username: root
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/mybatisplus

mybatis-plus:
  type-aliases-package: com.example.mp1.entity
  mapper-locations: classpath:/mapper/**/*.xml
  global-config:
    banner: false
    db-config:
      id-type: assign_id
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
dubbo:
  protocol:
    name: dubbo
    port: -1
  application:
    name: dubbo-test
  registry:
    address: nacos://127.0.0.1:8848
    username: nacos
    password: nacos
    register: true

nacos:
  config:
    server-addr: 127.0.0.1:8848

サービスインターフェース

public interface DubboTestService {
    
    
    User getUserById(Long id);
}

サービスの実装

@DubboService
@Service
public class DubboTestServiceImpl implements DubboTestService {
    
    

    @Autowired
    UserService userService;

    @Override
    public User getUserById(Long id) {
    
    
        User user = userService.getById(id);
        return user;
    }

}

サービス開始後のnacosサービス一覧は以下の通りです。
ここに画像の説明を挿入します

アピフォックステスト

まず、Dubbo サービスのテストに使用するモジュールである Dubbo プロジェクトを作成します。
ここに画像の説明を挿入します Dubbo アプリケーションデータをインポートします。このアプリケーションは、構成ファイルで構成したアプリケーションを指します。 . 端的に言えば、netty サービスのメタデータ情報は、最終的には nacos 設定センターのサービス名に格納されます。

ここに画像の説明を挿入します
アプリケーション情報を入力してインポートします

ここに画像の説明を挿入しますそうすれば、インターフェイス管理で対応するサービスを確認することができ、簡単です。

ここに画像の説明を挿入しますテストするときは、リモート呼び出しを行うために使用されるため、対応するサービスの ip:port を入力することを忘れないでください。それをカプセル化し、リクエストデータを netty サービスに書き込み、最終結果を返します。これは長すぎませんか?それはコミュニケーションの仕事ですか?

ここに画像の説明を挿入しますそれは素晴らしいことではないでしょうか？

登録センターを使用しない場合はどうなりますか?テストすることもできますが、サービスインターフェイスとメソッドを自分で作成し、サービスの ip:port を入力してからテストする必要があります。このグラフィカルインターフェイスを使用すると、テストがはるかに便利になります。

4. 長時間のデータ送信は精度の低下を引き起こす可能性があります

テーブル内のデータの一部はスノーフレークアルゴリズムによって生成されており、テストしたところ精度が失われていることが判明したため、それについて詳しく調べてみました。
これは、Dubbo がデフォルトでシリアル化プロトコルとしてヘシアンを使用するためであり、ヘシアンは長整数データをシリアル化するときに精度の低下を引き起こすためです。

テストをお見せしましょう:
見てください、テーブルにこのレコードがあります。最初の列は ID です:
ここに画像の説明を挿入しますここで、次のようにします。 a サービステスト:
元の 1710123046640713730 が 1710123046640713728 になり、2 が欠落している、つまり精度が失われていることがわかります。

解決策:

基本的に、精度が失われないように String 型に変更することで問題を解決します。
シリアル化方法をカスタマイズするか、精度の損失を引き起こさない Dubbo の他のシリアル化プロトコルを使用します。

うーん、これはテストから得られた経験と考えることができます。