技術共有

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

1. マイクロサービスとは何ですか?

1. 基本的な考え方

マイクロサービスとは、建築様式(モノリシック アーキテクチャ、垂直アーキテクチャ、分散アーキテクチャ、SOA アーキテクチャとは異なり) アプリケーションは、より小さなプロセス駆動型のサービスに分割されます。

2. マイクロサービスの特徴

1. 軽量: 複雑なシステムやサービスを垂直に分割し、各マイクロサービスは特別な問題の解決に重点を置きます。
2. 低結合: 各分割サービスはコード、リソース、環境の点で互いに独立しており、独立して開発、テスト、展開、保守できるため、システムの安定性に有益です (問題が発生した場合の影響が軽減されます)。が発生する）と拡張（リソースの拡大）リソースの評価がより便利になり、リスクが少なくなります）。
3. クロスプラットフォーム: 異なるマイクロサービスは異なる開発言語を使用し、異なる環境で実行できます。

2. SpringCloudとは何ですか?

1. 基本概念:

スプリングクラウドは、マイクロサービスフレームワークは、さまざまな分散システム ソリューションを提供します。マイクロサービスの開発と展開、サービスの登録と検出、サービス ガバナンス、コンポーネント化によるサービスの運用と保守などの機能を提供します。

2. 一般的に使用されるコンポーネント:

1）春雲Netflix：

エウレカ：登録センター

リボン: 負荷分散

ふり: リモート通話

Hystrix: サービスサーキットブレーカー

ズール/ゲートウェイ：ゲートウェイ

2）Spring Cloud Config: 一元化された構成管理ツール、アプリケーション構成の外部ストレージは、Spring アプリケーションまたは非 Spring アプリケーションに使用できます。

3）Spring Cloud Bus: イベントおよびメッセージ バス。クラスター内の状態変更または構成変更イベントを伝播するために使用されます。

4）Spring Cloud Consul: Docker コンテナとシームレスに統合されたサービス検出および構成ツール。

5）Spring Cloud Security: アプリケーションのセキュリティと認証のサポートを提供するセキュリティ ツールキット。

6）Spring Cloud Sleuth: 分散呼び出しチェーン トレース。Zipkin、HTrace、ELK トレースと互換性があります。

7）Spring Cloud Cluster: リーダー選挙。Zookeeper、Redis、および Consul の抽象化によって実装されます。

8）Spring Cloud Data Flow: ドラッグ アンド ドロップ インターフェイスまたは REST API を通じて簡単に使用できるマイクロサービス オーケストレーション。

9）Spring Cloud Stream: 外部システムに接続するアプリケーションを迅速に構築するための軽量のイベント駆動型マイクロサービス フレームワーク。

10）Spring Cloud Task: バッチ データ処理タスクを完了するアプリケーションを迅速に構築するための短期マイクロサービス フレームワーク。

3. SpringCloud コンポーネントを使用する手順

springcloud チュートリアル - 3. マイクロサービス サーキット ブレーカーのメカニズム、サーキット ブレーカー hystrix の使用方法の詳細説明_Java サーキット ブレーカーの設定方法 - CSDN ブログ

springcloud チュートリアル--4. ゲートウェイの使い方を詳しく解説 zuul_zuul 使い方チュートリアル - CSDN ブログ

1. Hystrix (ヒューズ、ダウングレード、電流制限)

1) それは何をするのですか?

存在する分散システムでは 、サービス ノードに障害が発生した場合、またはネットワークに異常が発生した場合、呼び出し元がブロックされて待機する可能性があります。タイムアウトが長時間に設定されている場合、呼び出し元のリソースが枯渇する可能性があります。これにより、呼び出し側の上流システムでリソースが枯渇し、最終的には次のような結果が得られます。システム雪崩 。サーキットブレーカーはサービス雪崩を効果的に防止できます。

