まず、SpringCloudのさまざまなコンポーネントについて理解し、次にその理由を理解しましょう。
WeChatパブリックアカウントのJavaバックエンドに従い、バックグラウンドでコマンド666を入力して、テクニカルマニュアルをダウンロードします。
原則を説明する前に、最も古典的なビジネスシナリオの1つを見てみましょう。たとえば、eコマースWebサイトを開発し、注文を支払う機能を実現するためのプロセスは次のとおりです。
1.注文を作成した後、ユーザーが注文をすぐに支払う場合は、注文ステータスを「支払い済み」に更新する必要があります
2.対応する商品在庫を差し引く
3.倉庫センターに配達を通知します
4.ユーザーの購入に対応するポイントを追加します
上記のように、マイクロサービスのアプリケーションシナリオとコアコンピタンス：
結合の削減：各マイクロサービスは単一の機能に焦点を合わせ、明確に定義されたインターフェイスを通じてサービスの境界を明確に表現します。サイズが小さく複雑さが低いため、各マイクロサービスは小規模な開発チームによって完全に制御でき、高い保守性と開発効率を簡単に維持できます。
独立したデプロイ：マイクロサービスには独立した実行プロセスがあるため、各マイクロサービスを個別にデプロイすることもできます。マイクロサービスが変更されたときに、アプリケーション全体をコンパイルしてデプロイする必要はありません。マイクロサービスで構成されるアプリケーションは、一連の並列リリースプロセスを持つことと同等であり、リリースをより効率的にすると同時に、本番環境へのリスクを軽減し、最終的にアプリケーションの配信サイクルを短縮します。
柔軟な選択：マイクロサービスアーキテクチャでは、テクノロジーの選択は分散化されています。各チームは、独自のサービスニーズと業界開発の現状に応じて、最適なテクノロジースタックを自由に選択できます。各マイクロサービスは比較的単純であるため、テクノロジースタックをアップグレードするリスクは低く、マイクロサービスを完全に再構築することも可能です。
フォールトトレラントメカニズム：コンポーネントに障害が発生すると、単一プロセスの従来のアーキテクチャでは、障害がプロセス内に広がる可能性が高く、その結果、アプリケーションがグローバルに使用できなくなります。マイクロサービスアーキテクチャでは、障害は単一のサービスに分離されます。適切に設計されている場合、他のサービスは、再試行やスムーズな劣化などのメカニズムを通じて、アプリケーションレベルのフォールトトレランスを実現できます。
柔軟な拡張：シングルブロックアーキテクチャアプリケーションは、水平方向の拡張も実現できます。つまり、アプリケーション全体が異なるノードに完全にコピーされます。アプリケーションのさまざまなコンポーネントで拡張要件が異なる場合、各サービスは実際のニーズに応じて個別に拡張できるため、マイクロサービスアーキテクチャはその柔軟性を反映します。
DubboベンチマークSpringCloudマイクロサービス
背景分析：Dubboは、Alibabaのサービス指向ガバナンスのコアフレームワークであり、中国のさまざまなインターネット企業で広く使用されています。SpringCloudは、有名なSpringファミリーの製品です。アリババは営利企業であり、多くのトップレベルのプロジェクトをオープンソース化していますが、それでも全体的な戦略の観点から自社のビジネスにサービスを提供することに重点を置いています。Springは、中国や世界で広く使用されているエンタープライズレベルのオープンソースフレームワークの研究開発に焦点を当てています。ユニバーサルでオープンソースの堅牢なオープンソースフレームワークの開発が主な事業です。
アクティビティの比較：Dubboは優れたサービスガバナンスフレームワークであり、サービスガバナンス、グレースケールパブリッシング、トラフィック分散の点でSpring Cloudよりも優れています。Dangdangに基づく残りのサポートの追加に加えて、Dubboは2年以上経過してもほとんど更新されません。使用中に問題が発生し、GitHubに送信された問題がほとんど応答しませんでした。それどころか、Spring Cloudは開発以来、高速で開発を続けており、GitHubでのコード送信の頻度とリリース間の時間間隔からわかります。現在、SpringCloudはバージョン2.0をリリースしようとしています。後の期間でより完全で安定します。
プラットフォームアーキテクチャ：Dubboフレームワークは、サービス間のガバナンスのみに焦点を当てています。構成センターと分散トラッキングを使用する必要がある場合は、それを統合する必要があります。これにより、Dubboを目に見えない形で使用することが難しくなります。Spring Cloudは、サービスガバナンスのほぼすべての側面を考慮しており、Spring Bootのサポートにより、非常に便利で簡単に開発できます。
技術的展望：ダボは中小企業からも多くの恩恵を受けています。長年の発展の後、インターネット業界もより高度な技術と概念で出現しました。ダボは残念です。Springは多くの理由でSpringBoot / Cloudを立ち上げました。
Springが最初に提唱した軽量フレームワークは、開発が進むにつれてますます大きくなっています。統合プロジェクトが増えるにつれて、構成ファイルはますます混沌とし、元の概念から徐々に逸脱していきます。長年の開発と、マイクロサービスや分散リンクトラッキングなどの新しい技術概念の出現により、Springは以前の開発モデルを改善するためのフレームワークを緊急に必要としているため、Spring Boot / Cloudプロジェクトが登場します。今すぐ春に訪問しましょう公式ウェブサイトでは、SpringBootとSpringCloudがホームページの3つの最も著名なプロジェクトの最初の2つに配置されていることがわかります。これは、Springがこれら2つのフレームワークにどれだけ接続しているかを示しています。ダボは次のように実装されています。
SpringCloudの実装のアイデア
ユーレカ
原則：サービスの登録と検出を監視します。つまり、マイクロサービスの名前がEurekaに登録されている場合、マイクロサービスはサービス呼び出しの構成ファイルを変更せずにEurekaを介して検出できます。
分析：Spring Cloudは、Netflixが開発したEurekaモジュールをカプセル化して、サービスの登録と検出を実現します。csの設計アーキテクチャを採用しています。EurekaServerは、サービス登録機能のサーバーです。サービス登録センターです。システムの他のマイクロサービスは、Eurekaのクライアントを使用して、Eurekaサーバーに接続し、ハートビートを維持します。このようにして、システムメンテナは、システム内の各マイクロサービスがEurekaサーバーを介して正常に動作しているかどうかを監視できます。Spring Cloudの他のいくつかのモジュール（Zuulなど）は、Eurekaサーバーを使用して、システムの他のマイクロサービスを検出し、関連するロジックを実行できます。
ユーレカサーバー
Eureka Serverはサービス登録サービスを提供します。各ノードが起動すると、Eureka Serverに登録されます。これにより、Eureka Serverのサービスレジストリに利用可能なすべてのサービスノードの情報が保存されます。サービスノードの情報は、直感的に表示できます。インターフェイスで。
ユーレカクライアント
Eurekaクライアントは、Eurekaサーバーの対話を簡素化するために使用されるJavaクライアントです。クライアントには、ラウンドロビンロードアルゴリズムを使用するロードバランサーも組み込まれています。アプリケーションが起動すると、ハートビートがEurekaサーバーに送信され（デフォルトの期間は30秒）、現在のサービスが利用可能であることを証明します。Eurekaサーバーが特定の時間（デフォルトでは90秒）内にクライアントのハートビートを受信しない場合、Eurekaサーバーはサービスレジストリからサービスノードを削除します。
Eurekaサーバーの自己保護メカニズム
ノードの85％以上が15分以内に正常なハートビートを持たない場合、Eurekaはクライアントとレジストリの間にネットワーク障害があると考えており、この時点で次の状況が発生します。
Eurekaは、長い間ハートビートを受信していないために期限切れになるはずのサービスを登録リストから削除しなくなりました
Eurekaは引き続き新しいサービス登録とクエリ要求を受け入れることができますが、他のノードと同期されません（つまり、現在のノードが引き続き使用可能であることを確認するため）。
ネットワークが安定すると、現在のインスタンスの新しい登録情報が他のノードに同期されます
したがって、Eurekaは、ZooKeeperのような登録サービス全体を麻痺させることなく、ネットワーク障害のために一部のノードが接続を失う状況に対処できます。
ユーレカ和ZooKeeper
よく知られているCAP理論は、分散システムがC（一貫性）、A（可用性）、およびP（パーティションフォールトトレランス）を同時に満たすことはできないことを指摘しています。分散システムではパーティションのフォールトトレランスを保証する必要があるため、トレードオフを行うことができるのはAとCの間だけです。
ZooKeeperはCPを保証します
レジストリにサービスリストを照会する場合、レジストリが数分前に登録情報を返すことは許容できますが、サービスを直接ダウンして利用できないことを受け入れることはできません。つまり、サービス登録機能には、一貫性よりも多くの可用性が必要です。ただし、ZooKeeperにはこのような状況があり、ネットワーク障害のためにマスターノードが他のノードとの接続を失うと、残りのノードがリーダーを再選します。
問題は、リーダーの選出時間が30〜120秒と長すぎ、ZooKeeperクラスター全体が選挙中に利用できなくなり、選挙中の登録サービスが麻痺することです。クラウド展開環境では、ネットワークの問題により、ZooKeeperクラスターがマスターノードを失う可能性があります。サービスは最終的には復元できますが、選出時間が長いために登録が長期間利用できなくなることは許容できません。
ユーレカはAPを保証します
Eurekは、設計時に使いやすさを優先します。Eurekaのすべてのノードは同等であり、いくつかのノードに障害が発生しても通常のノードの動作には影響せず、残りのノードは引き続き登録およびクエリサービスを提供できます。EurekaクライアントがEurekaに登録するか、接続が失敗したことを検出すると、自動的に他のノードに切り替わります.1つのEurekaがまだ存在している限り、登録サービスは保証されます（可用性が保証されます）が、情報が見つからない場合があります最新であること（強い一貫性は保証されません）。
さらに、ユーレカには自己保護メカニズムがあります。上記を参照してください。
総括する
Eurekaは、ZooKeeperのような登録サービス全体を麻痺させることなく、ネットワーク障害のために一部のノードが接続を失う状況に対処できます。
純粋なサービス登録センターとして、EurekaはZooKeeperよりも「プロフェッショナル」です。これは、登録サービスが使いやすさにとってより重要であり、一貫性が短期的に達成されないことを受け入れることができるためです。
リボン和Feign
マイクロサービスアーキテクチャでは、ビジネスは独立したサービスに分割され、サービスとサービス間の通信はHTTPRESTfulに基づいています。Spring Cloudには2つのサービス呼び出しメソッドがあります。1つはRibbon + RestTemplateで、もう1つはFeignです。
概念
Netflixリボンに基づくクライアント負荷分散ツールのセットは、ポーリング戦略を使用しました。
クライアントの負荷分散：負荷分散Zuulゲートウェイが特定のサービスアプリケーションにリクエストを送信するときに、サービスが複数のインスタンスを開始すると、リボンインスタンスを介した特定の負荷分散戦略を通じて特定のサービスに送信されます。Spring CloudのRibbonの場合、クライアントにはサーバーアドレスのリストがあります。リクエストを送信する前に、負荷分散アルゴリズム（単純なポーリング、ランダム接続など）を使用してサーバーを選択し、それにアクセスします。
負荷分散
負荷分散：Webサイト、アプリケーション、データベース、またはその他のサービスのパフォーマンスと信頼性を向上させるために、ワークロードを複数のサーバーに分散するために使用されます。
負荷分散を使用する利点は明らかです。クラスター内の1つ以上のサーバーがダウンしている場合、ダウンしていない残りのサーバーはサービスの継続的な使用を保証できます。アクセス圧力は、特定の理由ではなく、各サーバーに分散されます。ピーク時間により、システムのCPUが急激に上昇します。
負荷分散にはいくつかの実装戦略があり、一般的なものは次のとおりです。ランダム、ラウンドロビン、ConsistentHash、ハッシュ、加重
リボンのデフォルトの戦略はポーリングです
RestTemplate
従来、JavaコードでRESTfulサービスにアクセスするには、ApacheのHttpClientが一般的に使用されますが、この方法は扱いにくいため使用できません。Springは、操作するためのシンプルで便利なテンプレートクラスを提供します。これがRestTemplateです。
Feignは宣言型のhttpクライアントです。Feignを使用すると、httpクライアントの作成が簡単になります。その使用方法は、インターフェイスを定義してからそれに注釈を追加することで、ターゲットマイクロサービスを呼び出すときにjsonデータを常に解析/カプセル化するという面倒な必要性を回避します。Spring Cloudでは、FeignはデフォルトでRibbonを統合し、Eurekaと組み合わせて、デフォルトで負荷分散の効果を実現します。
リボンとフェイグの違い
偽の目標により、JavaHttpクライアントの作成が容易になります
Ribbon + RestTemplateを使用する場合、Ribbonはそれ自体でhttpリクエストを作成し、httpリクエストをシミュレートしてから、RestTemplateを使用して他のサービスに送信する必要があります。手順は非常に複雑です。RestTemplateを使用してhttpリクエストをカプセル化すると、テンプレートベースの呼び出しメソッドが形成されます。ただし、実際の開発では、サービスに依存する呼び出しが複数存在する可能性があり、インターフェイスが複数の場所で呼び出されることが多いため、一部のクライアントクラスは通常、これらの依存するサービス呼び出しをラップするためにマイクロサービスごとにカプセル化されます。したがって、Feignはこれに基づいてさらにカプセル化し、依存サービスインターフェイスの定義と実装を支援してくれます。
Feignの実装では、インターフェイスを作成し、アノテーションを使用して構成するだけで済みます（以前は、DaoインターフェイスはMapperアノテーションでマークされていましたが、現在はFeignアノテーションがマークされたマイクロサービスインターフェイスです）。完了プロバイダーのインターフェースバインディングにより、SpringCloudリボンを使用するときにサービスコールクライアントを自動的にカプセル化する開発の量が簡素化されます。
Feignはリボンを統合します
リボンは、ポーリングを通じてクライアントの負荷分散を実装します。リボンとは異なり、Feignは宣言型Webサービスクライアントであるため、Webサービスクライアントを非常に簡単に作成できます。インターフェイスを作成して追加するだけで済みます。注：ローカルメソッドを呼び出すのと同じように呼び出すと、リモートメソッドを呼び出す気がしなくなります。SpringCloudでは、FeignはデフォルトでRibbonを統合し、Eurekaと組み合わせて、デフォルトで負荷分散の効果を実現します。
リボンとNginxの違い
Nginxは、すべてのクライアント要求がNginxに渡され、Nginxがサーバー側の負荷分散に属する負荷分散要求転送を実行することです。両方のリクエストはNginxサーバーによって転送されます。クライアントの負荷分散リボン、リボンはEurekaレジストリのサーバー側からサービス登録情報のリストを取得し、それをローカルにキャッシュしてから、ポーリング負荷分散戦略をローカルに実装します。どちらもクライアント側で負荷分散を実現します。
アプリケーションシナリオの違い
Nginxはサーバー側の負荷分散に適しています。たとえば、TomcatとRibbonは、ローカルサービスの負荷分散を実現するためのマイクロサービスでのRPCリモート呼び出しに適しています。たとえば、DubboとSpringCloudはすべてローカル負荷分散を使用します。
ズール
アプリケーションシナリオ
現在、マイクロサービスのサービス、注文、製品、ユーザーなどが12を超える場合、クライアントが各サービスを1つずつ処理する必要がないことは明らかです。これには、サービスゲートウェイである統合された入り口が必要です。APIゲートウェイのすべてのクライアントは、このゲートウェイを介してバックエンドサービスへのアクセスを要求します。彼は、特定のルーティング構成を使用して、特定のURLを処理するサービスを判別できます。そして、Eurekaから登録サービスを取得してリクエストを転送します。
コア機能
Zuulには、リクエストのルーティングとフィルタリングの2つの最も重要な機能が含まれています。これは、さまざまなサービスの統合エントリであり、監視、承認、セキュリティ、スケジューリングなどを提供するためにも使用されます。
ルーティング機能：外部リクエストを特定のマイクロサービスインスタンスに転送する役割を果たします。これは、外部アクセスの統合エントリを実現するための基礎です。
フィルタ機能：リクエストの検証やサービスの集約などの機能を実現するための基礎となるリクエストの処理に介入します。
ZuulとEurekaが統合されています。Zuul自体がEurekaサービスガバナンスの下でアプリケーションとして登録され、他のマイクロサービスからのメッセージがEurekaから取得されます。つまり、Zuulがジャンプした後にマイクロサービスへの将来の訪問が取得されます。
注：Zuulサービスは最終的にEurekaに登録され、プロキシ+ルーティング+フィルタリングの3つの機能を提供します。
コア原則
Zuulのコアは一連のフィルターであり、その機能はサーブレットフレームワークのフィルター（AOP）に類似しています。
フィルタ間の直接通信はありませんが、リクエストコンテキストを介したデータ転送です。
ZuulフィルターはGroovyによって作成されます。これらのフィルターファイルはZuulサーバーの特定のディレクトリに配置されます。Zuulはこれらのディレクトリを定期的にポーリングし、変更されたフィルターはフィルタリング要求で使用するためにZuulサーバーに動的にロードされます。
Zuul負荷分散：Zuulは、対応するAPIプレフィックス要求をインターセプトし、対応するserverIdに転送します。Eurekaサービスでは、同じserverIdが複数のサービスに対応できます。つまり、同じサービスノードの異なるポートに2つのインスタンスを登録できます。ただし、serverIdは転送を行うときのZuulと同じであり、eureka-serverと組み合わせて負荷分散効果を実現します。
フィルタの種類
PRE：このフィルターは、要求がルーティングされる前に呼び出されます。このフィルターを使用して、認証、電流制限、パラメーターの検証および調整を行うことができます。
ルーティング：このフィルターは、リクエストをマイクロサービスにルーティングします。このフィルターは、マイクロサービスに送信されるリクエストを作成するために使用され、ApacheHttpClientまたはNetfilxリボンを使用してマイクロサービスをリクエストします。
POST（Post）：このフィルターは、マイクロサービスにルーティングした後に実行されます。このフィルターを使用して、標準のHTTPヘッダーを応答に追加したり、統計とメトリックを収集したり、マイクロサービスからクライアントに応答を送信したり、ログを記録したりできます。
エラー：他の段階でエラーが発生した場合は、このフィルターを実行してください。
ZuulとNginx
ZuulのパフォーマンスはNginxに匹敵しませんが、利点もあります。Zuulは、認証と承認、動的ルーティング、監視、復元力、セキュリティ、負荷分散などのエッジサービスを提供します。チームが小さく、ルーティング開発に特に責任がない場合は、Zuulをゲートウェイとして使用することをお勧めします。 。
NginxとZuulを一緒に使用して、それぞれの利点を活かすことができます。Nginxは、高い同時リクエスト転送を実現するためのロードバランサーとして使用され、Zuulはゲートウェイとして使用されます。
ZuulとRibbonが負荷分散を実現
ZuulはRibbonとHystrixをサポートし、クライアントの負荷分散も実現できます。私たちのFeignは、クライアント側の負荷分散とHystrixも実装していませんか？Zuulが実現できるようになった今、私たちのFeignはまだ必要ですか？
これは次のように理解できます。
Zuulは外部に公開されている唯一のインターフェースであり、これはコントローラーの要求をルーティングするのと同じですが、RibboneとFeginはサービスの要求をルーティングします。
Zuulは最も外側のリクエストの負荷分散を行い、RibbonとFeginはシステム内の各マイクロサービスのサービス呼び出しの負荷分散を行います。
Hystrix
前書き
Hystrixは、分散システムの遅延とフォールトトレランスを処理するために使用されるオープンソースライブラリです。分散システムでは、タイムアウトや例外など、回避できない多くの依存関係の呼び出しに失敗します。Hystrixは、依存関係の問題の場合、全体的なサービス障害を引き起こさず、カスケード障害を回避し、分散システムの復元力を向上させます。Hystrixは雪崩効果を解決するように見えました。
サービス雪崩
複数のマイクロサービス間で呼び出しを行う場合、マイクロサービスAがマイクロサービスBとマイクロサービスCを呼び出し、マイクロサービスBとマイクロサービスCが他のマイクロサービスを呼び出すとします。これは「ファンアウト」と呼ばれます。ファンアウトリンク上のマイクロサービスの呼び出し応答時間が長すぎるか利用できない場合、マイクロサービスAへの呼び出しはますます多くのシステムリソースを占有し、システムのクラッシュ、いわゆる「アバランシェ効果」を引き起こします。
サービスヒューズ
ヒューズメカニズムは、アバランシェ効果に対処するためのマイクロサービスリンク保護メカニズムです。
削除されたリンクのマイクロサービスが利用できない場合や応答時間が長すぎる場合、サービスが低下し、ノードマイクロサービスの呼び出しが融合し、間違った応答メッセージがすぐに返されます。ノードマイクロサービスの呼び出し応答時コールリンクは通常の後に復元されます。SpringCloudフレームワークでは、ヒューズメカニズムはHystrixによって実装されます。Hystrixはマイクロサービス間のコールのステータスを監視します。失敗したコールが特定のしきい値に達すると、デフォルトでは20コールが失敗します。 5秒でヒューズメカニズムが開始されます。ヒューズメカニズムの注釈は@HystrixCommandです。
サービスの低下
全体的なリソースがほとんどなくなっているので、私はしぶしぶ最初にいくつかのサービスをオフにし、次に問題を乗り越えた後にそれらをオンに戻します。
Hystrixモニタリングおよびサーキットブレーカー
このインターフェイスの監視およびサーキットブレーカ機能を実現するには、サービスインターフェイスにHystrixラベルを追加するだけで済みます。
Hystrixダッシュボード監視パネルは、各サービスのサービス呼び出しに費やされた時間を監視するためのインターフェースを提供します。
Hystrixタービンモニタリング集約
Hystrixモニタリングを使用するには、各サービスインスタンスのモニタリング情報を開いて表示する必要があります。Turbineは、すべてのサービスインスタンスの監視情報を1つの場所に集約して、統合して表示するのに役立ちます。このように、ページを1つずつ表示するためにページを1つずつ開く必要はありません。
Zuulのセキュリティメカニズム
署名メカニズム、インターフェースデータの改ざんや繰り返しの呼び出しを防ぐために、インターフェースパラメータ検証メカニズムが追加されています.sig署名アルゴリズムはMD5（appKey + appSecret + timestamp）、appKeyはクライアントに割り当てられたID、appSecretは秘密鍵ですクライアントに割り当てられたタイムスタンプこれはUnixタイムスタンプであり、要求されたURLは15分間有効です。
トークンメカニズム。ユーザーがログインすると、access_トークンが返されます。クライアントがログインする必要のあるリソースにアクセスするときは、ベアラーモードを使用して、head（ "Authorization]などのトークンをAuthorizationヘッダーに追加する必要があります。 "、"ベアラートークン "）。
Hystrixの設計原則
リソースの分離（スレッドプールの分離とセマフォの分離）メカニズム：分散サービスを呼び出すためのリソースの使用を制限します。呼び出されたサービスの1つに問題が発生しても、他のサービスの呼び出しには影響しません。
電流制限メカニズム：電流制限メカニズムは、主に各タイプのリクエストに最高のQPSしきい値を事前に設定することであり、設定されたしきい値よりも高い場合、リクエストは後続のリソースを呼び出さずに直接返されます。
ヒューズメカニズム：障害率がしきい値に達すると、劣化が自動的にトリガーされ（ネットワーク障害やタイムアウトによる障害率が非常に高いなど）、ヒューズによって引き起こされた高速障害はすぐに回復します。
劣化メカニズム：時間の経過とともに劣化する、リソースが不足している場合（スレッドまたはセマフォ）に劣化する、異常に劣化するなど。劣化した後、劣化したインターフェイスと連携して、最下位のデータを返すことができます。
キャッシュのサポート：リクエストキャッシュとリクエストマージの実装を提供します。
ほぼリアルタイムの統計/監視/アラーム機能を通じて、障害検出の速度を向上させます。
ほぼリアルタイムの属性と構成のホットモディフィケーション機能により、障害の処理と回復の速度を向上させます。
構成
前書き
Spring Cloud Configは、分散システム向けの構成管理ソリューションです。マイクロサービスとは、1つのアプリケーションでビジネスをサブサービスに分割することを意味します。各サービスの粒度は比較的小さいため、システムには多数のサービスが表示されます。各サービスを実行するには必要な構成情報が必要なため、一元化された動的な構成管理機能が不可欠です。Spring Cloudは、この問題を解決するためのConfigServerを提供します。各マイクロサービスは、何百もの構成ファイルを管理するためのapplication.ymlを提供します。
アプリケーションシナリオ
保守が不便で、複数の人が同時に構成ファイルを変更し、競合が続き、保守が困難
構成コンテンツのセキュリティとアクセス許可、主にオンライン構成の場合、通常は開発に公開されておらず、運用と保守のみにアクセス許可があるため、構成ファイルを分離してプロジェクトコードに配置しない必要があります
構成アイテムを更新するには再起動が必要であり、構成ファイルを更新するたびにアイテムを再起動する必要があり、これには時間がかかります。構成センターを使用した後、構成をリアルタイムで更新できます。congfigサーバーと構成クライアントをSpring Cloud Busと組み合わせて、構成の自動更新を実現します。
原理
構成ファイルはリモートGit（GitHub、Giteeなどのウェアハウスなど）に保存され、config-serverは構成ファイルをリモートGitからプルして、ローカルGitに保存します。
ローカルGitとconfig-serverの間の相互作用は双方向です。これは、リモートGitにアクセスできない場合、構成ファイルがローカルGitから取得されるためです。
config-client（つまり、各マイクロサービス）は、config-serverから構成ファイルをプルします。
役割
構成サーバー：構成ファイルのストレージを提供し、インターフェースの形式で構成ファイルのコンテンツを提供します。
構成クライアント：インターフェースを介してデータを取得し、このデータに基づいて独自のアプリケーションを初期化します。
次のように要約します。
