上記は、Spring-Cloudのマイクロサービスアーキテクチャのマスターであり、クラウドコンピューティングのベストビジネスプラクティスです。
春の雲に触れたいという男性ホルモンの衝動があり、特に征服したいのですが、彼女は私が好きだと思います。辛棄疾の詩を思い出します。緑の丘がより魅力的で、緑の丘がより魅力的です。私がこのようになるはずです。
2人がお互いを愛し合っているので、ここで深く理解する方法を理解しましょう...（何が必要ですか）次に、PUAスタイルのチュートリアルを教えます。
特に興味がある場合は、ここで停止しましょう。上記では、自由に交換して、トピックに戻ることができます。
1. Spring-Cloudの過去と現在
1.まず、Spring-Cloudに行きたいですか？
这篇文章针对没有接触过spring-cloud，或者有经验的可以更加巩固一下，Spring Cloud 是一系列框架的有
序集合，它利用 Spring Boot 的开发便利性简化了分布式系统的开发，比如服务发现、服务网关、服务路
由、链路追踪等。Spring Cloud 并不重复造轮子，而是将市面上开发得比较好的模块集成进去，进行封装，
从而减少了各模块的开发成本。换句话说：Spring Cloud 提供了构建分布式系统所需的“全家桶”。
2.春の雲の現状は？
目前，国内使用 Spring Cloud 技术的公司并不多见，不是因为 Spring Cloud 不好，主要原因有以下几点：
Spring Cloud 中文文档较少，出现问题网上没有太多的解决方案。国内创业型公司技术老大大多是阿里系员
工，而阿里系多采用 Dubbo 来构建微服务架构。大型公司基本都有自己的分布式解决方案，而中小型公司
的架构很多用不上微服务，所以没有采用 Spring Cloud 的必要性。但是，微服务架构是一个趋势，而 Spring Cloud 是微服务解决方案的佼佼者，这也是作者写本系列课程的意义所在。
3.春の雲の長所と短所？
其主要优点有：集大成者，Spring Cloud 包含了微服务架构的方方面面。
约定优于配置，基于注解，没有配置文件。
轻量级组件，Spring Cloud 整合的组件大多比较轻量级，且都是各自领域的佼佼者。
开发简便，Spring Cloud 对各个组件进行了大量的封装，从而简化了开发。
开发灵活，Spring Cloud 的组件都是解耦的，开发人员可以灵活按需选择组件。
接下来，我们看下它的缺点：
项目结构复杂，每一个组件或者每一个服务都需要创建一个项目。
部署门槛高，项目部署需要配合 Docker 等容器技术进行集群部署，而要想深入了解 Docker，学习成本高。
Spring Cloud 的优势是显而易见的。因此对于想研究微服务架构的同学来说，学习 Spring Cloud 是一个不错的选择。
2. Spring-Cloudの利用とビジネスシナリオ
実際、私はSpring-Cloudを初めて使用し、一目惚れしているので、機会を逃してまた会いましょう。
ビジネスシナリオの紹介：現在、注文の支払い機能を実現するためのオンラインビデオ学習プロジェクトを開発しているとします。
プロセスは次のとおりです。
- 注文を作成した後、ユーザーは注文の支払いをすぐに行い、注文ステータスを「支払い済み」に更新する必要があります
- 対応する商品在庫を差し引く
- 倉庫保管センターに配達を通知する
- 対応するポイントを増やします
- または対応するクーポンを差し引く
上記に対応して、注文サービス、在庫サービス、倉庫サービス、統合サービス、クーポンサービスがあります。
一般的な考え方：
- ユーザーが注文の支払いを完了すると、注文サービスにアクセスして注文ステータスを更新します
- 注文サービスは在庫サービスを呼び出して、対応する機能を完了します
- 注文サービスは倉庫サービスを呼び出して、対応する機能を完了します
- 注文サービスは、対応する機能を完了するために統合サービスを呼び出します
図1に示すように、支払い注文のビジネスプロセス全体が終了し、サービス間の呼び出しプロセスが明確に示されます。
次に、Spring Cloudマイクロサービスアーキテクチャのどのコンポーネント、相互に対話する方法、およびその背後にある主要な兄弟を調べてみましょう。
Spring Cloudは、Spring Cloud Config、Spring Cloud Netflix、Spring Cloud Consulなどの多くのサブプロジェクトで構成されています。構成管理、サービス検出、サーキットブレーカー、インテリジェントルーティングなど、分散システムやマイクロサービスの構築に一般的に使用されるツールを提供します。 、およびマイクロエージェント、制御バス、ワンタイムトークン、グローバルロック、マスター選択、分散セッション、クラスター状態などは、マイクロサービスの構築に必要なすべてのソリューションを満たしています。
服务发现——Netflix Eureka
客服端负载均衡——Netflix Ribbon
断路器——Netflix Hystrix
服务网关——Netflix Zuul
分布式配置——Spring Cloud Config
彼女を
1つずつ取得しましょう。SpringCloudのコアコンポーネントの1つであるEureka [jʊ'ri：kə]
では、注文サービスはどのように在庫サービス、倉庫サービス、ポイントサービスを呼び出したいのでしょうか。
注文サービスは、在庫サービスがどのマシンにあるかを知らないだけです！リクエストを開始したい場合でも、誰に送信するかはわかりません。無力です！現時点では
、Spring CloudEurekaの番です。Eurekaは、サービスの登録と検出を担当するマイクロサービスアーキテクチャのレジストリです。
下の写真を見て、写真と組み合わせてプロセス全体を注意深く分析しましょう。上の写真に
示すように、在庫サービス、倉庫サービス、およびポイントサービスにEurekaクライアントコンポーネントがあります。このコンポーネントは登録を担当します。このサービスの情報。Eurekaサーバーへ。
率直に言って、Eureka Serverに、現在使用しているマシンとリッスンしているポートを通知することです。
Eurekaサーバーは、各サービスのマシンとポート番号を格納するレジストリを備えたレジストリです。
注文サービスにはEurekaクライアントコンポーネントもあります。このEurekaクライアントコンポーネントは、Eurekaサーバーに次のように尋ねます。在庫サービスはどのマシンですか？どのポートがリッスンしていますか？倉庫サービスはどうですか？ポイントサービスはどうですか？
次に、関連情報をEurekaサーバーのレジストリからローカルキャッシュにプルできます。
このとき、注文サービスが在庫サービスを呼び出したい場合は、ローカルのEurekaクライアントを見つけて、在庫サービスがオンになっているマシンを尋ねることができますか？どのポートでリッスンしていますか？
応答を受け取ったら、すぐに在庫サービスのインターフェースを呼び出して在庫を差し引くように要求を送信できます。同様に、注文サービスが倉庫サービスとポイントサービスを呼び出す必要がある場合も、同じことが言えます。
結論として：
Eurekaクライアント：このサービスの情報をEurekaサーバーに登録する責任があります。
Eurekaサーバー：各サービスのマシンとポート番号を格納するレジストリを含むレジストリ。
Spring Cloudの2番目のコアコンポーネント：Feignの
注文サービスは、在庫サービス、ポイントサービス、倉庫サービスがどこにあるか、どのポート番号も監視されているかを認識できるようになりました。
しかし、もう一度新しい質問があります。注文サービスは、それ自体で多くのコードを記述し、他のサービスとのネットワーク接続を確立し、複雑な要求を作成し、過去に要求を送信し、最後に多くのコードを記述する必要がありますか？返された応答結果のコード？それを処理しますか？
これは上記のプロセスで翻訳されたコードスニペットです。一緒に見て、この絶望と無力感を体験してみましょう!!!
フレンドリーなリマインダー、前もって高エネルギーの警告：
上記の大きなコードを読んだ後、冷や汗を感じますか？実際、サービス間で電話をかけるとき、毎回コードを書くと、その量はコードの数は上記の段落よりも少なくとも数倍多いので、このことは単に地球の能力がありません。
その場合、どうすればよいですか？心配しないでください。Feignはすでにエレガントなソリューションを提供してくれています。Feignを使用しているかどうかを見てみましょう。注文サービスは、在庫サービスコードをどのように呼び出しますか？
上記のコードを読んだ後、あなたは何を感じますか？あなたは全世界がきれいであると感じますか、そしてあなたは生きる勇気を見つけました！
接続を確立し、要求を作成し、応答を解析するための基礎となるコードはありません。アノテーションを使用してFeign Clientインターフェースを定義し、そのインターフェースを呼び出すだけです。
Feign Clientは、指定したサービスとの接続を確立し、リクエストを作成し、リクエストを開始し、レスポンスを取得し、アノテーションに従って下部でレスポンスを解析します。Feignはあなたのためにこのすべての汚い仕事をしました。
だから問題は、Feignがそのような魔法のことをどのように行うのかということです。非常に単純で、Feignの重要なメカニズムは動的プロキシを使用することです。
上の写真を見て、写真と組み合わせて分析してみましょう。
まず、インターフェイスで@FeignClientアノテーションを定義すると、Feignはこのインターフェイスの動的プロキシを作成します。
次に、そのインターフェイスを呼び出すと、基本的に、コアのコアであるFeignによって作成された動的プロキシが呼び出されます。
Feignの動的プロキシは、@ RequestMappingおよびインターフェイス上の他のアノテーションに基づいて、要求するサービスのアドレスを動的に構築します。
最後に、このアドレスについて、要求を開始し、応答を解析します。
Spring Cloudコアコンポーネント3：リボン
Feignについて話し終えましたが、まだ終わっていません。インベントリサービスが5台のマシンに展開されている場合、新しい問題が再び発生します。
次のように：
192.168.169：9000
192.168.170：9000
192.168.171：9000
192.168.172：9000
192.168.173：9000
これは面倒です！Feignはどのマシンを要求するかをどのように知るのですか？それならSpringCloudリボンが便利です。
リボンは特にこの問題を解決します。その役割は負荷分散であり、リクエストごとにマシンを選択し、リクエストを各マシンに均等に分散するのに役立ちます。
リボンの負荷分散でデフォルトで使用される最も古典的なラウンドロビンポーリングアルゴリズム。これは何ですか？
簡単に言うと、注文サービスが在庫サービスに対して10件のリクエストを開始した場合、最初に最初のマシン、次に2番目のマシン、3番目のマシン、4番目のマシン、5番目のマシンをリクエストし、次にもう一度来るように依頼します。サイクル、最初のマシン、2番目のマシン。。。等々。
さらに、リボンは次のように、FeignおよびEurekaと緊密に協力して作業を完了しました。
まず、リボンはEurekaクライアントから対応するサービスレジストリを取得します。Eurekaクライアントは、すべてのサービスが展開されているマシンと、監視されているポート番号も認識しています。
次に、リボンはデフォルトのラウンドロビンアルゴリズムを使用して、そこからマシンを選択できます。
Feignは、このマシンのリクエストを作成して開始します。
上記のプロセス全体について、より深く理解するのに役立つ別の図を次に示します。
Spring Cloudコアコンポーネント4：Hystrix
マイクロサービスアーキテクチャでは、システムに多くのサービスがあります。この記事のビジネスシナリオを例として取り上げます。注文サービスは、ビジネスプロセスで3つのサービスを呼び出す必要があります。
ここで、注文サービス自体にリクエストを処理できるスレッドが最大100個あるとします。その後、残念ながらクレジットサービスがハングします。注文サービスがクレジットサービスを呼び出すたびに、数秒間スタックし、タイムアウト例外がスローされます。
一緒に分析してみましょう、これはどのような問題を引き起こしますか？システムが同時実行性の高いシナリオにある場合、多数のリクエストが着信すると、注文サービスの100スレッドがポイントサービスのリクエストでスタックし、スレッドがなくなります注文サービスで。リクエストを処理します。
次に、他の人が注文サービスを要求すると、注文サービスもダウンしていて、要求に応答しなくなっていることがわかります。
上記は、次の図に示すように、マイクロサービスアーキテクチャにおける恐ろしいサービスアバランシェの問題です。
上の図に示すように、非常に多くのサービスが相互に呼び出しを行うと、保護が行われないと、特定のサービスがハングし、連鎖反応が発生し、他のサービスがハングします。
たとえば、統合サービスが一時停止された場合、注文サービスのすべてのスレッドが統合サービスの要求でスタックします。スレッドは機能せず、注文サービスも瞬時に一時停止されます。他の人はすべて立ち往生し、応答できなくなります。
でも考えてみると、ポイントサービスがダウンしても注文サービスは省略できます！なぜですか？
ビジネスの観点から見てみましょう。注文の支払いを行うときは、在庫を差し引いて、倉庫に出荷するように通知するだけです。
ポイントサービスがダウンしている場合は、回復するのを待ってから、手動でゆっくりとデータを復元するのが大変です。ポイントサービスがダウンしているために、注文サービスを直接停止する必要があるのはなぜですか。受け入れられません。
問題が分析されたので、それをどのように解決するのですか？今度はHystrixがデビューする番です。Hystrixは、分離、融合、劣化のためのフレームワークです。どういう意味ですか？
率直に言って、Hystrixは多くの小さなスレッドプールに関与します。たとえば、注文サービスのリクエスト在庫サービスはスレッドプール、リクエストウェアハウジングサービスはスレッドプール、リクエストクレジットサービスはスレッドプールです。スレッドプール内の各スレッドは、そのサービスを要求するためにのみ使用されます。
例えを見てみましょう。残念ながら、現在、クレジットサービスはダウンしています。どうなりますか？もちろん、注文サービスでクレジットサービスを呼び出すために使用されるスレッドがスタックし、機能しません。
ただし、在庫サービスを呼び出す注文サービスと倉庫サービスの2つのスレッドプールは正常に機能しているため、これら2つのサービスはまったく影響を受けません。
このとき、誰かが注文サービスを要求した場合でも、注文サービスは在庫サービスを呼び出して在庫を差し引き、倉庫サービスを呼び出して配達を通知することができます。
クレジットサービスに電話をかけると、毎回エラーが報告されるだけです。しかし、ポイントサービスがすべてハングアップした場合、電話をかけるたびに数秒間スタックするというのはどういう意味ですか？それは意味がありますか？もちろんそうではありません！
したがって、ポイントサービスを直接融合する必要があります。たとえば、5分以内にポイントサービスを要求すると、直接戻ります。ネットワークにアクセスして数秒間スタックするように要求しないでください。このプロセスは、いわゆるヒューズ！
それから彼らは言った、兄弟、ポイントサービスがダウンしているなら、あなたはそれを融合するでしょう。とにかく、あなたは何をしているのですか！何もせずにただ戻ってはいけませんか？
問題ありません。ダウングレードしましょう。ポイントサービスを呼び出すたびに、ポイントサービスがダウンしているため、特定のユーザーに追加されたポイントの数を示すメッセージがデータベースに記録され、増加は成功しません。
ポイントサービスが復元された後、これらのレコードに基づいて手動でポイントを追加できます。このプロセスは、いわゆるダウングレードです。
誰もがより直感的に理解できるように、写真を使用してHystrixの分離、融合、ダウングレードのプロセス全体を整理しましょう。
Spring Cloudコアコンポーネント5：Zuul
Hystrixについて話した後、最後のコンポーネントであるZuulについて話しましょう。これはマイクロサービスゲートウェイです。このコンポーネントは、ネットワークルーティングを担当します。
ネットワークルーティングがわかりませんか？では、Zuulの日常業務がなければどうなるか教えてください。
バックグラウンドで何百ものサービスをデプロイし、フロントエンドの兄弟がいて、リクエストがブラウザから直接送信されたとします。
たとえば、誰かが在庫サービスを要求したい場合、このサービスの名前が在庫サービスであることを覚えていますか？5台のマシンにデプロイされていますか？
たとえ人々がこれを覚えても構わないと思っていても、バックエンドには何百ものサービス名とアドレスがありますか？大人がそれを求めた場合、あなたはそれを覚えなければならないというのは本当ですか？このようにプレイしたいのであれば、それは本当にです友情の船。ターン！
上記の状況は単に非現実的です。したがって、ゲートウェイは一般的なマイクロサービスアーキテクチャで設計する必要があります。
Android、iOS、PCフロントエンド、WeChatアプレット、H5などのように、バックエンドの何百ものサービスについて心配する必要はありません。ゲートウェイがあることを知っています。すべてのリクエストはゲートウェイに送られます。ゲートウェイは、要求をさまざまなバックエンドサービスに転送します。
そして、ゲートウェイを持った後、統一されたダウングレード、現在の制限、認証と承認、セキュリティなど、多くの利点があります。
総括する
最後に、マイクロサービスアーキテクチャにおける上記のSpringCloudコアコンポーネントの役割を要約しましょう。
Eureka：各サービスが開始されると、EurekaクライアントはサービスをEurekaサーバーに登録します。また、Eurekaクライアントは、他のサービスがどこにあるかを知るために、Eurekaサーバーからレジストリを順番にプルすることもできます。
リボン：サービス間で要求が開始されると、リボンに基づいて負荷分散が実行され、サービスの複数のマシンの1つが選択されます。
Feign：Feignの動的プロキシメカニズムに基づいて、アノテーションと選択されたマシンに従って、リクエストのURLアドレスがスプライスされてリクエストが開始されます。
Hystrix：リクエストはHystrixのスレッドプールを介して開始されます。異なるサービスは異なるスレッドプールを使用します。これにより、異なるサービス呼び出しの分離が実現され、サービスのなだれの問題が回避されます。
Zuul：フロントエンドとモバイルエンドがバックエンドシステムを呼び出したい場合、それらはZuulゲートウェイに均一に入り、Zuulゲートウェイは対応するサービスに要求を転送します。
上記は、SpringCloudマイクロサービスアーキテクチャのいくつかのコアコンポーネントの基本原則を説明したeコマースビジネスシナリオです。
テキストの要約は十分に直感的ではありませんか？問題ありません！Spring Cloudの5つのコアコンポーネントを画像で接続し、基本的なアーキテクチャの原則を直感的に感じます。
