Spring Cloud (Netflix、Alibaba) の共通コンポーネントの紹介

Spring Cloud の共通コンポーネントの紹介

1. 説明

近年のインターネットビジネスの活発な発展とマイクロサービス技術体系の継続的な改善・成熟に伴い、Spring BootとSpring Cloudサービスを組み合わせたシステム構築がマイクロサービス化に向けて発展し始めています。ガバナンス フレームワークは、ますます多くの開発チームによって認識されるようになり、徐々にエンタープライズ レベルのマイクロサービス構築の標準ソリューションになりました。

1.1.スプリングクラウドとは

Spring Cloud は、順序付けられたフレームワークのコレクションです。サービスディスカバリ登録、コンフィグレーションセンター、ロードバランシング、サーキットブレーカー、データモニタリングなど、Spring Boot の開発利便性をベースに分散システムインフラの開発を簡略化し、すべてをワンクリックで起動・起動できます。 Spring Boot 開発スタイル。

Spring Cloud は、さまざまな企業によって開発された比較的成熟した実用的なサービス フレームワークを結合し、Spring Boot スタイルで再カプセル化し、複雑な構成と実装原則を保護し、最終的には開発者に理解しやすく簡単なサービス フレームワークのシンプルなセットを提供します。導入と保守が容易な分散システム開発ツールキット。 Spring Cloud の主な支援者および貢献者には、Netflix や Alibaba など、国内外の多くの有名なインターネット テクノロジー企業が含まれており、Spring Cloud の継続的な進歩と発展を大きく推進してきました。

1.2.Spring Cloud コンポーネントの選択

Spring Cloud ファミリには多くのコンポーネントがあり、一部は単一サービスとして独立してデプロイされ、一部は高可用性クラスター分散方式でデプロイでき、一部はプラグインとしてアプリケーション サービスに統合されます。使用シナリオの充実とコミュニティ開発者の継続的な貢献により、Spring Cloud で同じタイプの機能を実装するコンポーネントから、それぞれが設計アイデアと機能に独自の焦点を当てたさまざまなブランチ サブプロジェクトが徐々に派生してきました。さらに、Spring Cloud ファミリ以外にもいくつかのオープンソース コンポーネントがあり、機能的に適合しているため、Spring Cloud コンポーネントと組み合わせてよく使用されます。そのため、ユーザーは自身の利用シーンに応じて柔軟に選択する必要があり、企業ユーザーはコンポーネントの成熟度や将来のサポートを考慮してコンポーネントを選択する必要があります。

以下は、開発者や設計者によるコンポーネントの選択と適用を容易にするために、一般的な Spring Cloud コンポーネントの機能と使用シナリオを簡単に紹介します。

2. コンポーネントの紹介

以下は、Spring Cloud の主要コンポーネントの紹介です。

2.1.サービスの登録と検出

サービスの登録と検出はサービス ガバナンスの基礎です。Spring Cloud Netflix サブプロジェクトの Eureka は、現在最も一般的に使用されている Spring Cloud サービス登録コンポーネントです。さらに、Nacos などの登録センター ソリューションもあります。 Spring Cloud Alibaba、Zookeeper については以下で説明し、広く使用されている Netflix Eureka と Alibaba Nacos についても紹介します。

2.1.1.Netflix エウレカ

Eureka は、Netflix がオープンソース化した REST サービスに基づくサービス登録および検出コンポーネントであり、最も広く使用されている Spring Cloud 登録センター コンポーネントです。現在、バージョン 1.x はまだメンテナンス中 (ネットワークのメンテナンスが停止したわけではありません) であり、バージョン 2.x は正式にリリースされていません。

1) 分散モデル

分散システムの CAP 理論は、分散システムの 3 つの特性、一貫性 (C)、可用性 (A)、およびパーティションフォールトトレランス (P) を要約したものですが、これら 3 つすべてを同時に達成することはできません。

Eureka の設計哲学は、Zookeeper の CP モデルとは異なる AP モデルに従うことです。 Eureka Server のすべてのノードは同等です。いくつかのノードに障害が発生しても、通常のノードの動作には影響しません。残りのノードは引き続き登録およびクエリ サービスを提供できます。 Eureka Client が Eureka Server に登録するときに、接続が失敗したことが検出されると、自動的に他のノードに切り替わります。 1 つの Eureka Server がまだ利用可能である限り、登録サービスは利用可能であることが保証されます (可用性の保証) が、検出される情報は最新ではない可能性があります (強整合性は保証されません)。

2) 主要成分

Eureka は主に 2 つのコンポーネントで構成されます。

Eureka Client: Eureka Server (通常はマイクロサービスのクライアントとサーバー) との対話を簡素化するために使用される Java クライアント

Eureka Server: サービスを登録および検出する機能を提供します (通常はマイクロサービスの登録センター)

