ショック！面接官を吊るす、SpringCloud マイクロサービスの面接で必要な質問 (VIP コレクション版)

CP: レジストリが CP に属している場合、レジストリにインスタンスを登録するか、インスタンスを削除するとき、登録または削除が成功する前に、レジストリクラスター内のデータの一貫性が保たれるまで待つ必要があり、時間がかかります。ビジネスアプリケーションの規模が増大し、アプリケーションのオンラインとオフラインが頻繁に切り替わるにつれて、登録センターへの負担が比較的大きくなり、サービス検出とサービス呼び出しの効率に影響を及ぼします。

AP: 登録センターが AP の場合、登録センタークラスターは、ノード間のデータに不整合があった場合でも、何が起こってもサービスを提供できます。たとえば、オフラインになっているサービスノードがプルされますが、現在は、一般的なマイクロサービスフレームワークまたはコンポーネントは、サービスフォールトトレランスと再試行機能を提供しており、これによってもこの問題を回避できます。登録センターにとっては、データの一貫性をリアルタイムで確保するために多くのリソースを消費する必要はなく、最終的な一貫性を確保できれば十分であるため、登録センターへの負担は少なくなります。

4. Nacos はどのようにして近くのアクセスを実現しますか?

Nacos では、サービスは複数のインスタンスを持つことができ、インスタンスに設定できますcluster-name。サービス A がサービス B を呼び出したい場合、Naocs はサービス A を呼び出しているインスタンスがどのクラスターに属しているかを確認し、同じクラスターを呼び出します。サービス B のインスタンス、これが Nacos の最も近いアクセスです。

5. Nacos の基礎となる負荷分散の基本原理

リボンで実装されており、リボン上で負荷分散アルゴリズムを定義し、そのアルゴリズムに基づいてサービスインスタンスからインスタンスを取得してサービスを提供します。

6. Nacos1.x 登録センターのアーキテクチャプロセス

サービスが開始されると、API を介してサービスの登録が開始されます。
サービス利用者は、開始時に使用したいサービスのリストを取得します。
サービス利用者は 10 秒ごとにデータを取得します。
Nacos サービスは異常を検出すると (サービスがオフラインになると)、更新のために UDP プロトコルをクライアントに送信します。
サービスは 5 秒ごとにハートビートを Nacos に送信します。
Nacos は 5 秒ごとにハートビート情報をチェックして、タイムアウトしたかどうかを判断します。15 秒を超えると、ノードを異常な状態に設定してブロードキャストします。30 秒を超えると、ノードを削除して、ノードがタイムアウトしていることを示します。利用できません。
Nacos クラスターデータ同期タスクプロトコル: Distro(AP) 、 Raft(CP)

7. 登録センターアーキテクチャプロセスとしての Nacos2.X

8. Nacos のディストリビューションプロトコル

Nacos の各ノードは、書き込みリクエストの一部を担当します。
各ノードは、担当する新しいデータを他のノードと同期します。
各ノードは、データの一貫性を維持するために、定期的に自身のデータのチェック値を他のノードに送信します。
各ノードは独立して読み取りリクエストを処理し、タイムリーにローカルに応答を送信します。
新しく追加された Distro ノードは、全量のデータをプルします。

9. エウレカ登録センターの理念

サービスの登録が開始されます。
クラスター内のデータ同期。
クライアントタイミングタスクは 30 秒ごとにデータを取得します。
クライアントのハートビートは 30 秒ごとに契約を更新します。
インスタンスの有効期限が切れているかどうかを 1 分ごとに確認し、期限が切れている場合はインスタンスを削除し、切断が大量に発生した場合は自己保護を開始します。
API を呼び出して正常にオフラインにします。

10. エウレカの自己防衛メカニズムの原理

Eureka サーバーは、すべての Eureka インスタンスの通常のハートビート率を 15 分ごとにチェックし、それが 85% 未満の場合、自己保護メカニズムをトリガーします。保護メカニズムがトリガーされると、Eureka はこれらの失敗したサービスを期限切れから一時的に保護しますが、これらのサービスは決して期限切れになるわけではありません。

