スプリングクラウドとスプリングブートの関係

1.1 関係

1.2 バージョン関係

1.3 リストを JSON 文字列に変換する

パブリック クラス テスト {
    public static void main(String[] args) {
        List<String> dataList=new ArrayList<String>();
        dataList.add("12");
        dataList.add("45");
        dataList.add("67");
       String json= StringUtils.join(dataList,",");
       System.out.println("json:"+json);
    }
}

結果：

1.4 springcloudコンポーネントの呼び出し処理

2つのケースプロジェクト

2.1 エンジニアリング構造

2.2 通話関係

2.3 nacos登録の設定

1. nacosの構築と展開

2. vod、eduプロジェクトのnacosを登録する

3. 見る

2.4 fegin+hystrix を使用したコール構成

2.4.1 教育構成

1.コントローラー

2.フェギ傾斜

2.4.2 VOD 構成

2.4.3 テスト

2.5 ヒストリックス監視の使用

2.5.1 設定手順

1.フェギ傾斜

2. 劣化したクラス

3つのゲートウェイの使用

3.1 ゲートウェイの役割

API ゲートウェイの出現の理由は、マイクロサービスアーキテクチャの出現です。通常、異なるマイクロサービスは異なるネットワークアドレスを持ち、外部クライアントはビジネス要件を完了するために複数のサービスインターフェイスを呼び出す必要がある場合があります。クライアントが各マイクロサービスサービスと直接通信する場合通信を行うと、次のような問題が発生します。

(1) クライアントは異なるマイクロサービスを複数回要求するため、クライアントの複雑さが増加します。

(2) クロスドメインリクエストがあり、特定のシナリオでは処理が比較的複雑になります。

(3) 認証が複雑であり、サービスごとに独自の認証が必要となる。

(4) リファクタリングが難しいプロジェクトが反復されると、マイクロサービスの再分割が必要になる場合があります。たとえば、複数のサービスを 1 つに結合したり、1 つのサービスを複数に分割したりできます。クライアントがマイクロサービスと直接通信する場合、リファクタリングの実装は困難になります。

(5) 一部のマイクロサービスでは、ファイアウォールやブラウザに適さないプロトコルが使用されている場合があり、直接アクセスが困難になります。

上記の問題は、API ゲートウェイの助けを借りて解決できます。API ゲートウェイはクライアントとサーバーの間の中間層であり、すべての外部リクエストは最初に API ゲートウェイ層を通過します。つまり、API の実装ではより多くのビジネスロジックが考慮されますが、セキュリティ、パフォーマンス、監視は API ゲートウェイによって実行できるため、ビジネスの柔軟性が向上するだけでなく、セキュリティが不足することもありません。