3) 作業工程

サービス開始後、エウレカに登録され、エウレカサーバーは他のエウレカサーバーと登録情報を同期します サービス利用者がサービスプロバイダーに電話したい場合、サービス登録センターからサービスプロバイダーのアドレスを取得し、サービス プロバイダーのアドレスをローカルにキャッシュすると、次回呼び出されるときにローカル キャッシュから直接フェッチされて呼び出しが完了します。

複数のサービス プロバイダーがある場合、Eureka Client はリボンを通じて自動的に負荷分散を実行します。

図 2-1 Eureka の作業プロセス

4) クラスターの展開

Eureka Server クラスターは、レプリケートを通じて相互にデータを同期します。マスター ノードとスレーブ ノードの区別はありません。すべてのノードは平等です。 Eureka Server がダウンした場合、Eureka Client のリクエストは自動的に新しい Eureka Server ノードに切り替わります。ダウンしたサーバーが復旧すると、Eureka はそのサーバーを再びサーバー クラスター管理に組み込みます。ノードがクライアント要求の受け入れを開始すると、すべての操作がノード間でコピーされ、要求は現在他の Eureka サーバーに認識されているすべてのノードにコピーされます。

Eureka は、パーティショニングのためにリージョンとゾーンという 2 つの概念を提供しており、どちらの概念も Amazon AWS から来ています。

地域: アジア、中国、深センなどのさまざまな地理的領域として理解できます。特定のサイズ制限はありません。プロジェクトの具体的な状況に応じて、リージョンを自分で合理的に分割できます。

ゾーン: 地域内の特定のコンピューター室として簡単に理解できます。たとえば、地域が深センに分割され、深センには 2 つのコンピューター室があります。この地域の下に 2 つのゾーン (ゾーン 1 とゾーン 2) を分けることができます。

図 2-2 Eureka クラスター

上の図では、us-east-1c、us-east-1d、および us-east-1e は異なるゾーンを表しています。ゾーン内のエウレカ クライアントは、同じゾーン内のエウレカ サーバーとのハートビート同期を優先します。同様に、発信者はゾーン内のエウレカ サーバーからサービス リストを取得することを優先します。ゾーン内のすべてのエウレカ サーバーがハングアップすると、呼び出し元はゾーン内のエウレカ サーバーからサービス リストを取得することを優先します。他のゾーンの情報から取得します。

5) 高可用性メカニズム

サービス登録センター Eureka Server が、ダウンタイムまたはネットワークの理由によりサービス プロバイダーが利用できないことを検出すると、サービス登録センターはサービスをダウン状態に設定し、現在のサービス プロバイダーのステータスを加入者に公開します。加入者サービス コンシューマーはローカル キャッシュを更新します。

サービス プロバイダーは開始後、定期的に (デフォルトは 30 秒) ハートビートを Eureka Server に送信し、現在のサービスが利用可能であることを証明します。 Eureka Server は、一定時間 (デフォルトでは 90 秒) 以内にクライアントのハートビートを受信しない場合、サービスがダウンしていると見なし、インスタンスからログアウトします。

Eureka Server ノードが短期間に多数のクライアントを失うと (おそらくネットワーク障害が原因で)、ノードは自己保護モードに入り、マイクロサービスをログアウトしなくなります。ネットワーク障害が回復すると、ノードは次のようになります。自己保護モード。

2.1.2.アリババ ナコス

Nacos は Alibaba のオープンソース プロジェクトであり、その中心的な位置づけは「クラウド ネイティブ アプリケーションの構築を容易にする動的なサービス検出、構成、およびサービス管理プラットフォーム」です。 Nacos は、サービスの登録と検出、および動的構成管理の 2 つのコア機能を提供します。動的構成管理の詳細については、セクション 2.5.3 を参照してください。

1) 分散モデル

Nacos は、CAP 理論の AP アーキテクチャに属する分散アーキテクチャであり、結果整合性をサポートし、分散サービスの検出と登録のシナリオで非常に優れたパフォーマンスを発揮します。現在、Dubbo は Zookeeper の代わりに Nacos の使用を公式にサポートしています。

2) システムアーキテクチャ

Nacosは主に以下の4つの機能を提供します。

①サービス検出とサービスヘルスチェック: Nacos は、DNS または HTTP インターフェイスを通じて他のサービスを検出し、サービスのリアルタイムのヘルスチェックを提供して、異常なホストやサービスインスタンスからのリクエストを防ぎます。

②動的構成管理: Nacos を構成センターとして使用できます。詳細については、セクション 2.5.3 を参照してください。

③ダイナミックDNSサービス：Nacosは加重ルーティングをサポートしており、データセンターの実稼働環境で中間層のロードバランシング、柔軟なルーティングポリシー、フロー制御、シンプルなDNS解決サービスを実装できます。