トラフィックが突然増加した場合の一般的なアプローチは次のとおりです。非中核的なビジネス機能サービス低下対策は、コア ビジネス機能の通常のサービスを保護するために採用されますが、コア機能サービスについては、電流制限措置を採用する必要があります。

2) それはクライアント側で起こりますか、それともサーバー側で起こりますか?

サービスサーキットブレーカー:一般的にこれはサーバー側で発生します (呼び出し元がすぐに失敗するようにすることが目的です) サービスがタイムアウトするか異常になると、現実のヒューズと同様にヒューズが発生します。 (場合によっては、特定のサービスの呼び出し時に例外が見つかった場合にすぐに失敗するようにクライアントで構成することもできます)。
サービスの低下: 通常、Web サイト全体のリクエストの負荷を考慮すると、サービスが切断またはシャットダウンされると、サービスは呼び出されなくなります (システムが停止している場合は、サーバー側で設定することもできます)。突然のトラフィックにより、コア機能を保護するためにコア機能がダウングレードされます。

電流制限: 通常はサーバー側で発生します。

3) 使用方法

• メルトダウン:

@EnableCircuitBreaker: アプリケーションで有効化ヒューズ

@HistrixCommand(fallbackMethod="xxxFallback",コマンドプロパティ = {
}): 融合アノテーションがダウングレード アノテーションに追加されます。 commandProperties = {} に融合条件を入力します。特定の融合条件については、ここをクリックしてください。HystrixPropertiesManager クラスチェック。

@HystrixCommand(fallbackMethod = "xxxFallback",commandProperties = {
            //20秒内出现3个请求,失败率为30%,就会触发熔断,30秒内不再发送调用
            // 条件一: 请求数量达到3个
            @HystrixProperty(name = HystrixPropertiesManager.CIRCUIT_BREAKER_REQUEST_VOLUME_THRESHOLD, value = "3"),
            // 条件二: 每20秒一个判断单位
            @HystrixProperty(name = HystrixPropertiesManager.EXECUTION_ISOLATION_THREAD_INTERRUPT_ON_TIMEOUT,value = "20000"),
            // 条件三: 失败率30%
            @HystrixProperty(name = HystrixPropertiesManager.CIRCUIT_BREAKER_ERROR_THRESHOLD_PERCENTAGE, value = "30"),
            // 结果: 熔断后, 30秒内不再请求远程服务
            @HystrixProperty(name = HystrixPropertiesManager.CIRCUIT_BREAKER_SLEEP_WINDOW_IN_MILLISECONDS, value = "30000")
    })

• ダウングレード:

新しい xxxFallbackFactory クラスを作成して FallbackFactory を実装し、create メソッドをオーバーライドします。 create でダウングレード メソッドが定義されます。

@FeignCliend(fallbackFactory=xxxFallbackFactory.class): Histrix は Feign に統合されています

または、フォールバック メソッドをメソッドに直接指定します: @HistrixCommand(fallbackMethod="xxxFallback")

• 制限:

        1、電流制限戦略:

1)、セマフォ電流制限

セマフォは、同時スレッドの数を制御するために使用されます。コンストラクターを介して内部仮想ライセンスの数を指定します。

セマフォ分離テクノロジが使用されている場合、リクエストを受信するたびに、サービス自身のスレッドが依存サービスを直接呼び出します。各スレッドがチェックポイントを通過すると、セマフォの数が 1 つずつ減ります。が 0 の場合、スレッドは通過できますが、フォールバック ロジックが直接実行されて返されます。率直に言えば、これは単なる現在の制限です。

セマフォは次のように理解できます。カウンター、カウンタは現在処理中のリクエストの数をカウントします。カウンタ値が設定値に達すると、後続のリクエストは受け付けられなくなり（またはダウングレードされ）、カウンタ値が設定値未満になるまで待つ必要があります。処理される。

