SpringCloudインタビューの質問

1.春の雲とは？

春の雲は、一連のフレームワークの順序付けられたコレクションです。スプリングブートの開発の利便性を利用して、サービスディスカバリ登録、構成センター、メッセージバス、ロードバランシング、サーキットブレーカー、データモニタリングなどの分散システムインフラストラクチャの開発を巧みに簡素化し、すべてスプリングブート開発スタイルで実行できます。ワンクリックで起動して展開します。

2.春の雲のコアコンポーネントは何ですか？

• ユーレカ：発見時のサービス登録
• Feign：アノテーションと選択したマシンに応じて、動的プロキシメカニズムに基づいて、リクエストのURLアドレスをスプライシングしてリクエストを開始します。
• リボン：ロードバランシングを実現するには、サービス内の複数のマシンから1つを選択します。
• Hystrix：スレッドプールを提供します。さまざまなサービスがさまざまなスレッドプールを使用するため、さまざまなサービス呼び出しの分離が実現し、サービス雪崩の問題を回避できます。
• Zuul：ゲートウェイ管理。Zuulゲートウェイはリクエストを対応するサービスに転送します。

3. feiginとは何ですか？その利点は何ですか？

1. Feignはインターフェースベースのアノテーションを使用しています
2. Feignはリボンを統合し、負荷分散する機能を備えています
3. Hystrixと統合、融合機能付き

4.リボンとフェインの違いは何ですか？

1. リボンは他のサービスを呼び出しますが、方法は異なります
2. 開始クラスの注釈は異なります。リボンは@RibbonClient feignは@EnableFeignClientsです。
3. サービスで指定された場所が異なります。リボンは@RibbonClientアノテーションで宣言されていますが、Feignは抽象メソッドを定義するインターフェースで@FeignClient宣言を使用しています。
4. 呼び出し方法は異なります。リボンはそれ自体でhttp要求を作成し、http要求をシミュレートしてから、RestTemplateを使用してそれを他のサービスに送信する必要があります。手順は非常に面倒です。Feignは呼び出されたメソッドを抽象メソッドとして定義する必要があります

5. Spring Cloud Busとは何ですか？

Spring Cloud Busは、分散ノードを軽量のメッセージブローカーに接続します。構成ファイルの変更をブロードキャストしたり、サービスと直接通信したり、監視に使用したりできます。
構成ファイルが変更され、要求が送信されると、すべてのクライアントが構成ファイルを再度読み取ります。

6. EurekaとZooKeeperの両方がサービスの登録と検出機能を提供できます。2つの違いを教えてください

1. ZooKeeperはCPを保証し、EurekaはAPを保証します
2. ZooKeeperにはLeaderとFollowerの役割があります。Eurekaノードは同じです（Eurekaノードは同じです。Eurekaが存在する限り、サービスが利用可能であることが保証され、クエリされたデータは最新ではありません）
3. ZooKeeperは半分以上の生存の原則を採用し、Eurekaは自己保護メカニズムを採用してパーティションの問題を解決します
4. Eurekaは基本的にプロジェクトですが、ZooKeeperは単なるプロセスです
5. Eurekaは、ネットワーク障害のために一部のノードが接続を失う状況に対処でき、ZooKeeperのような登録システム全体を麻痺させません（ZooKeeper登録サービスは選挙中に麻痺しますが、サービスは最終的に回復しますが、選挙中には利用できません）。
6. Eurekaは新しいサービスの登録およびクエリ要求を引き続き受け入れることができますが、他のノードと同期されません（高可用性）

7. Hystrixとは何ですか？必要ですか？

耐雪崩武器、サービスの低下、サービスの融合、依存関係の分離、監視（Hystrixダッシュボード）
いくつかの理由により、ユーザーサービスによって公開されたサービスは例外をスローします。この場合、Hystrixはフォールバックメソッドの定義に使用されます。例外が発生した場合、いくつかのデフォルト値が返されます。（回路ブレーカーの目的は、例外が発生するか、このメソッドが他のメソッドを呼び出し、最終的に例外の回復につながる可能性があるメソッドの時間を確保することです）

サービスのダウングレード：圧迫されたダブルイレブンプロンプト

コアサービスに優先順位を付けると、非コアサービスが利用できないか、利用が弱くなります。HystrixCommandアノテーションで指定します。
fallbackMethod（フォールバック関数）は、特にダウングレードロジックを実装します。

飼育係の原則

Zookeeperは、サービス管理のレジストリーとしても使用できます（Zookeeperには、分散トランザクションロックなどの他の用途もあります）。
マイクロサービスが開始されるたびに、一時的な子ノードがzookeeperに登録されます。たとえば、5つの注文サービス、4つの商品サービス（5つの一時ノードがzkの注文カタログの下に作成されます）、（4 （zkの製品カタログの下に作成された4つの一時的な連絡先）。
サービスが停止すると、ノードは一時的な連絡先であるためすぐに削除され、サービスに登録されているマイクロサービスにはサービスリストの更新が通知されます（zkで監視され、ノードの更新があるたびに、サービスに登録されているマイクロサービスに通知されますサービス更新サービス一覧）。
新しいマイクロサービスが登録されると、対応するディレクトリに一時的な子ノードが作成され、サービスに登録されているマイクロサービスにサービスリストの更新が通知されます。
各マイクロサービス30は、zkから新しいサービスリストを取得します。

キャップ