④サービスとメタデータの管理: Nacos は、サービスのメタデータ、構成、Kubernetes DNS、サービスの正常性とインジケーターの統計などの管理を支援できる、使いやすいサービス ダッシュボードを提供します。

Nacos のシステムアーキテクチャは次のとおりです。

図 2-3 Nacos アーキテクチャ

3) 高可用性

Nacos は 2 つの展開モードをサポートしています。1 つは Eureka のような AP プロトコルの展開です。このモードは一時的なインスタンスのみをサポートし、コンピュータ ルームの災害復旧をサポートします。もう 1 つは永続インスタンスをサポートする CP モードで、この場合、デュアル マシン ルームのディザスタ リカバリはサポートされません。

Nacos が提供するマルチマシン ルーム展開ソリューションは、Nacos-Sync コンポーネントを使用してデータ センター間でデータを同期します。これは、各データ センターの Nacos クラスターに複数のデータ センターからの完全なデータが含まれることを意味します。

図 2-4 Nacos マルチマシンルームの展開

4) エウレカとの比較

以下は、Nacos と Eureka のいくつかの指標の比較です。

表 2-1 Nacos と Eureka の比較

項目を比較する	ナコス	ユーレカ
キャップモデル	AP および CP モデルをサポート	APモデル
クライアントがサービス情報を更新する方法	DNS-F クライアントはリッスン モードのプッシュ/プルを使用して更新情報をプルします	クライアントは定期的にサーバーをポーリングして、他のサービスの IP 情報を取得し、それを比較します。
スケーラビリティ	Raft 選出アルゴリズムは優れたパフォーマンス、可用性、耐障害性を備えており、新しいノードは同期情報をすべてのノードにブロードキャストする必要がありません。	ブロードキャスト同期情報を使用すると、クラスターのマシンが 1,000 台を超えると、Eureka クラスターは大きな負荷にさらされます。
ヘルスチェックモード/方法	サーバー/クライアント/クローズドチェックモードをサポート、チェック方法にはTcp、HTTP、SQLが含まれ、カスタムヘルスチェッカーをサポート	クライアントはHTTPハートビートをサーバーに送信します
負荷分散	サポート	サポート
手動によるオンラインおよびオフラインのサービス方法	コンソールページまたはAPI経由	APIを呼び出す
センター間同期ソリューション	サポート	サポートしません
重み	Nacos は、トラフィック プレッシャーを調整するためのウェイト設定機能をデフォルトで提供します。	サポートしません
メーカー	アリババ	Netflix

2.2.フロー制御

リクエスト フロー制御はサービス ガバナンスの主な手段であり、主にリクエストのロード バランシング、電流制限の低下、サービス サーキット ブレーカー、その他の機能が含まれます。

合理的な負荷分散戦略を構成することにより、サービスのスループット レートが向上し、全体的なサービス応答時間が短縮されます。電流制限ルールを事前に設定することにより、予想を超える特定のリクエストに選択的なアクセス制限が課されます。ダウングレードおよびサーキット ブレーカー戦略により、サービス障害時 利用不能または応答タイムアウトが発生した場合、システム全体の麻痺を防ぐために、サービスは一時的に停止されます。

大規模なトラフィック要求のシナリオに対処する場合、電流制限劣化とサービスサーキットブレーカーは標準的な技術ソリューションとなり、システムのスムーズな動作を確保する上で重要な役割を果たしています。

Spring Cloud Netflix は、クライアントの負荷分散、電流制限、サーキット ブレーカーをそれぞれ実装するための、Ribbon と Hystrix を提供し、ほとんどのシナリオのトラフィック制御ニーズを満たすことができます。また、トラフィック制御コンポーネントの統合を容易にする Feign も提供します。Feign+Ribbon+Hystrix は、現在最も一般的なフロー制御スキーム。さらに、Hystrix サーキット ブレーカーと同様の機能を実装できる Alibaba のオープンソース Sentinel もあります。これらのコンポーネントとソリューションを以下に紹介します。

2.2.1.Netflix フェーン + リボン + ヒストリックス

Netflix のオープンソースの Feign+Ribbon+Hystrix は、現在最も一般的なトラフィック制御ソリューションであり、リクエストのロード バランシング、電流制限の低下、サービスの中断などの機能を実現するために一般的に併用されます。

1) Netflix フェインの紹介

Feign は Java 言語で書かれた HttpClient バインダーであり、Spring Cloud マイクロサービスでマイクロサービス間の宣言呼び出しを実装するために使用されます。 Feign は、マイクロサービス間の呼び出しに使用される、他のサービスへのリクエストのインターフェイスを定義できます。http リクエストを自分で記述する必要はありません。クライアントに実装されます。このインターフェイスの呼び出しは、他のサービスをリモートで呼び出すのと同じです。リクエスト エラーが発生した場合、インターフェイスの実装を呼び出すことができます。