@HystrixCommand(
 commandProperties= {
   @HystrixProperty(name="execution.isolation.strategy", value="SEMAPHORE"),
   @HystrixProperty(name="execution.isolation.semaphore.maxConcurrentRequests", value="20")
 },
 fallbackMethod = "errMethod"
)

2)、スレッドプールの電流制限

@HystrixCommand(
    commandProperties = {
            @HystrixProperty(name = "execution.isolation.strategy", value = "THREAD")
    },
    threadPoolKey = "createOrderThreadPool",
    threadPoolProperties = {
            @HystrixProperty(name = "coreSize", value = "20"),
            @HystrixProperty(name = "maxQueueSize", value = "100"),
            @HystrixProperty(name = "maximumSize", value = "30"),
            @HystrixProperty(name = "queueSizeRejectionThreshold", value = "120")
    },
    fallbackMethod = "errMethod"
)

ここで注意してください:javaスレッドプール内でスレッド数が超過した場合coreSize、キューがいっぱいの場合は、スレッド作成リクエストが最初にキューに入ります。スレッドの数がその数に達するまで、スレッドは作成され続けます。maximumSize 、そして拒否戦略を採用します。ただし、hystrix によって構成されたスレッド プールには追加のパラメータがあります。queueSizeRejectionThreshold、もしqueueSizeRejectionThreshold < maxQueueSize、キューの数が次の数に達しましたqueueSizeRejectionThreshold拒否戦略を採用するため、maximumSize失敗した。もしqueueSizeRejectionThreshold > maxQueueSize、キューの数が次の数に達しましたmaxQueueSize時間、maximumSizeが有効な場合、システムはその数に達するまでスレッドの作成を続けます。maximumSize。

      2. セマフォ電流制限とスレッド プール電流制限の違い:

1) パフォーマンス レベル: セマフォは元のスレッドを使用し、パフォーマンスの消費が低くなります。

2) システム安定性レベル: スレッド プールは分離されており、問題自体が他のスレッド プールに影響を与えることはありません。

3) 同期と非同期: セマフォは使用される元のスレッドであるため、同期的であり、ブロッキングされます。

        3. 電流制限戦略の使用シナリオ:

リクエストの量が非常に多く、スレッド分離のオーバーヘッドが比較的高い場合、負荷を軽減するためにセマフォを使用することをお勧めします。この状況は通常、(外部サービスを呼び出さずに) 非ネットワークリクエストを処理するために使用されます。他のシナリオでは、スレッド プール方式を使用することをお勧めします。

4) 3 つの違いは何ですか?

電流制限は、トラフィック制限を超えない限り、サービスは引き続き利用可能であり (サーキット ブレーカーとは異なります)、ダウングレードする必要はありません (呼び出し元が処理するためにトラフィック制限超過の例外をスローすることもできます)。そのままで）。それでは、サーキット ブレーカーとダウングレードの違いについてお話しましょう。

• 異なる概念

サーキット ブレーカーはサービス全体が利用できないことを意味し (自己保護に重点を置く)、ダウングレードは次善のオプションを選択することを意味し (収益の保護に重点を置く)、電流制限は超過できないトラフィック量を指します。

• さまざまなトリガーメカニズム

デフォルトでは、リクエストの失敗率が 10 秒以内に 50% を超えたことを hystrix が検出すると、サーキット ブレーカー メカニズムがトリガーされます。その後、マイクロサービスへのリクエストは 5 秒ごとに再試行され、マイクロサービスが応答できない場合は、サーキット ブレーカー メカニズムが続行されます。マイクロサービスに到達できる場合、サーキット ブレーカー メカニズムがオフになり、通常のリクエストが復元されます。

デフォルトでは、hystrix は次の 4 つの条件下でダウングレード メカニズムをトリガーします。

1. メソッドが HystrixBadRequestException をスローする
2. メソッド呼び出しのタイムアウト
3. サーキットブレーカーをオンにして通話を傍受します
4. スレッド プール、キュー、またはセマフォがいっぱいです

