概要概要
Spring Cloudによって構築されたマイクロサービスシステムでは、ほとんどの開発者が内部サービス通信用に公式に提供されているFeignコンポーネントを使用しています。この宣言型HTTPクライアントは非常にシンプルで便利でエレガントに使用できますが、Feignコンシューマーサービスを使用する場合はパフォーマンスが少し低下します。 DubboRPCフレームワークよりも劣っています。
マイクロサービスアーキテクチャでは、ビジネスごとに分割されたマイクロサービスは独立してデプロイされ、独自のプロセスで実行されます。マイクロサービス間の通信は、ショートアンサー通信メカニズムとしてHTTPを使用する傾向があり、ほとんどの場合、RESTAPIが使用されます。この通信方法は非常にシンプルで効率的であり、開発プラットフォームや言語とは関係ありませんが、通常の状況では、HTTPはキープアライブ機能を有効にしません。つまり、現在の接続は短い接続です。短い欠点の欠点接続とは、各リクエストにTCP接続が必要なことです。これにより、効率が大幅に低下します。
REST APIサービスを外部に提供することは非常に良いことですが、内部呼び出しもHTTP呼び出しを使用している場合、パフォーマンスは低いように見えます。SpringCloudが内部サービス呼び出しにデフォルトで使用するFeignコンポーネントは、使用されるHTTPプロトコルです。現時点では、内部サービスとREST APIにRPC呼び出しを外部で使用する場合、これは非常に良い選択です。たまたま、Dubbo SpringCloudがこの選択を提供してくれました。
上記の内容は公式サイトからの抜粋です。
ここで考慮しなければならないもう1つのポイントがあると思います。多くの企業が初期にダボに基づいて多くの低レベルのマイクロサービスを構築してきました。移行にクラウドアーキテクチャを使用するのは比較的面倒です。ダボをクラウドに直接統合できます。
前回の記事では、feignを使用してOrder-serviceからAccount-Serviiceを呼び出す方法を実装しました。この章では、dubboを使用してAccount-Dubboを呼び出す方法を実装し、最後にJMeterを使用してインターフェースのパフォーマンステストを実行します。 2つの間のパフォーマンスのギャップを確認します。
ダボプロデューサーを実現
-
プロジェクト
account-dubboでサービスモジュールをaccount-dubbo確立し、2つのモジュールdubbo-apiとdubbo-providerモジュールを再確立します。 -
で
dubbo-providerポンポンファイル、キー依存ダボ春の雲のを追加します。
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-dubbo</artifactId>
</dependency>
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
「注：Dubboのネイティブjarをここで直接使用することはできません。また、nacosレジストリを導入し、dubboをspringcloudレジストリに登録する必要があります。」
-
dubbo-providerプロジェクトの構成ファイルを変更しますapplication.properties
spring.cloud.nacos.discovery.server-addr = 10.0.23.48:8848
dubbo.application.id = account-dubbo
dubbo.protocol.name = dubbo
dubbo.protocol.port = 20881
dubbo.scan.base-packages = com.javadaily.dubbo.service
dubbo.registry.address = spring-cloud://localhost
spring.application.name = account-dubbo
dubbo.registry.check = false
dubbo.consumer.check = false
dubbo.cloud.subscribed-services = order-service
ここで使用されているようにdubbo.registry.address、ダボはスプリングクラウドのレジストリに登録されています。
-
[
dubbo-apiサービスの追加]インターフェイスで、アカウントサービスインターフェイスとして使用するパフォーマンステストの背面にあります。
public interface AccountService {
AccountDTO getByCode(String accountCode);
}
-
で
dubbo-provider、このインタフェースの実現（...設定を少しMyBatisの）
@Service
public class AccountServiceImpl implements AccountService {
@Autowired
private AccountMapper accountMapper;
@Override
public AccountDTO getByCode(String accountCode) {
AccountDTO accountDTO = new AccountDTO();
Account account = accountMapper.selectByCode(accountCode);
BeanUtils.copyProperties(account,accountDTO);
return accountDTO;
}
}
Spring ServiceNotesネイティブではない@Serviceアノテーションを使用していることに注意してくださいorg.apache.dubbo.config.annotation.Service。
-
では
dubbo-providerメインの起動クラスを追加し、追加EnableDubboのコメントを
@SpringBootApplication
@EnableDubbo
public class AccountDubboApplication {
public static void main(String[] args) {
SpringApplication.run(AccountDubboApplication.class, args);
}
}
-
ダボサービスを開始し、レジストリへの登録が正常かどうかを確認します。
注文サービスの消費者の変更
-
ダボ関連の依存関係を導入する
<!--dubbo-->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-dubbo</artifactId>
</dependency>
<dependency>
<groupId>com.jianzh5.cloud</groupId>
<artifactId>dubbo-api</artifactId>
<version>1.0.0</version>
</dependency>
-
コンシューマー構成ファイルを変更し、dubboの構成パラメーターを増やします
dubbo:
registry:
address: spring-cloud://localhost
cloud:
subscribed-services: account-dubbo
consumer:
check: false
Order-Service外部RPCサービスを提供する必要がないため、レジストリをdubboに構成するだけで済みます。
dubbo.cloud.subscribed-servicesサービス作成者IDの構成により、デフォルトはすべてに登録されている*であり、このオプションが推奨される構成です。
-
消費ロジックを変更し、dubboを使用して呼び出します。
@Slf4j
@RestController
public class FeignController {
@Reference
private AccountService accountService;
@GetMapping("/order/getAccount/{accountCode}")
public ResultData<AccountDTO> getAccount(@PathVariable String accountCode){
AccountDTO accountDTO = accountService.getByCode(accountCode);
return ResultData.success(accountDTO);
}
}
org.apache.dubbo.config.annotation.Referenceダボサービスを導入することにより。
上記の手順で、SpringCloudとDubboの統合が完了しました。自分でテストできます。次に、2つのパフォーマンスの違いを確認します。
性能試験
テスト効果は元のポスターのラップトップでテストされます。効果の違いは、高構成でより明白になります。
構成：Intel Core i5-7200U CPU @ 2.50GHz 2.70GHz 6コア16Gメモリ
テストツール：JMeter5.1
スレッド数：1000
ランプアップ：10
ダボコール効果
| 平均応答時間 | スループット | 最小応答時間 | 最大応答時間 |
|---|---|---|---|
| 488ms | 95.8 /秒 | 16ms | 2970ms |
偽の通話効果
| 平均応答時間 | スループット | 最小応答時間 | 最大応答時間 |
|---|---|---|---|
| 3213ms | 75.1 /秒 | 108ms | 6097ms |
上記のテスト結果から、両者のパフォーマンスのギャップがわかります。feignのパフォーマンスはdubboよりも大幅に遅れています。パフォーマンスを追求するアプリケーションでは、RPC呼び出しにdubboを使用することをお勧めします。
この記事がお役に立てば、
いいね、再投稿、コメントの3つのリンクを考え出すことを忘れないでください。またね！
SpringCloud aliababシリーズの概要：