Feign は、Web サービス クライアントの作成を容易にする宣言型 Web サービス クライアントです。インターフェイスを作成し、インターフェイスに注釈を追加し、Feign を使用します。 Feign は Feign アノテーションまたは JAX-RS アノテーションを使用でき、ホットスワップ可能なエンコーダーとデコーダーもサポートします。 Spring Cloud は、Feign に Spring MVC アノテーション サポートを追加し、リボンと Eureka を統合して、Feign 使用時の負荷分散を提供します。

2) Netflix リボンの紹介

リボンは Netflix がリリースしたオープンソース プロジェクトで、その主な機能は、Netflix の中間層サービスを接続するためのクライアント側のソフトウェア負荷分散アルゴリズムを提供することです。リボン クライアント コンポーネントは、接続タイムアウト、再試行などの一連の完全な構成項目を提供します。簡単に言うと、構成ファイル内のロード バランサーの背後にあるすべてのマシンをリストすると、リボンが特定のルール (単純なポーリング、ランダム接続など) に基づいてこれらのマシンに接続するのを自動的に支援します。

リボンは 2 つのステップで動作します。最初のステップでは、同じゾーン内で負荷の少ないサーバーを優先する Eureka サーバーを選択します。2 番目のステップでは、指定されたポリシーに従ってサーバーから取得したサービス登録リストから選択します。ユーザーによるアドレス。リボンは、ポーリング、ランダム、応答時間に基づく重み付けなど、さまざまな戦略を提供します。

3) Netflix Hystrix の紹介

Hystrix は、サービス デグラデーション、サービス サーキット ブレーカー、スレッド分離、リクエスト キャッシュ、リクエスト マージ、サービス モニタリングなどの強力な機能を備えており、Spring Cloud のトラフィック制御コンポーネントとして最も一般的に使用されています。

Hystrix は、サーキット ブレーカーによる遅延や障害に対するフォールト トレランスを向上させることを目指しています。以下の4つの仕組みでこの問題を解決します。

①隔离（线程池隔离和信号量隔离）：限制调用分布式服务的资源使用，某一个调用的服务出现问题不会影响其他服务调用。

②优雅的降级机制：超时降级、资源不足时(线程或信号量)降级，降级后可以配合降级接口返回托底数据。

③熔断：当失败率达到阀值自动触发降级(如因网络故障/超时造成的失败率高)，熔断器触发的快速失败会进行快速恢复。

④缓存：提供了请求缓存、请求合并实现。

此外，Hystrix还基于Hystrix Dashboard支持流量实时状态监控，具体内容在2.4.2节介绍。

4）Feign+Ribbon+Hystrix之间的关系

图2-5 流量控制机制

在Spring Cloud微服务体系下，微服务之间的互相调用可以通过Feign进行声明式调用，在这个服务调用过程中Feign会通过Ribbon从服务注册中心获取目标微服务的服务器地址列表，之后在网络请求的过程中Ribbon就会将请求以负载均衡的方式打到微服务的不同实例上，从而实现Spring Cloud微服务架构中最为关键的功能即服务发现及客户端负载均衡调用。

另一方面微服务在互相调用的过程中，为了防止某个微服务的故障消耗掉整个系统所有微服务的连接资源，所以在实施微服务调用的过程中我们会要求在调用方实施针对被调用微服务的限流熔断逻辑。而要实现这个逻辑场景在Spring Cloud微服务框架下我们是通过Hystrix这个框架来实现的。

调用方会针对被调用微服务设置调用超时时间，一旦超时就会进入熔断逻辑，而这个故障指标信息也会返回给Hystrix组件，Hystrix组件会根据熔断情况判断被调微服务的故障情况从而打开熔断器，之后所有针对该微服务的请求就会直接进入熔断逻辑，直到被调微服务故障恢复，Hystrix断路器关闭为止。

2.2.2.Alibaba Sentinel

Sentinel是阿里中间件团队研发的面向分布式服务架构的轻量级高可用流量控制组件。Sentinel 主要以流量为切入点，从流量控制、熔断降级、系统负载保护、实时监控等多个维度来帮助用户提升服务的稳定性。

Sentinel 作为一个功能完备的高可用流量管控组件，其核心sentinel-core没有任何多余依赖，打包后只有不到200 KB，非常轻量级。开发者可以放心地引入sentinel-core而不需担心依赖问题。Sentinel和Hystrix一样，支持与Feign集成，方便客户端调用，同时，Sentinel提供了多种扩展点，用户可以很方便地根据需求去进行扩展，并且无缝地切合至Sentinel中。

1）流量控制