起動が完了すると、Eureka は 60 秒ごとにサービスの健全性ステータスをチェックします。保護され、障害が発生したサービスが一定時間 (デフォルトでは 90 秒) 経過しても復元されない場合、これらのサービスは削除されます。この期間中にサービスが復元され、インスタンスのハートビート率が 85% を超えた場合、自己保護メカニズムは自動的にオフになります。

11. エウレカとナコスの比較

Nacos2.0 では、登録センターが定期的に消費者に積極的に情報をプッシュしますが、Eureka は積極的に情報をプッシュしません。
Nacos は CP モードと AP モードをサポートし、Eureka は AP モードをサポートします。
Nacos はオンラインとオフラインのエレガントなサービスとトラフィック管理を備えていますが、Eureka の背景ページは表示のみであり、オンラインとオフラインの操作には API を使用する必要があり、トラフィック管理機能はありません。
Nacos コミュニティは活発ですが、Eureka のオープンソース作業は停止しました。
Nacos は登録センターと設定センターの機能を統合しており、Eureka は単なる登録センターです。

12. Nacos 構成センターのロングポーリングメカニズム

ナコス 1.4.x

クライアントは、長い接続リクエストをポーリングしてサーバーに送信します。この長い接続は最大 30 秒でタイムアウトします。サーバーは、クライアントからリクエストを受信すると、まず構成の更新があるかどうかを判断し、更新がある場合はすぐに戻ります。サーバーがありません。キューへの参加要求を 29.5 秒間「保留」し、最後の 0.5 秒で設定ファイルをチェックし、設定ファイルが更新されているかどうかに関係なく正常に戻ります。ただし、29.5 秒の待機期間中に、サーバーがある場合は、は構成の更新であるため、早期に終了して戻る可能性があります。

ナコス2.x

サーバーの構成が変更されると、長いリンクを通じてクライアントにサービスの変更が通知され、クライアントはそれをプルします。
時間指定されたタスクは 5 秒ごとに取得されます。

13. Nacos 構成によって参照される時間指定タスクが失敗する (Nacos が作業中に問題に遭遇する)

まず最初に、 @Schedule は Bean をロードするときにポストプロセッサを使用しScheduledAnnotationBeanPostProcessor、@Scheduleマークされたメソッドを取得して、それを Bean のライフサイクルで実行することを知っておく必要があります。
@RefreshScope値が Refresh である @Scope があります。彼はオブジェクトを作成し、それを対応するキャッシュに置きます。GenericScope#getメソッドを通じてキャッシュから対応する Bean オブジェクトを取得します。構成を更新し、コンテナーをリフレッシュすると、これらのインスタンスオブジェクトはマークが付いている場合、@RefreshScopeオブジェクト内にスケジュールされたタスクがある@Scheduleため、それにアクセスし続けることはできません。対応するインスタンスを作成するには、インスタンス内のインターフェイスを呼び出す必要があります (対応するBeanFactory#getBean オブジェクトがある場合は、が取得され、対応するオブジェクトがない場合は作成されます)、対応するスケジュールされたタスクは通常の動作になります。

解決策: 構成を更新し、コンテナーを更新するRefreshScopeRefreshedEventと、イベントが送信されます。このイベントをリッスンするだけで、対応するインスタンスが作成され、スケジュールされたタスクが通常どおり実行されます。

14. Nacos はどのような構成をロードしますか?また、これらの構成の優先順位は何ですか?

sharedConfigs Redis、mysql 設定などのパブリック設定。
extensionConfigs 拡張設定ファイル。
${application.name} nacos-config
${application.name}. ${file-extension} nacos-config.yaml
${application.name}- ${profile}. ${file- extension} nacos-config-prod.yaml

15. Nacos 構成センターがダウンしています。サービスに影響はありますか?

しません。クライアントは構成センターの構成情報を取得した後、構成情報のコピーをローカルに保存します。構成センターがダウンすると、最初にローカルファイルが読み取られます。

16. 構成センターの技術的選択

コミュニティ活動に注目してください。
独自のテクノロジースタックを組み合わせます。
製品の機能が満たされているかどうか。

17. Feign が初めて電話をかけるのに時間がかかるのはなぜですか?

リボンはデフォルトで遅延読み込みされており、リボンに対応するコンポーネントは初めて呼び出されたときにのみ生成されるため、最初の呼び出しが非常に遅くなるという問題が発生します。

ribbon:
  eager-load:
    enabled: true
      clients: service-1

