1. フェーンの導入
Feign は、マイクロサービス アーキテクチャ内のサービス間の通信を簡素化するための宣言型HTTP クライアント フレームワークです。これは Spring Cloud フレームワークの一部であり、HTTP リクエストを定義して呼び出すためのエレガントで使いやすい方法を提供することを目的としています。
Feign の設計目標は、サービス間の通信をより簡単かつ直感的にすることです。通常、マイクロサービス アーキテクチャでは、あるサービスが別のサービスの API を呼び出して、データを取得したり操作を実行したりする必要があります。従来の方法では、HTTP リクエストを手動で作成し、リクエストとレスポンスを処理する必要がありましたが、Feign の登場によりこのプロセスが簡素化されました。
Feignを利用すれば、呼び出すサービスのAPIを記述するインターフェースを定義し、アノテーションでリクエストやレスポンスの処理方法を設定するだけで済みます。Feign は、インターフェイス定義に従って利用可能な HTTP リクエストを自動的に生成し、そのリクエストをターゲット サービスに送信し、応答を適切なオブジェクト タイプに変換して返します。
Feign には次の機能と利点があります。
- 宣言型 API 定義: インターフェースを定義するだけで、基礎となる HTTP の詳細に注意を払うことなく、サービス間の通信を明確に記述することができます。
- 組み込みの負荷分散サポート: Feign は Spring Cloud のサービス登録および検出メカニズムと統合されており、負荷分散を自動的に実装し、複数のインスタンスからのサービス呼び出しを簡単に処理できます。
- リクエストと応答の自動シリアル化と逆シリアル化: Feign は、リクエストと応答のシリアル化と逆シリアル化を自動的に処理できるため、オブジェクト指向の方法でデータを操作できます。
- サービスのヒューズと電流制限の統合: Feign は、Spring Cloud のヒューズ (Hystrix など) および電流リミッター (Sentinel など) と統合されており、サービスのヒューズと電流制限機能を提供して、システムの安定性と信頼性を向上させることができます。
- 拡張が簡単: Feign は、カスタム構成とインターセプターを通じてその動作を拡張およびカスタマイズできるプラグイン可能なメカニズムを提供します。
2番目に、Feignの使用
ここでは、説明のための例として pig プロジェクトを取り上げます。プロジェクトアドレス: https://gitee.com/log4j/pig
1. プロジェクトモジュールの説明
pig §── pig-auth -- 認可サービス提供 [3000] └── pig-common -- システム共通モジュール ├── pig-common-bom -- グローバル依存関係管理制御 ├── pig-common-core --共通ツールコアパッケージ §── pig-common-datasource -- 動的データソースパッケージ ├── pig-common-job -- xxl-job パッケージ ├── pig-common-log -- ログサービス ├── pig-common -mybatis -- mybatis 拡張パッケージ ├── pig-common-seata -- 分散トランザクション ├── pig-common-security -- セキュリティ ツール ├── pig-common-swagger -- インターフェース ドキュメント ├── pig -common- feign -- feign 拡張パッケージ └── pig-common-xss -- xss セキュリティ パッケージ ├── pig-register -- Nacos Server[8848] って いつ── pig-gateway -- Spring Cloud Gateway[9999] └── pig -upms -- 一般的なユーザー権限管理モジュール └── pig-upms-api -- 一般利用者権利管理システム公開 API モジュール └── pig-upms-biz -- 一般利用者権利管理システム業務処理モジュール [4000] └── pig-visual └── pig-モニター -- サービス監視[5001] §── pig-codegen -- グラフィカル コード生成[5002] §── pig-sentinel-dashboard -- トラフィック高可用性[5003] └── pig-xxl-job-admin - -分散タイミングタスク管理プラットフォーム [5004]
2. 偽のクライアントの定義
(1) 偽の依存を導入する
pig-upms-api モジュールと pig-upms-biz モジュールの両方で、偽の依存関係を導入する必要があります。
<!--feign 注解依赖-->
<dependency>
<groupId>com.pig4cloud</groupId>
<artifactId>pig-common-feign</artifactId>
<optional>true</optional>
</dependency>
(2) 場所を定義する
コードからわかるように、Feign のクライアントは pig-upms-api モジュールで定義されています。Feign のクライアントを pig-upms-api モジュールで定義するのは一般的な設計パターンです。このモードの目的は、Feign のクライアント インターフェイスを API モジュールの一部として定義し、pig-upms-api 依存関係を導入することで他のモジュールが API を使用できるようにし、pig-upms-biz モジュール (一般的な) との接続を実現することです。ユーザー (権利管理システムのビジネス処理モジュール間の通信)。
(3) 偽装クライアントの定義
RemoteUserService を例に挙げます。
//标识这是一个Feign客户端接口,contextId指定客户端的id,用于和其他客户端区分
//value="pig-upms-biz" 指定了要调用的服务名称
@FeignClient(contextId = "remoteUserService", value = ServiceNameConstants.UMPS_SERVICE)
public interface RemoteUserService {
//通过用户名查询用户、角色信息
//@GetMapping注解指定了要调用的HTTP GET请求的路径。这里是 /user/info/{username}
//headers指定了请求的头部信息,这里HEADER_FROM_IN的值是"from=Y"
@GetMapping(value = "/user/info/{username}", headers = SecurityConstants.HEADER_FROM_IN)
R<UserInfo> info(@PathVariable("username") String username);
//通过手机号码查询用户、角色信息
@GetMapping(value = "/app/info/{phone}", headers = SecurityConstants.HEADER_FROM_IN)
R<UserInfo> infoByMobile(@PathVariable("phone") String phone);
//根据部门id,查询对应的用户 id 集合
@GetMapping(value = "/user/ids", headers = SecurityConstants.HEADER_FROM_IN)
R<List<Long>> listUserIdByDeptIds(@RequestParam("deptIds") Set<Long> deptIds);
}
実際、この Feign クライアントはSysUserControllerにリクエストを送信します。
(4) 他のモジュールでのテスト
たとえば、Feign を使用して pig-codegen モジュールでインターフェイス呼び出しを行う場合は、pig-upms-api で Feign クライアントを定義するため、最初に codegen モジュールに pig-upms-api 依存関係を導入する必要があります。
<!--upms api、model 模块-->
<dependency>
<groupId>com.pig4cloud</groupId>
<artifactId>pig-upms-api</artifactId>
</dependency>
テスト コントローラーを作成します。
@RestController
@RequiredArgsConstructor //自动生成构造方法,在生成FeignDemoController会将remoteUserService传入
@RequestMapping("/feignDemo")
public class FeignDemoController {
//注入Feign客户端接口 RemoteUserService
//定义为final 确保在实例化后变量不会发生意外改变
private final RemoteUserService remoteUserService;
@Inner(value = false)
@GetMapping("/test")
public R<UserInfo> test() {
//假设传入的用户名是 admin
String username = "admin";
//调用feign中的info方法
return remoteUserService.info(username);
}
}
サービス テストを開始すると、管理者ユーザーの情報が正常に取得されたことがわかります。
補足:2つの注入法の理解について:
プロパティを挿入するときは、2 つの方法で注釈
remoteUserService
を使用できます。2 つの方法には次のような違いがあります。@RequiredArgsConstructor
@Autowired
@RequiredArgsConstructor
: クラスでアノテーションを使用すると@RequiredArgsConstructor
、コンストラクターが自動的に生成され、それがremoteUserService
パラメーターとして渡されて注入されます。このアプローチは、コンストラクターを通じて依存関係を注入することです。アノテーションを使用すると、@RequiredArgsConstructor
コードが簡素化され、コンストラクターを手動で作成する作業が軽減されます。
@Autowired
: アノテーションがプロパティで使用されると@Autowired
、対応する型のインスタンスがプロパティに自動的に挿入されます。この方法は、フィールドを通じて依存関係を注入することです。Spring フレームワークは自動的にスキャンして、RemoteUserService
型に一致するインスタンスを見つけて、それをremoteUserService
プロパティに挿入します。依存関係の注入はアノテーションを使用して@Autowired
簡単に実行できますが、必要なインスタンスが存在し、一意であることを確認する必要があります。一般に、これら 2 つの注入方法の効果は同じであり、両方ともプロパティ
RemoteUserService
に注入されます。remoteUserService
どちらを使用するかは、プロジェクトの好みと規則によって決まります。を使用すると@RequiredArgsConstructor
より簡潔なコードを提供できますが、 を使用すると@Autowired
より柔軟で、よりさまざまなシナリオに適応できます。