Sentinel可以针对不同的调用关系，以不同的运行指标（如QPS、并发调用数、系统负载等）为基准，对资源调用进行流量控制，将随机的请求调整成合适的形状。

Sentinel支持多样化的流量整形策略，在QPS过高的时候可以自动将流量调整成合适的形状。常用的策略有：

①直接拒绝模式：即超出的请求直接拒绝。

②慢启动预热模式：当流量激增的时候，控制流量通过的速率，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮。

③匀速器模式：利用Leaky Bucket算法实现的匀速模式，严格控制了请求通过的时间间隔，同时堆积的请求将会排队，超过超时时长的请求直接被拒绝。

2）负载保护

Sentinel对系统的维度提供保护，负载保护算法借鉴了TCP BBR的思想。当系统负载较高的时候，如果仍持续让请求进入，可能会导致系统崩溃，无法响应。在集群环境下，网络负载均衡会把本应这台机器承载的流量转发到其它的机器上去。如果这个时候其它的机器也处在一个边缘状态的时候，这个增加的流量就会导致这台机器也崩溃，最后导致整个集群不可用。针对这个情况，Sentinel提供了对应的保护机制，让系统的入口流量和系统的负载达到一个平衡，保证系统在能力范围之内处理最多的请求。

3）实时监控和控制面板

Sentinel提供HTTP API用于获取实时的监控信息，如调用链路统计信息、簇点信息、规则信息等。如果用户正在使用Spring Boot/Spring Cloud并使用了Sentinel Spring Cloud Starter，还可以方便地通过其暴露的 Actuator Endpoint 来获取运行时的一些信息。

4）与Netflix Hystrix的对比

Sentinel作为一款与Hystrix作用类似的流量控制组件，两者主要有以下异同点。

表2-2 Sentinel与Hystrix的异同

2.3.网关

随着微服务的兴起，API网关（API Gateway）也成为微服务的标配，API网关是位于在服务集群边界上的入口，主要解决请求路由、访问控制、权限认证等问题。

图2-6 API网关

微服务网关一般包含以下特征和功能。

l 高可用：微服务网关应该是高可用、无状态的。

l 请求路由：包括路由策略动态配置、灰度发布等功能。

l 流量控制：包括请求负载均衡、限流降级、服务熔断等功能。

l 权限认证：包括请求权限认证、参数解密、黑白名单等功能。

l 请求链路记录：包括请求耗时监控、链路日志支持等功能。

下面就对Spring Cloud最常用的两款网关组件进行介绍。

2.3.1.Spring Cloud Gateway

Spring Cloud Gateway是Spring官方基于Spring 5.0、Spring Boot2.0和Project Reactor等技术开发的网关组件，Spring Cloud Gateway旨在为微服务架构提供简单、有效和统一的API路由管理方式。Spring Cloud Gateway作为Spring Cloud生态系统中的网关，目标是替代Netflix Zuul，在Spring Cloud2.x微服务架构体系中发挥非常大的作用。

1）主要概念

Spring Cloud Gateway的几个重要概念如下：

①路由：路由是网关最基础的部分，路由信息由ID、目的URL、一组断言和一组Filter组成。如果断言路由为真，则说明请求的URL和配置匹配。

②断言：Spring Cloud Gateway中的断言函数输入类型是Spring5.0框架中的ServerWebExchange。断言函数允许开发者去定义匹配来自于Http Request中的任何信息，比如请求头和参数等。

③过滤器：Spring cloud gateway中的Filter是分为两种类型的Filter，分别是Gateway Filter和Global Filter，过滤器Filter将会对请求和响应进行修改处理。

2）工作流程

Spring Cloud Gateway接到请求后，由Gateway Handler Mapping中找到与请求相匹配的路由，将其发送到Gateway Web Handler，Handler再通过指定的过滤器链将请求发送到我们实际的服务执行业务逻辑，最后返回执行结果。

Spring Cloud Gateway的工作流程示例如下。

图2-7 Spring Cloud Gateway处理流程

3）主要功能及实现方式

网关作为流量入口，在微服务系统中有着十分重要的作用，常用功能包括以下几个方面。

①权限认证

Spring Cloud Gateway は、Filter に基づいた JWT などの認証戦略を実装し、リクエストパラメータを解析することでリクエストのパーミッション認証とトークン検証の配布を実現します。

以下は、Spring Cloud Gateway が権限認証を実行するプロセスの例です。

図 2-8 Spring Cloud Gateway の権限認証

②ダイナミックルーティング

ゲートウェイには、ルーティング構成とルーティング ルールという 2 つの重要な概念があり、ルーティング構成とは、指定された宛先アドレスにルーティングされる要求パスを構成することを指します。ルーティングルールとは、ルーティング設定に合わせた上で、ルーティングルールに基づいた転送処理を指します。

