1.1概要
Spring Cloud現在、マイクロサービスアーキテクチャの分野のリーダーであり、無数の本やブログがこのテクノロジーについて説明しています。ただし、ほとんどの説明はまだSpring Cloud関数の使用レベルであり、多くの人は基本的な原則を知らない可能性があります。
実際、これSpring Cloudはファミリー全体のバケットスタイルのテクノロジースタックであり、多くのコンポーネントを含む分散型マイクロサービスアーキテクチャのワンストップソリューションです。この記事は、その基礎となる動作原理を分析するためのコアコンポーネントから始まります。つまり、Eureka、Ribbon、Feign、Hystrix、Zuulこれらのコンポーネントです。
1.2ビジネスシナリオの概要
最初にビジネスシナリオをお話ししましょう。現在eコマースWebサイトを開発していると仮定します。注文の支払い機能を実現するためのプロセスは、次のとおりです。
- 注文を作成した後、ユーザーが注文をすぐに支払う場合は、注文ステータスを「支払い済み」に更新します
- 対応する製品在庫を差し引く
- 倉庫センターに配達を通知する
- ユーザーの購入に対応するポイントを追加します
上記のプロセスには、注文サービス、在庫サービス、倉庫サービス、およびポイントサービスが必要です。プロセス全体の一般的な考え方は次のとおりです：
- ユーザーが注文の支払いを完了すると、注文サービスにアクセスして注文ステータスを更新します
- 注文サービスは在庫サービスを呼び出して、対応する機能を完了します
- 注文サービスは倉庫サービスを呼び出して、対応する機能を完了します
- 注文サービスは、対応する機能を完了するために統合サービスを呼び出します
この時点で、注文の支払いのビジネスプロセス全体が終了します
次の図は、サービス間の呼び出しプロセスを明確に示しています。
Spring Cloudビジネスシナリオができたら、これらのコンポーネントがマイクロサービスアーキテクチャで互いにどのように連携するか、それらの役割、およびその背後にある原則を見てみましょう。
1.3Spring Cloudコアコンポーネント：Eureka
最初の質問を考えてみましょう。在庫サービス、倉庫サービス、またはポイントサービスを呼び出す場合、注文サービスを呼び出す方法は？
注文サービスは、在庫サービスがどのマシンにあるかを知りません！リクエストを開始したい場合でも、誰に送信すればよいかわからず、無力です。
この時点で、それは現れる時間Spring Cloud Eurekaでした。Eurekaこれは、サービスの登録と検出を担当するマイクロサービスアーキテクチャの登録センターです。
次の図を見て、図と組み合わせてプロセス全体を注意深く分析してみましょう。
上の図に示すように、在庫サービス、倉庫サービス、およびポイントサービスには、このサービスの情報をに登録するEureka ClientコンポーネントがEureka Serverあります。率直に言って、それはEureka Serverあなたがどのマシンにいて、どのポートをリッスンしているのかを知ることです。代わりEureka Serverに、これはレジストリであり、各サービスが配置されているマシンとポート番号を保存するレジストリがあります。
Eureka Client注文サービスにもコンポーネントがあります。このEureka ClientコンポーネントEureka Serverは、在庫サービスがどのマシンにあるかを尋ねます。どのポートをリッスンしていますか？倉庫サービスはどうですか？ポイントサービスはどうですか？Eureka Server次に、関連情報をレジストリからローカルキャッシュにプルできます。
このとき、注文サービスが在庫サービスを呼び出したい場合は、ローカルEureka Clientマシンに在庫サービスがオンになっているマシンを尋ねることができます。どのポートをリッスンしていますか？応答を受信した後、在庫サービスのインターフェースを呼び出して在庫を差し引くように要求を送信できます。同様に、注文サービスが倉庫サービスとポイントサービスを呼び出す必要がある場合も、同じ方法で行われます。
結論は：
Eureka ClientEureka Server：このサービスの情報をに登録する責任がありますEureka Server：レジストリセンター。各サービスが配置されているマシンとポート番号を保存するレジストリがあります。
1.4Spring Cloudコアコンポーネント：Feign
これで、注文サービスは、在庫サービス、ポイントサービス、および倉庫サービスがどこにあるか、およびどのポート番号が同時にリッスンしているかを認識します。しかし、新しい質問が発生します。注文サービスは、それ自体で多くのコードを記述し、他のサービスとのネットワーク接続を確立し、複雑な要求を作成し、要求を送信し、最後に返された応答に対して多くのコードを記述する必要がありますか？ 。それに対処しますか？
これは上記のプロセス翻訳のコードスニペットです。この絶望的で無力な感覚を見て、体験してみましょう。！！
フレンドリーなリマインダー、先の高エネルギー：
上記の大きなコードを読んだ後、背中が冷たくなり、冷や汗を感じましたか？実際、サービス間呼び出しを行うとき、毎回コードを書くと、コードの量は上記の段落の少なくとも数倍になるので、これは地球上の人々ができることではありません。
その場合、どうすればよいですか？心配しないでください、Feign私たちはすでにエレガントなソリューションを提供しています。Feign注文サービスが在庫サービスを呼び出すためのコードを使用すると、どのようになるか見てみましょう。
上記のコードを読んだ後、どのように感じますか？全世界がきれいだと感じますか、そしてあなたは再び生きる勇気を見つけました！接続を確立し、要求を作成し、応答を解析するための基礎となるコードはありません。アノテーションを使用してFeignClientインターフェースそのインターフェースを呼び出すだけです。注釈に基づいて、ユーザーはFeign Client指定したサービスとの接続を確立し、リクエストを作成し、リクエストを開始し、レスポンスを取得し、レスポンスを解析します。この一連の汚い仕事はFeignすべてあなたのために行われます。
だから問題は、Feignそれはどうしてそんなに魔法なのかということです。簡単に言うとFeign、重要なメカニズムの1つは、動的プロキシの使用です。次の図を見て、図と組み合わせて分析してみましょう。
- まず、
@FeignClientインターフェイスで注釈を定義するFeignと、このインターフェイスの動的プロキシが作成されます - 次に、そのインターフェイスを呼び出す場合、本質は
Feign、コアのコアである作成された動的プロキシを呼び出すことです。 Feign動的プロキシは、インターフェース上の@RequestMapping注釈に基づいて、要求するサービスのアドレスを動的に構築します。- 最後に、このアドレスについて、リクエストを開始し、レスポンスを解析します
1.5Spring Cloudコアコンポーネント：Ribbon
終わったFeign、まだ終わっていない。5以下に示すように、人々の在庫サービスがマシンに展開されている場合、新しい問題が再び発生します。
192.168.169:9000
192.168.170:9000
192.168.171:9000
192.168.172:9000
192.168.173:9000
トラブルになります！どのFeignマシンを要求するかをどうやって知るのですか？
- そこで
Spring Cloud Ribbon便利です。Ribbonこの問題を解決するために特別に設計されています。その機能は負荷分散です。これは、リクエストごとにマシンを選択し、リクエストを各マシンに均等に分散するのに役立ちます。 Ribbonデフォルトの負荷分散で使用される最も古典的なラウンドRound Robinロビンアルゴリズム。これは何ですか？簡単に言えば、注文サービスが10在庫サービスへの2番目の要求を開始すると、最初の1マシン、次に最初の2マシン、最初の3マシン、最初の4マシン、最初の5マシン、そしてサイクル、最初の1マシンを要求できるようになります。 、2マシン。。。等々。
さらに、作業Ribbonは次のように緊密に協力しFeignて行わEurekaれます。
- まず
Ribbon、から対応するサービスレジストリEureka Clientを取得し、すべてのサービスが展開されているマシンとリッスンしているポート番号を確認します。 - 次に
Ribbon、デフォルトのRound Robinアルゴリズムを使用して、マシンを選択できます。 Feignこのマシンに対してリクエストが作成され、開始されます。
上記のプロセス全体について、より深く理解するのに役立つ別の図を次に示します。
1.6Spring Cloudコアコンポーネント：Hystrix
マイクロサービスアーキテクチャでは、システムに多くのサービスがあります。この記事のビジネスシナリオを例として取り上げます。注文サービスは、ビジネスプロセスで3つのサービスを呼び出す必要があります。ここで、注文サービス自体に100リクエストを処理するためのスレッドが最大で1つあるとします。その後、残念ながらポイントサービスがハングアップします。注文サービスがポイントサービスを呼び出すたびに、数秒間スタックし、タイムアウト例外がスローされます。 。
それを一緒に分析しましょう、これはどのような問題を引き起こしますか？
1.システムが同時実行性の高いシナリオにある場合、多数のリクエストが着信する100と、注文サービスの各スレッドがリクエストポイントサービスでスタックします。その結果、注文サービスにはリクエスト
2を処理できるスレッドがなく、他の人が注文サービスをリクエストすると、注文サービスもハングしてリクエストに応答しないことがわかります。
上記は、次の図に示すように、マイクロサービスアーキテクチャにおける恐ろしいサービスアバランシェの問題です。
上の図に示すように、非常に多くのサービスが相互に呼び出します。1つのサービスに障害が発生すると、連鎖反応が発生し、他のサービスが失敗します。たとえば、ポイントサービスが切断されると、注文サービスのすべてのスレッドが要求ポイントサービスでスタックします。スレッドは機能せず、注文サービスもすぐに切断されます。他の注文サービスを要求する場合すべてがスタックし、応答できなくなります。
でも考えてみれば、ポイントサービスが中断されても注文サービスは中断される可能性があります！なんで？
- ビジネスと組み合わせて見てみましょう。注文の支払い時に在庫を差し引いてから、倉庫に
OK商品の配送を通知します。 - ポイントサービスがハングした場合、重要なのは、回復した後、データを手動でゆっくりと復元することです。ポイントサービスが停止されたために注文サービスも停止されたのはなぜですか？受け入れられない！
問題が分析されたので、どのように解決しますか？
さあ、Hystrix輝きを放ちましょう。Hystrixこれは、絶縁、回路ブレーカー、および劣化のためのフレームワークです。どう言う意味ですか？端的に言えば、Hystrix小さなスレッドプールがたくさんあります。たとえば、在庫サービスを要求する注文サービスはスレッドプールであり、倉庫サービスの要求はスレッドプールであり、要求ポイントサービスはスレッドプールです。各スレッドプールのスレッドは、そのサービスを要求するためにのみ使用されます。
たとえば、ポイントサービスが停止されたのは残念ですが、どうなりますか？
もちろん、注文サービスでポイントサービスを呼び出すために使用されるスレッドはスタックし、機能しなくなります。ただし、在庫サービスを呼び出す注文サービスと倉庫サービスの2つのスレッドプールは正常に機能しているため、これら2つのサービスはまったく影響を受けません。
このとき、他の誰かが注文サービスを要求した場合でも、注文サービスは在庫サービスを呼び出して通常どおり在庫を差し引き、倉庫サービスを呼び出して配達を通知することができます。ポイントサービスを呼び出すと、毎回エラーが報告されるだけです。しかし、ポイントサービスがすべてハングアップしている場合、電話をかけるたびに数秒間スタックする必要があるのはなぜですか？それは意味がありますか？もちろん違います！したがって、クレジットサービスを直接融合することができます。たとえば、クレジットサービスの要求は5分以内に直接返されます。ネットワーク要求に移動して数秒間スタックしないでください。このプロセスはいわゆる融合です。 ！！
あの人はまた言った、兄弟、ポイントサービスが切れるなら、それは断ち切られるでしょう、それであなたは何をしているのですか？何もせずに戻るだけですか？問題ありません。ダウングレードしましょう。ポイントサービスを呼び出すたびに、ポイントサービスが一時停止されているため、特定のユーザーに追加されたポイントの数を示すメッセージがデータベースに記録され、ポイントの追加に成功しません。 ！！このように、ポイントサービスが復元されたときに、これらのレコードに基づいて手動でポイントを追加できます。このプロセスはダウングレードと呼ばれます。
より直感的に理解できるように、画像を使用してHystrix、分離、融合、ダウングレードのプロセス全体を整理しましょう。
1.7Spring Cloudコアコンポーネント：Zuul
その後Hystrix、最後のコンポーネントZuulであるマイクロサービスゲートウェイについて説明します。このコンポーネントは、ネットワークルーティングを担当します。ネットワークルーティングがわかりませんか？では、私に言わせてください、Zuulもしあなたが毎日の仕事をしていなかったらどうなるでしょうか？
何百ものサービスがバックグラウンドでデプロイされていて、フロントエンドの兄弟がいて、人々のリクエストがブラウザーから直接送信されているとします。例：誰かが在庫サービスを要求したい場合でも、このサービスの名前を覚えておくように依頼しますinventory-serviceか？5単一のマシンにデプロイされていますか？人々がこれを覚えていても、あなたのバックグラウンドにある何百ものサービスの名前と住所はどうですか？家族がそれを要求するとき、彼らはそれを覚えていなければならない可能性はありますか？このようにプレイしたいのなら、それは本当に小さな友情の船です、あなたがそれを覆したと言うなら！
上記の状況はまったく現実的ではありません。android、ios、pcしたがって、一般的なマイクロサービスアーキテクチャでは、フロントエンドやWeChatアプレットなど、ゲートウェイが設計されているH5必要があります。バックエンドの何百ものサービスを気にする必要はありません。はゲートウェイであり、すべてのリクエストはゲートウェイ、ゲートウェイに送信されます。リクエストのいくつかの特性に応じて、リクエストはバックエンドのさまざまなサービスに転送されます。
また、ゲートウェイを使用した後は、統合されたダウングレード、現在の制限、認証と承認、セキュリティなど、多くの利点があります。
1.8まとめ
Spring Cloud最後に、マイクロサービスアーキテクチャにおける上記のコアコンポーネントの役割を要約しましょう。
Eureka：各サービスが開始Eureka Clientされると、サービスはに登録されEureka Serverます。また、他のサービスがどこにあるかを知るために、レジストリEureka Clientを逆からEureka Serverプルすることもできます。Ribbon：負荷分散に基づいてサービス間でリクエストが開始された場合、Ribbonサービスの複数のマシンから1つを選択しますFeign：Feign動的プロキシメカニズムに基づいて、注釈と選択されたマシンに従って、要求URLアドレスがスプライスされ、要求が開始されますHystrix：要求はHystrixスレッドプールを介して開始されます。異なるサービスは異なるスレッドプールを使用します。これにより、異なるサービス呼び出しの分離が実現され、サービスのなだれの問題が回避されます。Zuul：フロントエンドとモバイルエンドがバックエンドシステムを呼び出したい場合、Zuulそれらはゲートウェイから均一に入力され、ゲートウェイZuulは対応するサービスに要求を転送します
上記は、eコマースビジネスシナリオを通じたSpring Cloudマイクロサービスアーキテクチャのいくつかのコアコンポーネントの基本原則の説明です。
テキストの要約は十分に直感的ではありませんか？問題なし！Spring Cloudコアコンポーネントのそれぞれを図で接続5し、基本的なアーキテクチャの原則を直感的に感じます。
