1. マイクロサービスを使用する必要があるのはなぜですか?
マイクロサービス アーキテクチャ モデルを採用すると、単一のアーキテクチャ モデルによって引き起こされるシステムの複雑さを解決できます。主に以下のようなメリットが挙げられます。
- アジャイル開発: 各サービスは独立した小規模であり、別個のチームが責任を負うため、アジャイル開発モデルを採用し、適切なテクノロジを自由に選択し、古いサービスを書き換えることもできます。もちろん、統一された API 規約に従う必要があります。 。
- 独立したデプロイメント: 各マイクロサービスは独立してデプロイされ、迅速かつ反復的にデプロイできます。それぞれのサービス要件に従って、サービス リソース要件に最も適合する適切な仮想マシンとハードウェアが選択されます。
- 便利な開発と保守: アプリケーション全体が管理可能なモジュールとサービスに分解され、個々のサービスをより迅速に開発でき、理解と保守が容易になります。
- 負荷分散: 負荷分散を必要とする一部のサービスは、複数のクラウド仮想マシンにデプロイできます。NGINX などのロード バランサーを追加して、複数のインスタンス間でリクエストを分散するため、アプリケーション全体の負荷分散を行う必要がありません。
- 単一データベースのパフォーマンスのボトルネックを突破します。 各サービスは、単一のデータベース スキーマを共有するのではなく、独自のデータベース スキーマを持ちます。
2. サービスをマイクロサービスに分割するための原則は何ですか?
分割の一般原則は、あるビジネスが他のサービスに依存していないか、ほとんど依存せず、独立したビジネス セマンティクスを持ち、2 つ以上の他のサービスまたはクライアントにデータを提供する場合、
- 単一の責任、高い結合性、低い結合: 簡単に言うと、テーブルはサービスに分割されます。
- 適度なサービスの粒度: サービスは詳細になりすぎないでください (チームによっては、インターフェイスごとに 1 つのサービスを使用することもあります)
- 製品、ユーザー、注文などを 1 つのモデルとして割り込むビジネス モデルを使用する
- 進化的分割: 最初から細かく分割しすぎず、反復プロセスを通じて徐々に最適化できます。
- 循環依存関係と双方向依存関係を避ける: サービス間で循環依存関係を作らないようにしてください。
3. マイクロサービスではどのようなコンポーネントが使用されていますか? 各コンポーネントの役割は何ですか? どのようなシナリオが使用されますか?
- エウレカ（登録センター） のすべてのマイクロサービスモジュールは登録センターに登録され、登録フォームが生成され一元管理されます。eureka はプロデューサーでもあり、消費者でもあります。もちろん、クラスターを構築することもでき、エウレカの 1 つがクラッシュしても、他のマイクロサービスの使用には影響せず、システムのパフォーマンスが向上します。
- リボン (負荷分散)リボンの最も優れた部分は、RoundRobinRule ポーリング アルゴリズムです。デフォルトでは、各サービスが順番に 1 回要求されます。サービスは相互に通信する必要もあります。これは、http または rpc (リモート プロシージャ コール) を使用して行うことができます。RestTemplate を使用できます。RestTemplate は http を内部でカプセル化してオブジェクトを返すため、より便利で高速に使用できます。
- ズール（関門）とは、平たく言えば玄関のことで、通りたいものは通せるが、通りたくないものは通せない。カスタマーサービスからサーバーにリクエストが送信される際、ゲートウェイによる一連の検証とフィルタリングを経てアクセス要件を満たしていれば、他のマイクロサービスへのアクセス時やルーティング後のアクセス時に同様のセキュリティ認証を経る必要がありませんそしてゲートウェイによる転送。
- Hystrix (ヒューズ)は、回路内のヒューズに相当します。ヒューズの使用法を説明する例を挙げてください。商品を注文すると注文サービスが呼び出され、注文サービスから倉庫サービスに商品の発送が通知され、注文サービスからポイントサービスにユーザーにポイントが加算されることが通知されます。ポイント サービスがハングアップすると、注文サービスがポイント サービス スレッドを要求するたびに、数秒待機してから例外を返します。フラッシュ セール中に、多数の注文サービス スレッドがポイント サービスでスタックし、その後注文サービスもハングアップすると、サービスは終了し、雪崩が発生してサービス全体が爆発します。初めてリクエストするときにポイントサービスがダウンしていることがわかっても、それは気にする必要はなく、各サービスがすべきことをします。このような場合に Hystrix が使用されます。最後に、ポイント サービスがダウングレードされ、ポイント サービスには例外があることがユーザーに通知され、手動で確認した後にポイントが追加されます。最悪の場合、ポイントサービス復旧後に手動でポイント処理が行われるため、サービス全体の利用に影響はないとのこと。Hystrixには非常に優れた機能があり、ポイントサービスがダウンしていることがわかると、Hystrixが自動的に開き、一定時間が経過すると、Hystrixが半分開いた状態になり、ポイントサービスのリクエストを入れて、ポイント サービスの状態。ポイント サービスがまだハングしている場合、Hystrix は開き続けます。ポイント サービスのリクエストが成功すると、Hystrix は自動的に終了します。（ハイストリックスの人は本当に優しくて、みんなを安心させてくれる）
4. サービス間の呼び出しにはどのようなコンポーネントが使用されますか? 原理を教えていただけますか？
Springcloud のコアコンポーネントである Feign を使用して呼び出されます
5. マイクロサービスのデプロイメントを使用して、サービス雪崩にどのように対処しますか?
サービス雪崩効果とは、「サービス提供者の利用不能」（原因）が「サービスの呼び出し元の利用不能」（結果）につながり、利用不能が徐々に増幅する現象です。
サービス雪崩には、ハードウェア理由、ネットワーク理由、ソフトウェア理由など、さまざまな理由があります。ソフトウェアの観点から見ると、サービス雪崩を解決するためのいくつかのソリューションは次のとおりです。
- タイムアウト: スレッドの圧迫は、同期リモート呼び出しが長時間応答を取得できないことによって発生するため、タイムアウトを設定すると、スレッドの長期的な占有が軽減され、スレッドの圧迫を回避できます。
- 電流制限: 過剰な同時実行によるサービスのクラッシュを防ぐために、サービスの現在のフローを制限します。
- サーキット ブレーカー: サービスがハングアップした場合、それ以上の呼び出しは行われませんが、結果は直接返されます。これはサーキット ブレーカーと呼ばれます。これにより、ハングしたサービスが呼び出し元に与える影響が回避されます。
- 分離: プロセス分離、スレッド分離、セマフォ分離に分けられます。分離メカニズムの本質は、サービス呼び出しの粒度をより小さな部分に分割して、サービス生成のクラッシュによるサービス呼び出しへの影響を軽減し、サービス雪崩を回避することです。