記事ディレクトリ
1. 需要
ビジネスニーズが高まる中、当初は各プロジェクトが独立して開発されており、フロントエンドとバックエンドは分離しているものの、各プロジェクトは互いに干渉することはありません。その後、特定の要件により、複数のプロジェクトのデータを相互にインターリーブして取得する必要があります。
当初のアイデアは、複数のデータ ソースを統合することでした。
例
データベース DBa、DBb、DBc に対応するプロジェクト A、B、C の 3 つがあり、プロジェクト A はデータベース DBa と DBc を同時に操作する必要があります。
このとき、RPC フレームワークを呼び出すのが理想的です。
環境/バージョン
IDEA2022.3.2
java11
SpringBoot 2.7.12-SNAPSHOT
Nacos 2.2.2
注: SpringBoot3.x 以降を使用する場合は、jdk17 以降を使用する必要があります。そうしないとエラーが発生します。
二つ、気づいてください
2.1. RPC とは何ですか?
RPC の正式名は Remote Procedure Call で、リモート プロシージャ コールと訳されます。これは、異なるプロセスまたはコンピュータ間の通信に使用されるコンピュータ ネットワーク通信プロトコルであり、リモート メソッドをローカル メソッドであるかのように呼び出すことができます。
別のコンピューター上の関数またはメソッドを呼び出す必要があるアプリケーションがあるとします。通常は、ネットワーク プログラミングを通じて手動で要求を送信し、応答を受信する必要があります。RPC を使用すると、ローカル関数を呼び出すのと同じようにリモート関数を直接呼び出すことができるため、複雑なネットワーク プログラミングが簡素化されます。
具体的には、RPC 通信プロセス中に、呼び出し元はローカル メソッドを呼び出すのと同じようにリモート サーバーにリクエストを送信します。リクエストには、呼び出されるメソッド名とパラメータ リストが含まれます。リクエストを受信すると、リモート サーバーはリクエストを解析し、対応するメソッドを呼び出し、実行結果を呼び出し元に返します。呼び出し元は応答を受信した後、ローカル関数のように結果を処理できます。
平たく言えば、RPC は、電話中に相手に何をする必要があるかを伝え、完了後に相手が結果を教えてくれるようなものです。この方法では、自分でタスクを完了する必要はなく、このプロセスでは、完了する必要があるタスクと結果のみを気にする必要があり、具体的な実装方法を気にする必要はありません。
RPC は、マイクロサービス アーキテクチャのサービス コール、Hadoop のリモート プロシージャ コールなど、分散システムで広く使用されています。分散システムをよりシンプル、柔軟、スケーラブルにすることができます。
2.2. ダボとは何ですか?
背景
Dubbo 誕生の背景は 2011 年にまで遡ります。大きな挑戦となりました。こうした状況の中で、Dubbo が誕生しました。
Dubbo はもともと Alibaba のエンジニアによって提案および開発されました。その目的は、Alibaba の社内分散システムに高性能で信頼性が高く、スケーラブルな RPC フレームワークを提供し、Alibaba が分散サービス アーキテクチャをより適切に構築し、サービス ガバナンスを実装できるようにすることです。
その後、Dubbo が徐々に成熟し、アリババ内で広く使用されるようになると、アリババはオープンソース化を決定し、2011 年末に最初のバージョンを正式にリリースし、続いて 2012 年と 2015 年にバージョン 2.0 と 2.5 をリリースし、2019 年にバージョン 2.7 をリリースしました。Dubbo のオープン ソースと継続的な更新と反復により、ますます多くのユーザーと開発者が参加するようになり、徐々に Java エコシステムで最も人気のある RPC フレームワークの 1 つになりました。
現在、Dubbo は Alibaba、Huawei、Netease などの企業の分散システムで広く使用されており、国内外の主要なインターネット企業やコミュニティによって広く認識され、サポートされています。
2018 年 11 月に、Apache Dubbo が Apache のトップレベル プロジェクトになりました。これは、Dubbo が非常に成熟し、高品質で、活発なコミュニティのオープンソース プロジェクトに発展したことを意味します。Dubbo の追加により、分散システム分野における Apache の地位はさらに強化され、分散システムの開発と推進に多大な貢献を果たしました。
効果
Dubbo には主に 3 つのコア モジュールが含まれています。
プロバイダー (サービスプロバイダー): サービスを公開するアプリケーションとサービスを提供する方法。
Consumer (サービスコンシューマ): リモートサービスを呼び出すアプリケーションおよびサービスを利用するメソッド。
レジストリ (サービス レジストリ): サービスの登録と検出のための管理センター。
Dubbo フレームワークのワークフローは次のとおりです。
1. サービスプロバイダーは、提供するサービスを開始し、登録センターに登録します。
2. サービス消費者は、必要なサービスの登録センターを開始し、登録します。
3. 登録センターは、利用可能なサービスのリストをサービス利用者に返します。
4. サービスコンシューマはリモートサービスを呼び出します。
5. リモート サービス プロバイダーはリクエストに応答し、結果をサービス コンシューマに返します。
6. サービス利用者は応答を受信し、呼び出しを完了します。
2.3. ナコスとは何ですか?
Nacos は、クラウドネイティブの概念に基づいた動的なサービス検出、構成管理、サービス ガバナンス プラットフォームであり、2018 年に Alibaba オープンソース チームによってオープンソース化されました。これは主に、分散システムにおけるサービスの登録、検出、構成管理、DNS サービスの問題を解決します。
Nacos は次のコア機能を提供します。
1. サービスの登録と検出: Nacos は、サービス プロバイダーがサービスを自動的に登録し、サービス インスタンスの健全性ステータスを Nacos サーバーに報告するのに役立ちます。また、サービス コンシューマーは、Nacos を通じて利用可能なサービス インスタンスをクエリできます。
2. 構成管理: Nacos は集中構成管理機能を提供し、動的構成、バージョン管理、グレースケール リリース、監視などの機能をサポートし、分散システムで構成情報を簡単に管理できます。
3. サービス ルーティングと負荷分散: Nacos は、サービス プロバイダーとコンシューマ間のトラフィック管理とルーティング ルールの動的な更新、および複数の負荷分散戦略をサポートします。
4. DNS サービス: Nacos は DNS サービスのプロビジョニングをサポートしており、他のサービス検出コンポーネントを必要とせずに DNS を使用してサービスを検出できます。
注意: Dubbo 公式 Web サイトのデフォルトの登録センターは Zookeeper であり、この記事で使用されている登録センターは Nacos です。
3. 通常の SpringBoot プロジェクト統合マイクロサービス コンポーネント スキーム (著者は 2 種類を提供)
オプション 1 (推奨)
著者のようなプロジェクト (要件を参照) は、最初からマイクロサービス アーキテクチャを選択するのではなく、開発によりマイクロサービス コンポーネントを使用するように進化しました。この部分を見てください。それ以外の場合は、オプション 2 を参照してください。
1. Maven の依存関係をインポートします (コンシューマーとプロバイダーは同じです)
<!--nacos-->
<dependency>
<groupId>com.alibaba.nacos</groupId>
<artifactId>nacos-client</artifactId>
<version>2.2.2</version>
</dependency>
<!-- dubbo -->
<dependency>
<groupId>org.apache.dubbo</groupId>
<artifactId>dubbo-spring-boot-starter</artifactId>
<version>3.2.0-beta.6</version>
</dependency>
アノテーション @EnableDubbo をスタートアップ クラスに追加します。
2. application.yml ファイルを構成する (コンシューマ)
server:
port: 8102
spring:
cloud:
nacos:
server-addr: localhost:8848
dubbo:
consumer:
check: false
application:
name: dubbo-springboot-demo-consumer
protocol:
name: dubbo
# 设置为-1表示自动配置可用端口
port: -1
registry:
address: nacos://127.0.0.1:8848
application.yml ファイル (プロバイダー) を構成する
server:
port: 8105
spring:
cloud:
nacos:
server-addr: localhost:8848
dubbo:
application:
name: dubbo-springboot-demo-provider
protocol:
name: dubbo
port: -1
registry:
address: nacos://127.0.0.1:8848
3. 統一インターフェースクラス (コンシューマーとプロバイダーのパッケージ名は同じである必要があるため、パッケージ名に注意してください)
package com.example.astar.component;
public interface DemoService {
String sayHello(String name);
}
4. プロバイダーインターフェース (インターフェースに @DubboService アノテーションを追加)
package com.example.astar.service.Impl;
import com.example.astar.component.DemoService;// 注意包名
import org.apache.dubbo.config.annotation.DubboService;
@DubboService
public class AstarServiceImpl implements DemoService {
private static int flag = 0;
@Override
public String sayHello(String name) {
String message = "你好啊！ " + name + " =========》 " + flag++;
return message;
}
}
5. 消費者通話インターフェース
package com.example.astar.controller;
import com.example.astar.component.DemoService;//注意包名
import org.apache.dubbo.config.annotation.DubboReference;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
@RequestMapping("/user")
public class UserController {
@DubboReference
private DemoService demoService;
@GetMapping("/1")
public String hello() {
String result = demoService.sayHello("Astar");
String re = "Receive result ======> " + result;
System.out.println(re);
return re;
}
}
6. 通話が成功しました
これら 2 つのプロジェクト (コンシューマとプロバイダ) を開始します。コンシューマは check: false で構成されているため、どちらのプロジェクトを最初に開始しても問題ありません。コンシューマのポートは 8102 です。アクセスしてみましょう
http://localhost:8102/user/1
下記参照
親切なヒント:
DemoService の完全修飾パッケージ名は import com.example.astar.component.DemoService です。これは、コンシューマとプロバイダ間のブリッジが同じインターフェイスから来ていることを意味します。クラスを実現するには、プロジェクト内にまったく同じインターフェイスを作成する必要があります。気にしないでください。プロバイダー インターフェイスとコンシューマー インターフェイスのパッケージ名が異なる場合、呼び出しは失敗します。
人間の言葉で言えば、たとえ 2 つのプロジェクトが同じファイルの下にないとしても、どうして同じクラスを使用できるのでしょうか? ここで、クラス自体とパッケージ名が同じであれば、Dubbo はそれらを同じものとみなします。
オプション II
このソリューションは、最初にマイクロサービスのフレームワークを使用することを決定したプロジェクトに基づいており、通常は次のようないくつかのサブモジュールに分割します。
インターフェースモジュール
手順について話すのが面倒なので、最初の解決策とほぼ同じですが、違いはパブリック モジュール インターフェイスのインポートです。
コンシューマとプロバイダにサブモジュールを追加するだけです。
<dependency>
<groupId>org.apache.dubbo</groupId>
<artifactId>dubbo-samples-spring-boot-interface</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
注意: パッケージ化する際、サブモジュールのインポートされた部分も一緒にパッケージ化されます。心配しないでください。通常どおりに使用でき、残りの部分は変更されません。
終わり
広大な人類の海はまだまだ先が長く、
修煉に集中してこそ美しくなれるのです。
着実に一歩を踏み出し、
真実を見極めるために花が咲くのを待ちましょう。