Spring Cloud Gateway はすべてのリクエストトラフィックのエントリポイントとして機能し、実際の本番環境での高信頼性と高可用性を確保するために、再起動は可能な限り回避されます。 RouteDefinitionRepository インターフェイスを実装して Spring Cloud Gateway 動的ルーティング構成を実装することで、ゲートウェイを拡張できます。

③フロー制御

Spring Cloud Gateway はデフォルトで電流制限フィルター RequestRateLimiterGatewayFilterFactory を提供し、電流制限実装クラス RedisRateLimiter はトークン バケットを使用して電流を制限します。ユーザーは独自のニーズに応じて AbstractGatewayFilterFactory を実装して、パーソナライズされた電流制限操作を実現できます。

Spring Cloud Gateway はリボンを統合して負荷分散戦略を実装できます。

Spring Cloud Gateway は、Hystrix を統合し、フィルターの下にサーキット ブレーカーのダウングレード構成を追加し、ダウングレード後に返されるルートを設定し、要求されたサービスのサーキット ブレーカーを実現することで、サーキット ブレーカーのダウングレードを実現できます。

2.3.2.Netflix ズールー語

Zuul は、Netflix によってオープンソース化された API ゲートウェイ サーバーであり、本質的には Web サーブレット アプリケーションです。 Zuul2.x バージョンのリリースが遅れたため、Spring は Spring Cloud2.x のデフォルト ゲートウェイとして独自の Spring Cloud Gateway を開発することを選択しましたが、Zuul は依然として多くの Spring Cloud システムで広く使用されています。

1) 主要な概念

Zuul の中核は一連のフィルターであり、その機能はサーブレット フレームワーク (AOP) のフィルターと比較できます。

Zuul はリクエストをユーザー処理ロジックにルーティングします。これらのフィルターは、認証、負荷制限などの一部のフィルター処理プロセスに参加します。

2) ワークフロー

Zuul でのリクエストのライフ サイクルを次の図に示します。

図 2-9 Zuul 権限認証

3) Spring Cloud Gatewayとの比較

Zuul2.x はまだ広く使用されていないため、Zuul1.x と Spring Cloud Gateway の主な指標のみを以下に示します。

表 2-3 Zuul と Spring Cloud Gateway の比較

	Spring クラウド ゲートウェイ	Netflix ズール 1.x
パフォーマンス	使用される WebFlux モジュールは Reactive Web フレームワークに基づいており、非同期、ノンブロッキング、イベント駆動型のサービスの構築に使用でき、スケーラビリティの点で非常に優れたパフォーマンスを発揮します。	Zuul 1.x、依然としてブロッキング I/O モデルに基づいており、パフォーマンスは Spring Cloud Gateway ほど良くありません
オープンソース組織	Spring Cloud Gateway は Spring Cloud のサブプロジェクトです	Zuul1.x は Netflix によって開発されたオープンソースであり、将来的に Spring Cloud に統合する予定はありません。
バージョン	Spring Boot 2.* に基づいています。	Spring Boot 1.* に基づいています。

2.4.サービス監視

完全なマイクロサービス監視は、サービスの安定性を確保するために必要な手段であり、Spring Cloud は、サービス インスタンスとサービス呼び出しリンクの監視を支援するいくつかの優れたコンポーネントも提供します。

以下は、Spring Cloud の一般的に使用されるサービス監視コンポーネントの紹介です。

2.4.1.Spring Boot 管理者

Spring Boot Admin は、SpringBoot アプリケーションの管理と監視に使用されます。アプリケーションは、Spring Boot 管理クライアントとして (HTTP 経由で) Spring Boot 管理サーバーに登録されるか、Spring Cloud レジストリ (Eureka、Consul など) を使用して検出されます。 UI は、Spring Boot 管理クライアントの Actuator エンドポイント上の監視を表示する Vue.js アプリケーションです。サーバーは Spring WebFlux + Netty を使用します。

Spring Boot Admin は、登録されたアプリケーションに対して次の機能を提供します。

l 健康状態の表示

l 詳細情報を表示します。たとえば、

l JVMとメモリのインジケーター

l micrometer.ioインジケーター

l データソースインジケーター

l キャッシュインジケーター

l ビルド情報番号の表示

l ログファイルをフォローしてダウンロードする

l jvmシステムおよび環境プロパティの表示

l Spring Boot構成プロパティの表示

Spring Cloud の投稿可能な /env- エンドポイントと /refresh-endpoint をサポートします

l 簡単なログレベル管理

l JMX-Bean との対話

l スレッドダンプを表示する

l http トレースを表示する

l 監査イベントの表示

l httpエンドポイントの表示

l スケジュールされたタスクを表示する

l アクティブなセッションの表示と削除 (spring-session を使用)

l Flyway/Liquibase データベースの移行を表示する

l ヒープダンプをダウンロードする