18. Feign はどのようにして認定の譲渡を実現しますか?

インターフェイスを実装しRequestInterceptor、ヘッダーを通じて認証を渡します。

public class FeignAuthRequestInterceptor implements RequestInterceptor {
private String tokenId;

public FeignAuthRequestInterceptor(String tokenId) {
    this.tokenId = tokenId;
}

@Override
public void apply(RequestTemplate template) {
    template.header("Authorization",tokenId);
}

}

19. デフォルトで HTTP を送信する Feign の最下層は何ですか? 何が問題ですか? どうすれば改善できますか?

Feign の最下層にはデフォルトで JDK が付属していますHttpURLConnection。単一スレッドで HTTP リクエストを送信し、スレッドプールを構成できません。http リクエストの送信には Okhttp または HttpClient を使用でき、どちらもスレッドプールをサポートしています。

一般的な HTTP クライアント

HTTPクライアント

HttpClient は Apache Jakarta Common Http の下のサブプロジェクトで、HTTP プロトコルをサポートする効率的で最新の機能豊富なクライアントプログラミングツールキットを提供するために使用され、HTTP プロトコルの最新バージョンと推奨事項をサポートします。従来の JDK と比較して URLConnection、 HttpClient は使いやすさと柔軟性が向上し、クライアントが HTTP リクエストを送信しやすくなり、開発の効率が向上します。

OKhttp

ネットワークリクエストを処理するためのオープンソースプロジェクトは、Android 側で最も人気のある軽量フレームワークであり、Square によって提供され、との置き換えに使用され HttpUrlConnection ます Apache HttpClient。OkHttp は簡潔な API、効率的なパフォーマンスを備え、複数のプロトコル (HTTP/2 および SPDY) をサポートしています。

HTTPURL接続

HttpURLConnection これは Java の標準クラスであり、から継承しており URLConnection、指定された Web サイトに GET リクエストと POST リクエストを送信するために使用できます。HttpURLConnection HttpClient ほど簡単ではなく、使用するのがより複雑です。

残りのテンプレート

RestTemplate これは、Rest サービスにアクセスするために Spring によって提供されるクライアントであり、RestTemplate リモート HTTP サービスにアクセスするためのさまざまな便利なメソッドを提供し、クライアントの書き込み効率を大幅に向上させることができます。

OKhttp 設定

feign:
  okhttp:
    enabled: true

20. 2PC プロセスとその利点と欠点について簡単に説明してください

利点: データの強力な整合性を確保しようとし、実装コストが低い. すべての主要な主流データベースに独自の実装があり、MySQL については 5.5 から (XA) をサポートします。

欠点:

単一点の問題: プロセス全体におけるトランザクションマネージャーの役割は非常に重要です。トランザクションマネージャーがダウンした場合、たとえば、最初のフェーズが完了し、2 番目のフェーズの送信準備中にトランザクションマネージャーがダウンした場合、リソースはマネージャーは常にブロックされ、データベースが使用できなくなります。
同期ブロック: 準備が完了すると、送信が完了してリソースが解放されるまで、リソースマネージャー内のリソースはブロックされます。
データの不整合: 2 フェーズコミットプロトコルは分散データの強力な整合性を考慮して設計されていますが、データの不整合の可能性は依然としてあります。一部の参加者のみがコミット操作を受信して実行しましたが、残りの参加者はブロックされていました。が通知を受信できず、この時点でデータの不整合が発生しました。

21. 3PC プロセスとその利点と欠点について簡単に説明してください

3 フェーズコミット (3PC) は、2 フェーズコミット (2PC) の最適化をアップグレードしたもので、3PC は 2PC の第 1 フェーズと第 2 フェーズに準備フェーズを挿入します。最終的な送信段階の前に、各参加ノードの状態が一貫していることが保証されます。

同時に、コーディネーターとパティシパントの両方にタイムアウト機構が導入され、パティシパントがさまざまな理由でコーディネーターからのコミット要求の受信に失敗した場合、ローカルトランザクションはブロックされて待機することなく中止され、単一の問題を解決します。 2PC の障害点の問題は解決しましたが、3PC はまだデータの一貫性の問題を根本的に解決できていません。