• 異なる所有関係

ダウングレード メカニズムはサーキット ブレーカー中に呼び出される場合がありますが、通常、サーキット ブレーカー メカニズムはダウングレード中に呼び出されません。サーキット ブレーカーは全体的な観点から開始され、システムの安定性を確保するためにサービスを非アクティブ化しますが、ダウングレードは次善の策で保証されたソリューションを提供するため、所有権関係は異なります (サーキット ブレーカー > ダウングレード)。

2. ふりとRestTemplate

リンク内容の概要:

1. スターター依存関係を追加します。
2. 注釈を追加します: @EnableFeignClients;
3. Feign インターフェースを作成します。

@FeignClient(名前="eureka-HA",フォールバックファクトリー=DeptClientServiceFallbackFactory.class)

springcloud チュートリアル -- 1. エントリーレベルのデモをすばやく構築します。この記事を読むだけです_Ye Juyan-GitCode オープン ソース コミュニティ早速、私に従って、最初の Spring Cloud エクスペリエンスを開始してください。 まず、マイクロサービスの基本コンポーネントを確認します。 [図はこちら] プロデューサ: サービスの提供 コンシューマ: サービスの消費 サービスの登録/検出センター: サービスの登録、検出、監視springcloud マイクロサービスのアーキテクチャ基盤を理解する: プロデューサー (クライアント)、コンシューマー (クライアント)、サービス登録/検出センター (サーバー) Ye Juyan GitCode オープンソース コミュニティhttps://gitcode.csdn.net/65e840841a836825ed78b9d0.html?dp_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpZCI6MzI1MTQ3NiwiZXhwIjoxNzIxMTM0MjcwLCJpYXQiOjE3MjA1Mjk0NzAsInVzZXJuYW1lIjoicXFfMTk5NTIwMjkifQ.7co5oRDfDrxtdqIsV-9AjJacdbURh-cikj5Rtxt7Z1c

3.ズールの利用

参照する：

SpringBootプロジェクトアーキテクチャ「Gateway zuul構築」の実践 - CSDNブログ

4. 登録センターエウレカの利用

参照する：

SpringBootプロジェクトアーキテクチャ実戦「親プロジェクト構築と登録センター構築」_Java構築 SpringBoot親プロジェクト立ち上げ - CSDNブログ

4. SpringCloudの仕組み

1.エウレカの動作原理:

1. サービス登録: サービス プロバイダーが開始すると、サービスの IP アドレス、ポート番号、サービス名、その他の情報を含む登録リクエストが Eureka サーバーに送信されます。 エウレカサーバーは登録要求を受信すると、サービス情報をメモリに保存し、外部サービス登録情報照会機能を提供します。

2. サービス ディスカバリ: サービス コンシューマが他のサービスを呼び出す必要がある場合、サービス ディスカバリ リクエストを Eureka サーバーに送信して、必要なサービスのインスタンスのリストを取得します。 リクエストを受信すると、Eureka サーバーは、サービスの IP アドレス、ポート番号、その他の情報を含む、対応するサービスのインスタンスのリストを返します。サービス コンシューマは、返されたインスタンス リストに基づいて、呼び出す (負荷分散) サービス インスタンスの 1 つを選択します。

3. ハートビート ヘルス チェック: サービス プロバイダーは、サービスが正常に動作していることを証明するために、定期的にハートビート パケットを Eureka サーバーに送信します。 Eureka サーバーが一定期間内にサービス インスタンスからハートビート パケットを受信しない場合、サービス インスタンスはダウンしていると見なされ、サービス リストから削除されます。

5. SpringCloudの基礎となるソースコード

1. ゲートウェイズールのソースコード