分散には、一貫性（一貫性）、可用性（可用性）、パーティション許容値（パーティション許容値）の3つのインジケーターがあり、CAPと呼ばれます。エリックはCAPを完全に達成することはできないと提案しましたこれはCAPの定理です。

レジストリとしての可用性の要件は一貫性よりも高いため、ユーレカは飼育係よりも合理的であるようです

一貫性

一貫性とは、データの読み取りと書き込みをまったく同じにする必要があることを意味します。たとえば、1つのデータがuser-server1とuser-server2の2つのサーバーに格納されているとします。
次に、server1を使用してデータaをデータbに変更します。このとき、server1にアクセスすると、bになります。
しかし、server2にアクセスしたときに、返されたaがまだ変更されていない場合、整合性は満たされず、返されたbはデータの整合性です。

可用性

これは理解しやすいです。つまり、サーバーにリクエストを送信している限り、サーバーは私に応答してサーバーが常に利用可能であることを確認する必要があります。

パーティション許容差

一般的に言って、分散システムは複数の場所に分散されます。たとえば、サーバーの1つは北京にあり、もう1つは上海にあります。おそらく天候やその他の理由により、2つのサーバーが直接通信できず、データを同期できません。これはパーティションのフォールトトレランスです。パーティションの許容度は避けられないと考えています。つまり、Pが存在している必要があります。

エウレカ保証AP

** Eurekaは可用性を優先します：** Eurekaプラットフォームでは、サーバーがダウンした場合、EurekaはZooKeeperのようなリーダー選出プロセスを持ちません。クライアント要求は自動的に新しいEurekaノードに切り替わり、ダウンするとサーバーが復元された後、Eurekaは再びサーバークラスター管理に組み込みます。そのために必要なことは、新しいサービス登録情報を同期することだけです。したがって、 "レフトビハインド"サーバーが復元後にEurekaサーバークラスターから削除されるリスクを心配する必要はありません。
Eurekaは、より広範なネットワークセグメンテーション障害に対処し、「0」のダウンタイムメンテナンス要件を達成するように設計されています。ネットワークセグメンテーションエラーが発生した場合、各Eurekaノードは引き続き外部にサービスを提供します（注：ZooKeeperは提供しません）。新しいサービス登録を受信し、それらをダウンストリームサービスディスカバリリクエストに提供します。このようにして、同じサブネットに実装でき、新しくリリースされたサービスを引き続き検出してアクセスできます。

Eurekaの各ノードは同等であり、いくつかのノードの障害は通常のノードの動作に影響を与えません。残りのノードは引き続き登録およびクエリサービスを提供できます。EurekaクライアントがEurekaに登録するか、接続が失敗したことを検出すると、自動的に他のノードに切り替わります。1つのEurekaがまだ存在している限り、登録サービスは保証されます（可用性が保証されます）が、情報は見つかりました最新でない可能性があります（強い整合性は保証されません）。
さらに、Eurekaには自己保護メカニズムもあります。ノードの85％を超えて15分以内に正常なハートビートがない場合、Eurekaはクライアントとレジストリの間にネットワーク障害があると信じており、この時点で次のことが起こります。ハプニング：

1. Eurekaは、長い間ハートビートを受信して​​いないために期限切れになるサービスを登録リストから削除しなくなりました
2. Eurekaは引き続き新しいサービス登録とクエリ要求を受け入れることができますが、他のノードとは同期されません（つまり、現在のノードが引き続き利用可能であることを確認するため）。
3. ネットワークが安定すると、現在のインスタンスの新しい登録情報が他のノードに同期されます

Eurekaには、クライアント側のキャッシュ機能もあります（注：Eurekaは、クライアントプログラムとサーバー側プログラムの2つの部分に分かれており、クライアントプログラムは、登録と検出サービスのインターフェースを提供します）。したがって、Eurekaクラスター内のすべてのノードで障害が発生した場合、またはネットワークセグメンテーションエラーが発生した場合でも、クライアントはEurekaサーバーにアクセスできません。Eurekaサービスのコンシューマーは、Eurekaクライアントキャッシュを通じて既存のサービス登録情報を取得できます。最も極端な環境であっても、通常のユーレカノードはすべて要求に応答せず、この問題を解決するための優れたサーバーソリューションはありません。ユーレカのクライアントキャッシングテクノロジーのおかげで、コンシューマーサービスはユーレカを通過できます。クライアントは、登録サービス情報を照会して取得します。

飼育係はcpを保証します

ZooKeeperは分散協調サービスとして非常に優れていますが、サービスディスカバリサービスには適していません。サービスディスカバリサービスの場合、誤った情報を含む結果が返されても、何もしないよりはましです。サービス検出サービスの場合、特定のサービスが5分前に利用可能であったサーバーに関する情報を返し、結果を返さずに一時的なネットワーク障害が原因で利用可能なサーバーを見つけないようにすることをお勧めします。したがって、ZooKeeperを使用してサービス検出サービスを実行するのは間違いです。
飼育係はこのような状況になるため、マスターノードがネットワーク障害のために他のノードとの接続を失うと、残りのノードがリーダーを再選します。問題は、リーダーの選挙時間が30〜120秒と長すぎ、選挙中はzkクラスター全体が利用できないため、選挙中に登録サービスが麻痺することです。クラウドデプロイメント環境では、ネットワークの問題が原因でzkクラスターがマスターノードを失う可能性が高くなります。サービスは最終的に復元できますが、長い選挙時間が原因で発生する登録の長期的な利用不可は許容できません。