利点: タイムアウトメカニズムの導入。トランザクションマネージャーの突発的なダウンによりリソースが常にブロックされてしまう問題を解決しました。

短所: 3PC はタイムアウトメカニズムを使用して同期ブロッキングの問題を解決しますが、同時にネットワーク通信が 1 つ増えるため、パフォーマンスが低下し、データの不整合の問題が依然として残ります。

22. Seata はどのようなトランザクションモードをサポートしていますか?

2PCの4つのモードを提供

AT モード: 侵入と自動補正のないトランザクションモードを提供します [これはローカルでトランザクションをサポートできるリレーショナルデータベースに基づいており、Java コードは JDBC 経由でデータベースにアクセスできます。ここでは侵入はありません。対応するアノテーションを追加するだけで済みます。グローバルアフェアを開く]
XA モード: XA インターフェイスを実装したデータベースの XA モードをサポートします [ここでは通常、mysql oracle が XA を実装したように、データベースが対応する XA モードインターフェイスを実装する必要があります]
TCC モード: TCC はアプリケーションレベルでは 2PC として理解でき、これを実現するにはビジネスロジックを記述する必要があります。
SAGA モード: 長いトランザクションに効果的なソリューションを提供します。

23. Seata の Feign を通じて xid をグローバルに転送する方法

グローバルトランザクション ID は、Feign のヘッダーを通じて渡されます。

24. ゲートウェイのコアコンセプト

ルート

ルーティングはゲートウェイの最も基本的な部分であり、ルーティング情報には、ID、宛先 URI、述語ファクトリーのセット、フィルターのセットが含まれます。述語が true の場合、要求された URL は構成されたルートと一致します。

述語

つまりjava.util.function.Predicate 、Spring Cloud Gateway は Predicate を使用してルーティングの一致条件を実装します。

フィルター

SpringCloud Gateway のフィルターは、Gateway FilIer と Global Filter に分かれています。フィルターはリクエストとレスポンスを処理できます。

ルートは転送ルール、述語はこのパスに従うかどうかの条件、フィルターはビジネスロジックをルートに追加し、リクエストと応答を変更できます。

25. Gateway でスムーズなサービス移行を実現するにはどうすればよいですか?

Weight ルートのアサーションファクトリを使用してサービスの重みを設定し、動的移行のためにその設定を Nacos 設定センターに置くことができます。

重みルーティングアサーションファクトリ: アサーションファクトリには、グループグループと重みを表すために使用される 2 つのパラメータが含まれています。同じグループ内の複数の URI アドレスの場合、ルーターは設定された重みに応じた割合でリクエストを対応する URI に転送します。負荷分散を実現します。

spring:
  cloud:
    gateway:
      routes:
      - id: weight_high
        uri: https://weighthigh.org
        predicates:
        - Weight=group1, 8
      - id: weight_low
        uri: https://weightlow.org
        predicates:
        - Weight=group1, 2

26. Zuulのアーキテクチャとスレッドの安全性を確保する方法

サーブレットはスレッドセーフではないのでデータをスルーしてしまうのですが、フィルターはリクエストをどうやって区別するのかという非常に厄介なところがあります。

Zuul は RequestContextフィルター間でデータを渡すために使用されます。データは、リクエストのルーティング先などを含め、各リクエストの ThreadLocal に保存されます。HttpServletRequestこれらHttpServletResponse のデータは RequestContext に保存されます。

概要: Zuul は多くのフィルターで構成されています。これらのフィルターは、ルーティング前のフィルター、ルーティング後のフィルター、ルーティングのルーティングフィルターに分かれています。サーブレット、ランナー、フィルターはすべてスレッドセーフではありませんが、私たちはスレッドセーフですRequestContext。

27. Zuul 起動アノテーション @EnableZuulProxy と @EnableZuulServer の違い

@EnableZuulProxy 一般に、この@EnableZuulServerクラスが対応するクラスを継承し、その機能を追加することを紹介します。

WeChat パブリックアカウントをフォローしてください: リソースをチャージしてください返信
: 春
[imooc-java2021] システムコース - Java エンジニア 2022 年版
Quark ネットワークディスク: https://pan.quark.cn/s/bbaec39732e0#/list/share

公式アカウントに注目してください。必要なリソースはすべて利用可能で、無料で純粋に共有できるリソースがたくさんあります。