SpringBootプロジェクトアーキテクチャ「Gateway zuul構築」の実践 - CSDNブログこの記事は 227 回閲覧され、読まれました。第 3 章 ゲートウェイ Zuul の構築 はじめに: 1. 主な機能 Zuul は主に、ダイナミック ルーティング (組み込みのリボン実装) とフィルタリング (統合認証フィルタ、グレースケール パブリッシング フィルタ、ブラック/ホワイト リスト IP フィルタ、サービス電流制限フィルタとして使用可能) を提供します。 (Sentinel で実装可能)) 機能; 2. Spring Cloud GateWay との違いは、2 つの異なるオープンソース組織によって提供されるゲートウェイ ソリューションであることです。 Spring Cloud GateWay は、ノンブロッキング API、組み込みの電流制限フィルターを使用し、長い接続 (WebSocket など) をサポートし、同時実行性が高くバックエンド サービスの応答が遅いシナリオでは Zuul よりも優れています。https://blog.csdn.net/qq_19952029/article/details/124285479

2. 登録センター Eureka のソース コード

3. サーキットブレーカー Histrix ソースコード

4. 構成センターの構成ソース コード

5. 負荷分散リボンのソース コード

6. マイクロサービスは偽のソースコードを呼び出します

6. SpringCloud が分散トランザクションを実装する方法

Seata TCC モードの実践 (パート 2)-Alibaba Cloud 開発者コミュニティシータTCCモード実戦（その２）https://developer.aliyun.com/article/1053737?spm=5176.26934562.main.1.799c6a03T45SJ9上記のブログ投稿は、さまざまなステータス指標によって判断できる一時停止の問題を解決するものではありません。

https://www.cnblogs.com/lilpig/p/16613226.htmlhttps://www.cnblogs.com/lilpig/p/16613226.html

1. TCCモードの役割

TM: トランザクション マネージャー。@GlobalTransaction アノテーションを使用して生成されます。

TC: コーディネーター

RM:参加者

全体のプロセスは次のとおりです。

TM はグローバル トランザクションをプロキシし、実行を開始する前に TC に登録します。
TMはグローバルトランザクション内の各ブランチトランザクションの実行を開始し、RMはブランチトランザクションと実行状況を登録してTCに報告します。
ブランチ トランザクションの実行が完了すると、TM は TC に対してグローバル トランザクションをコミットまたはロールバックする要求を開始します。

2. TCC リソースの予約、送信、およびロールバックの意味。

予約とは、データベースリソースを中間状態にロックして更新し、確認後の第二段階コミット時に有効状態に変更することを意味します。したがって、予約フェーズとコミットロールバックフェーズすべてにデータベースの操作が含まれますそのため、手動処理が必要な確認やロールバックの失敗が発生する場合もありますが、これはログの記録や再試行の補正などによって解決できます。

3. TCCのメリットとデメリット

TCCモードの利点：

1. 1 段階での直接送信、DB ロックなし、その他のロックなし、優れたパフォーマンス
2. 予約および回復ロジックは独自に作成され、データベースに依存しません。非トランザクション データベースで使用できます。

TCC モードの欠点：

1. コーディングは複雑です
2. 一貫性が低い
3. なぜならConfirmそしてCancel失敗する可能性もあり、このプロセスに対処する必要があります
4. たとえば、注文は新しい行を追加するプロセスであるなど、TCC モデルに適していないビジネスもあります。

4.XAモード

各参加者のローカル トランザクションがコミットおよびロールバックされるタイミングを調整することにより、強力な一貫性を実現します。

XAモードのメリット：

1. 実装が簡単。ほとんどのデータベースはすでに XA トランザクションをサポートしているため、Seata は簡単なパッケージ化を行うだけで済みます。
2. 強い一貫性

XAモードのデメリット：

1. 各トランザクションはすべてのトランザクション処理が完了するまで待機する必要があり、データベース ロックが占有されるため、パフォーマンスが低下し、可用性が低下します。
2. データベースがXAトランザクションをサポートしていない場合は使用できません

5.ATモード

弱い一貫性