l ステータス変更通知 (電子メール、Slack、Hipchat などを介して)

l ステータス変更のイベントログ（非永続的）

以下は、Spring Boot Admin のサンプル スクリーンショットです。

図 2-10 Spring Boot 管理者

図 2-11 Spring Boot 管理者

図 2-12 Spring Boot 管理者

図 2-13 Spring Boot 管理者

2.4.2.Netflix Hystrix ダッシュボード + タービン

Hystrix Dashboard は、Hystrix をリアルタイムに監視するためのツールであり、Hystrix Dashboard を通じて、各 Hystrix コマンドのリクエスト応答時間、リクエスト成功率などのデータを直感的に確認できます。

ただし、Hystrix Dashboard だけでは単一アプリケーション内のサービス情報しか確認できないため、Turbine ツールを使用してシステム内の複数のサービスのデータを集約し、Hystrix Dashboard 上に表示する必要があります。

HystrixDashboard インターフェース監視パラメーターの例は次のとおりです。

図 2-14 Netflix Hystrix ダッシュボード インターフェイス

図 2-15 Netflix Hystrix ダッシュボード インターフェイス

2.4.3.スプリングクラウドスルース+ジップキン

Spring Cloud は、マイクロサービス リンク トラッキングを実装するための Zipkin の統合を容易にする spring-cloud-sleuth-zipkin を提供します。

1) 探偵の原理

Spring Cloud Sleuth は分散サービス リンク追跡ソリューションを実装しており、Sleuth を使用すると、特定のサービスの問題を迅速に特定できます。簡単に言えば、Sleuth はコール チェーン モニタリング ツールのクライアントに相当し、各マイクロサービスに統合され、コール チェーン モニタリング データの生成を担当します。

Spring Cloud Sleuth は Zipkin をカプセル化したもので、Span、Trace などの情報の生成、HTTP Request へのアクセス、Zipkin Server への収集情報の送信がすべて自動的に完了します。

Spring Cloud Sleuth は、次のタイプのコンポーネントを追跡できます: async、hystrix、メッセージング、websocket、rxjava、スケジューリング、Web (SpringWebMvc、Spring WebFlux、Servlet)、webclient (Spring RestTemplate)、feign、zuul。スルースはトランスをインターセプトして最下層にスパンを作成できます。

2) 主要な概念

①スパン（span）：スパンは仕事の基本単位です。スパンには、64 ビットの一意の ID、64 ビット トレース コード、説明情報、タイムスタンプ イベント、キーと値の注釈 (タグ)、およびスパン プロセッサの ID (通常は IP) が含まれます。

初期スパンはルート スパンと呼ばれ、このスパン内のスパン ID とトレース ID の値は同じです。

②トランス（トラッキング）：ツリー構造を形成する一連のスパンが含まれます。

③注釈: 既存のイベントをタイムリーに記録するために使用されます。一般的に使用される注釈は次のとおりです。

l CS (クライアント送信): クライアントはスパンの開始を示すリクエストを送信します。

l SR (サーバー受信): サーバーはリクエストを受信し、処理を開始します。 (SR - CS) はネットワークの遅延に等しい

l SS (サーバー送信): サーバーはリクエストの処理を完了し、サーバーに戻り始めます。 (SR - SS) は、サーバーがリクエストを処理するのにかかる時間を示します。

l CR (Client Received): クライアントは戻り結果の受信を完了し、この時点でスパンが終了します。 (CR - CS) は、クライアントがサーバーからデータを受信した時刻を示します。

3) ジップキンの紹介

サービスベースのアプリケーションのフルリンク追跡の問題に対応して、Google は Dapper 論文を発表し、サービス追跡分析の実施方法を紹介しました。基本的な考え方は、サービス呼び出しのリクエストと応答に ID を追加して、上流リクエストと下流リクエストの関係を示すことです。この情報を使用すると、サービス呼び出しのリンクとサービス間の依存関係を視覚的に分析できます。

Zipkin は Dpper に対応する実装であり、Twitter によってオープンソース化されています。

図 2-16 Zipkin アーキテクチャ

インスツルメントされたクライアントとインスツルメントされたサーバーは分散システム内のサービスであり、機器ライブラリを通じて追跡情報を収集し、機器ライブラリは Transport を呼び出して追跡情報を Zipkin に送信します。

Transport は Zipkin が外部と提供するインターフェースで、現在 HTTP、Kafka、Scribe の 3 種類があります。

Zipkin は、リンク データの永続的なストレージをサポートしています。

図 2-17 リンク追跡の例

図 2-18 リンク追跡の例

2.5.設定センター

システムがマイクロサービス化されると、もともと単一のアプリケーションに存在していた設定項目が多数のサブサービスに分散・分割されるため、多数の設定項目をいかに合理的に維持し、複数の実行インスタンスで設定項目の更新を効率的に完了させるかが課題となってきます。解決すべき緊急の問題、次元の問題。

Spring Cloud は、マイクロサービス シナリオで構成管理を実装するための構成センター コンポーネントとして Spring Cloud Config を提供します。さらに、構成センターのオプションとして、より強力でエンタープライズ アプリケーション シナリオにより適した Apollo と Nacos があります。

以下は、これらの構成センターのコンポーネントを比較して紹介します。

2.5.1.Spring クラウド構成

Spring Cloud Config は、分散システムの外部構成に対するサーバーとクライアントのサポートを提供します。便利な導入、運用、メンテナンス。

Spring Cloud Config サーバーは、分散構成センターとも呼ばれ、構成サーバーに接続し、クライアントが構成情報の取得、情報の暗号化/復号化などを行うためのアクセス インターフェイスを提供するために使用される独立したマイクロサービス アプリケーションです。クライアントは、構成センターを指定してアプリケーション リソースとビジネス関連の構成コンテンツを管理し、起動時に構成センターから構成情報を取得してロードします。デフォルトでは、GIT は構成情報の維持に使用され、データベース、SVN、ローカル ファイルなどを永続ストレージとして使用することもできます。

Spring Cloud Config には次の利点があります。

①アプリケーション、環境、バージョンの3次元で管理

②設定ストレージはGit、SVNなどの方式をサポート

③Springとのシームレスな統合、低移行コスト

Spring Cloud Config には次のような欠陥もあります。

① 動的な構成機能が弱く、構成を調整するには再デプロイや大量のコードの追加が必要です。

②ガバナンスとセキュリティ監査能力が弱い

③厳密にはエンタープライズレベルではなく、小規模プロジェクトにのみ適しています

2.5.2.アポロ

Apollo は、Ctrip のフレームワーク部門によって開発されたオープンソースの構成管理センターです。さまざまなアプリケーション環境とさまざまなクラスターの構成を一元管理できます。構成が変更された後、リアルタイムでアプリケーション側にプッシュでき、標準化されています権限、プロセス管理、その他の機能。

Apollo は、Key-Value 形式で構成を管理するために 4 つの次元をサポートしています。

l アプリケーション

環境

l クラスター

l 名前空間 (名前空間)

Apollo と Spring Cloud Config の比較は次のとおりです。

表 2-4 Spring Cloud Config と Apollo の比較

ファンクションポイント	アポロ	春のクラウド構成
設定インターフェース	統合インターフェース管理	なし
設定有効時間	リアルタイム	再起動して有効にする/更新/git webhook+MQ
バージョン管理	インターフェース操作	なし
グレースケールのリリース	サポート	なし
認可・監査・レビュー	インターフェイス操作は、変更権限と公開権限の分離をサポートします	git 操作が必要であり、権限を分離することはできません
インスタンス構成の監視	クライアント構成を参照してください	なし
構成取得パフォーマンス	高速、DB + キャッシュのサポート	git clone リポジトリ、ローカル ファイルを読み取る
クライアントサポート	Java、.Net、Spring アノテーション	Spring アプリケーション + アノテーションのサポート

2.5.3.アリババ ナコス

第2.1.2章で述べたように、NacosはSpring Cloudの登録センターコンポーネントとして機能するだけでなく、以下で簡単に紹介する構成センターの機能も含みます。

動的構成管理は、Nacos の 3 つの主要機能の 1 つであり、動的構成サービスを通じて、すべての環境ですべてのアプリケーションまたはサービスの構成情報を一元的かつ動的に管理できます。

動的構成センターは、構成の更新中にアプリケーションやサービスを再展開することなく、対応する構成情報を有効にすることができるため、システムの運用および保守能力が大幅に向上します。

Nacos サーバーは構成情報を保存します。クライアントがサーバーに接続すると、グループは dataID に基づいて特定の構成情報を取得できます。サーバー構成が変更されると、クライアントは通知を受け取ります。クライアントは、変更された最新の構成情報を取得すると、独自の処理を行うことができ、非常に便利です。構成が必要なすべてのシナリオは、Nacos を通じて管理できます。

Nacos は、サーバーの最新の構成情報をクライアントにプッシュするのではなく、クライアントは長いポーリング タスクを維持し、変更された構成情報を定期的にプルし、最新のデータをリスナー ホルダーにプッシュします。

ナコスとアポロの比較は以下の通り。

一般に、Apollo と Nacos は Spring Cloud Config よりも幅広いエコロジー サポートを備えており、構成管理プロセスにおいて優れています。 Apollo は Nacos よりも構成管理が包括的ですが、使用するのが面倒でもあります。 Nacos は使用が比較的簡単で、高いパフォーマンス要件を伴う大規模なシナリオに適しています。