1. システム アーキテクチャの進化
システム アーキテクチャは一般に、単一アプリケーション アーキテクチャ→垂直アプリケーション アーキテクチャ→分散アーキテクチャ→SOA アーキテクチャ→マイクロサービス アーキテクチャ、そして新たなサービス メッシュ (サービス メッシュ) といういくつかのプロセスを経てきました
。アプリケーション アーキテクチャ
インターネットの初期の頃、一般的な Web サイト アプリケーションのトラフィックは比較的小さく、あまり多くのアプリケーションを必要としませんでした。そのため、すべての機能コードをまとめてデプロイするために 1 つのアプリケーションだけが使用されていました。これにより、開発とデプロイメントが削減されるだけでなく、メンテナンスのコストを節約できます。
利点: プロジェクト構造はシンプルで小規模プロジェクトに適しており、開発コストが低く、プロジェクトは 1 つのノードにデプロイされるため、保守が容易です。
短所: システム機能がすべて 1 つのエンジニアリング モンキーに集中しているため、中規模および大規模プロジェクトの開発と保守が容易ではない、システム モジュール間の結合が高く、単一点フォールト トレランス率が低い、最適化できないさまざまなモジュールに対して水平方向に拡張されます。
2. 垂直アプリケーション アーキテクチャ
効率を向上させるために、元のアプリケーションを複数の独立したアプリケーションに分割します。
利点: システムの分割により、トラフィックの共有が実現され、同時発生する問題が解決され、さまざまなモジュールに対して水平方向に最適化および拡張できます。1 つのシステムの問題が他のシステムに影響を与えず、フォールト トレランス率が向上します。
欠点: システムは相互に独立しており、相互に呼び出すことができず、開発タスクが繰り返されることになります。
3. 分散アーキテクチャ
プロジェクトはプレゼンテーション層とサービス層の 2 つの部分に分かれます サービス層にはビジネス ロジックが含まれます プレゼンテーション層はページとの対話処理のみを必要とします ビジネス ロジックはサービスを呼び出すことで実現されますサービス層の。
利点: 共通の機能をサービス層として抽出し、コードの再利用性を向上させます。
デメリット：システム間の結合度が高くなり、呼び出し関係が複雑になり、維持が困難になる。
4. SOA アーキテクチャ
コールセンターはリアルタイムでクラスタを管理し、リソースのスケジューリングとガバナンス センター (サービス指向アーキテクチャ) の鍵となります。
利点: 登録センターを使用すると、サービス間の呼び出し関係の自動調整が解決されます。
短所: サービス間に依存関係があり、特定のリンクに障害が発生すると大きな影響を及ぼします (サービス雪崩) サービスの関係が複雑で、運用と保守、テスト、デプロイが困難です。
5. マイクロサービス フレームワークは、
ある程度、サービス指向アーキテクチャ SOA の継続的な開発における次のステップであり、サービスの「完全な分割」に重点が置かれています。
利点: サービスは個別に分割、パッケージ化、デプロイ、アップグレードされるため、各マイクロサービスの明確なタスク分割が保証され、拡張に役立ちます。マイクロサービスは、Restful およびその他の軽量の http プロトコルを使用して相互に呼び出します。
短所: 分散システム開発の技術コストは高くなります (フォールト トレランス、分散トランザクションなど)。
2. マイクロサービス アーキテクチャ1.
マイクロサービス アーキテクチャの一般的に使用される
サービス ガバナンスとレジストリ管理。
安静にして、rpc を呼び出します。
ゲートウェイはクライアントのアクセスを制御します。
フォールトトレランス 問題発生後に自己処理を行います。
リンク追跡は、問題発生後のトラブルシューティングに使用できます。
2. マイクロサービス アーキテクチャの概念
2.1. サービス ガバナンスはサービスの自動管理であり、その中心となるのはサービスの自動登録と検出です。
サービス登録: サービス インスタンスは、独自のサービス情報を登録センターに登録します。
サービス検出: サービス インスタンスは、登録センターを通じてサービス インスタンスに登録されているサービス インスタンスの情報を取得し、この情報を使用してサービス インスタンスが提供するサービスを要求します。
サービスの削除: サービス登録センターは、問題のあるサービスを利用可能なリストから自動的に削除するため、そのサービスは呼び出されなくなります。
2.2. サービス呼び出し、HTTP ベースの RESTful インターフェイス、および TCP ベースの RPC プロトコル
REST: これは HTTP 呼び出し形式であり、より標準的でより一般的であり、http プロトコルをサポートする言語には関係ありません。
RPC: リモート サービスをローカル サービスであるかのように呼び出すことができるプロセス間通信の方法。RPC フレームワークの主な目標は、リモート サービス呼び出しをよりシンプルかつ透過的にすることです。RPC フレームワークは、基礎となる送信方法、シリアル化方法、および通信の詳細を保護する責任があります。
2.3. サービスゲートウェイ、API ゲートウェイは、すべての API 呼び出しを API ゲートウェイ層に均一に接続し、ゲートウェイ層は均一に接続して出力します。
ゲートウェイの基本機能には、統合アクセス、セキュリティ保護、プロトコル適応、トラフィック制御、長いリンクと短いリンクのサポート、およびフォールト トレランスが含まれます。
2.4. サービスのフォールト トレランス: マイクロサービスでは、多くの場合、リクエストには複数のサービスの呼び出しが含まれます。サービスのフォールト トレランスがないとサービスの 1 つが利用できなくなると、一連のサービスが利用できなくなる可能性が非常に高くなります。これが雪崩効果です。
サービスフォールトトレランスの 3 つの基本的な考え方:
外部環境に影響されない、
上流のリクエストによって潰されない、
下流の応答によって潰されない 2.6. マイクロサービスアーキテクチャ向けソリューション2.6.1. マイクロサービス向けのワンストップオープンソースソリューションを提供するServiceCombは、企業、ユーザー、開発者がエンタープライズアプリケーションをクラウドに簡単にマイクロサービス化し、マイクロサービスの効率的な運用保守管理を実現できるよう支援することに尽力しています。アプリケーションの。2.6.2、SpringCloud は、サービス検出登録、構成センター、メッセージ バス、ロード バランシング、サーキット ブレーカー、データ監視など、SpringBoot の開発利便性を利用して分散インフラストラクチャの開発を微妙に簡素化する一連のフレームワークのコレクションです。など、SpringBoot 開発スタイルを使用して、ワンクリックの起動とデプロイを実現できます。2.6.3. SPringCloud Alibaba は、分散アプリケーション マイクロサービスの開発に必要なコンポーネントを含む、マイクロサービス開発のワンストップ ソリューションを提供します
3、SpringCloud Alibaba
3.1、主要功能
服务限流降级：默认支持WebServlet、WebFlux、OpenFeign、RestTemplate、Spring Cloud Gateway、Zuul、Dubbo和RocketMQ限流降级功能的接入，可以在运行时通过控制台实时修改限流降级规则，还支持查看限流降级Metrics监控。
服务注册与发现：适配Spring Cloud服务注册与发现标准，默认集成了Ribbon的支持。
分布式配置管理：支持分布式系统中的外部化配置，配置更改时自动刷新。
消息驱动能力：基于Spring CLoud Stream为微服务应用构建消息驱动能力。
分布式事务：使用@GlobalTransactional注解，高效并且对业务零侵入地解决分布式事务问题。
阿里云对象存储：阿里云提供的海量、安全、低成本、高可靠的云存储服务，支持在任何应用、任何时间、任何地点存储和访问任意类型的数据。
分布式任务调度：提供秒级、精准、高可靠、高可用的定时（基于Cron表达式）任务调度服务。同时提供分布式的任务执行模型。
阿里云短信服务：覆盖全球的短信服务，友好、高效、智能的互联网通信能力，帮助企业迅速搭建客户通道。
3.2、组件
Sentinel：把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
Nacos:一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
RocketMQ：一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。
Dubbo：Apache Dubbo是一款高性能Java RPC框架。
Seata：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。
Alibaba Cloud ACM：一款在分布式架构环境中应用配置进行集中管理和推送的应用配置中心产品。
Alibaba Cloud OSS：阿里云对象存储对象，是阿里云提供的海量、安全、低成本、高可靠的云存储服务。
Alibaba Cloud SchedulerX：一款分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时任务调度服务。
Alibaba Cloud SMS：覆盖全球的短信服务，友好、高效、智能的互联网通讯能力，帮组企业迅速搭建客户通道
3. Nacos Discovery – サービス ガバナンス
1. サービス ガバナンスは、マイクロサービス アーキテクチャの中心となる最も基本的なモジュールであり、各マイクロサービスの自動登録と検出サービス登録を実現するために使用されます。サービス ガバナンス フレームワークでは、登録センターが設置されます
。各Aサービスユニットは、提供するサービスの詳細を登録センターに登録し、登録センターにサービスのリストを作成します。サービス登録センターは、リストにあるサービスが利用可能かどうかをハートビート方式で監視する必要があります。そうでない場合は、サービス リストに含まれている必要があります。使用できないサービスを削除してください。
サービス検出: サービス呼び出し元はサービス登録センターに問い合わせて、すべてのサービス インスタンスのリストを取得し、特定のサービス インスタンスへのアクセスを実現します。
一般的に使用される登録センター
Zookeeper は、分散サービス フレームワークであり、Apache Hadoop のサブプロジェクトであり、主に分散アプリケーションでよく発生するデータ管理の問題を解決するために使用されます。
Eureka は SpringCloud Netflix の重要なコンポーネントであり、その主な機能はサービスの登録と検出です。
Consul は GO 言語をベースに開発されたオープンソース ツールで、主に分散型サービス指向システム向けのサービス登録、サービス検出、構成管理の機能を提供します。Consul の機能は、サービスの登録/検出、ヘルスチェック、キー/値のストレージ、マルチデータセンター、分散一貫性保証などを含む非常に実用的です。Nacos は、動的なサービス検出、構成管理、およびサービス管理プラットフォームです
。 SpringCloud Alibaba のコンポーネントの 1 つであり、サービス登録の検出とサービスの構成を担当します。
2. nacos は使いやすい機能セットを提供し、速達配信により動的なサービスの検出、サービスの構成、サービスのメタデータ、およびトラフィック管理が実現されます。
3、实现服务调用的负载均衡,就是将负载（工作任务、访问请求）进行分摊到多个操作单元（服务器、组件）上进行执行；分为服务器负载均衡、客户端负载均衡。
4、基于Ribbon实现负载均衡
Ribbon是SpringCloud的一个组件，使用一个注解就能轻松的搞定负载均衡；在RestTemplate的生成方法上添加@LoadBalanced注解；Ribbon内置了多种负载均衡策略，顶级接口为com.netfix.loadbalancer.IRule
5、基于Feign实现服务调用
Feign是Spring Cloud提供的一个声明式的伪http客户端，它使得调用远程服务就像调用本地服务一样简单，只需要创建一个接口并添加一个注解即可。
Nacos很好的兼容了Feign，Feign默认集成了Ribbon，所以在Nacos下使用Feign默认就实现了负载均衡的效果
4. センチネルサービスの耐障害性
1. サービス雪崩効果
分散システムでは、ネットワーク上の理由やサービス自体の理由により、一般にサービスが 100% 利用可能であることが保証されず、サービスに問題がある場合、スレッドのブロッキングが発生します。このサービスを呼び出すときに、この時点でリクエストが大量に流入すると、複数のスレッドがブロックされて待機し、サービスが麻痺する原因になります。
サービス間の依存関係により、障害が伝播し、マイクロサービス システム全体に壊滅的な影響を及ぼします。これがサービス障害の雪崩効果です。
2. 一般的なフォールトトレラントソリューション
1) 分離とは、システムを特定の原則に従っていくつかのサービスモジュールに分割することを意味します。各モジュールは比較的独立しており、強い依存性はありません。障害が発生した場合、問題と影響を単一のグループに分離できます。モジュール内ではリスクが拡散せず、他のモジュールにも影響せず、システム サービス全体にも影響を与えない 一般的な分離方法には、スレッド プールの分離とセマフォの分離が含まれます。
2) タイムアウト: 上流サービスが下流サービスを呼び出すときに、最大応答時間を設定します。この時間を超えても下流サービスが応答しない場合、リクエストは切断され、スレッドは解放されます。
3) 電流制限は、システムを保護するという目的を達成するためにシステムの入出力の流れを制限することであり、システムの安定した動作を確保するには、制限する必要があるしきい値に達すると、流量を制限し、流量制限を完了するために少量の措置を講じます。
4) ヒューズ: ダウンストリーム サービスの応答が遅い場合、または過度のアクセス圧力により障害が発生した場合、システム全体の可用性を保護するために、アップストリーム サービスはダウンストリーム サービスへの呼び出しを一時的に切断することができます。全体を融合といいます。
サービスヒューズには、一般に 3 つの状態があります
ヒューズオフ状態：サービスに異常がない場合、ヒューズがオンの状態であり、発信者の通話に制限はありません。
ヒューズが有効になっている場合: サービス インターフェイスへの後続の呼び出しはネットワークを経由せず、ローカル フォールバック メソッドを直接実行します。
セミヒューズ状態: サービス呼び出しの復元を試み、制限されたトラフィックによるサービス呼び出しを許可し、呼び出しの成功率を監視します。成功率が期待値に達した場合、サービスが復元されてヒューズに入ったことを意味します。サーキット ブレーカー オフ状態
5) への移行 (ダウングレード) は、サービスにバッキング プランを提供することであり、サービスが正常に呼び出されなくなると、そのバッキング プランが使用されます。
共通フォールト トレラント コンポーネント
Hystrix は、Netflix によってオープンソース化された遅延およびフォールト トレラント ライブラリであり、リモート システム、サービス、またはサードパーティ ライブラリへのアクセスを分離し、連鎖的な障害を防止し、システムの可用性とフォールト トレランスを向上させるために使用されます。 。
Resilience4J は、非常に軽量でシンプル、そして非常に明確で豊富なドキュメント統合ツールです。
Sentinel は、Alibaba によってオープンソース化されたサーキット ブレーカーの実装であり、非常に安定しています。
3. Sentinel の紹介
1)、Sentinel (分散システム トラフィック ガード) は、サービスの耐障害性を実現する包括的なソリューションであり、サービスの安定性を保護します。
Sentinel には次の機能があります。
seckill、メッセージ ピーク シェービング、クラスター フロー制御、ダウンストリームで使用できないアプリケーションのリアルタイム融合などの豊富なアプリケーション シナリオ コンソールを介して完全なリアルタイム監視を行うと、システムの第 2 レベルのデータを確認できます
。アプリケーションに接続された単一クラスター
広範なオープン ソース エコロジー、他のオープン ソース フレームワーク/ライブラリとのすぐに使用できる統合モジュールを提供 完璧
な SPI 拡張ポイント、使いやすく完璧な SPI 拡張インターフェイスを提供し、拡張インターフェイスの実装によるロジック
2), Sentinel 2 つの部分に分かれています.
コア ライブラリはフレームワーク/ライブラリに依存せず、すべての Java ランタイム環境で実行でき、Dubbo/SpringCLoud などのフレームワークを適切にサポートしています
コンソールは SpringBoot に基づいて開発されており、Tomcat などの
追加の
アプリケーション コンテナを必要とせずに、パッケージ化した後直接実行できます。ます
。starter-alibaba-sentinel Sentinel は、マシン検出、スタンドアロン リソースのリアルタイム監視、およびルール管理機能を提供する軽量のコンソールを提供します。5. Sentinel の概念と機能1) 基本概念:リソースは Sentinel が保護したいものであり、Java アプリケーション内のあらゆるコンテンツであり、サービス、メソッド、またはコードの一部である場合もあります。ルールは、主にフロー制御ルール、ヒューズ ダウングレード ルール、システム保護ルールなど、リソースを保護する方法を定義するために使用されます。2）、重要な機能：フロー制御。ネットワークパケットのデータを調整するために使用されます。いつでも到着するリクエストはランダムで制御できないことが多く、システムの処理能力は限られているため、フローを制御する必要があります。システムの処理能力を調整するSentinelは、ランダムなリクエストを必要に応じて適切な形に調整することができます。ヒューズのダウングレードでは、コール リンク内のリソースの不安定なパフォーマンスが検出された場合、次の 2 つの方法が採用されます。
Sentinel は、リソースの同時スレッド数を制限することで、リソースの同時スレッド数を制限することで、不安定なリソースが他のリソースに与える影響を軽減します。応答時間が長くなるなど、リソースが不安定になると、リソースへの直接的な影響が生じます。スレッドの数が徐々に蓄積されるため、特定のリソース上でスレッドの数が一定量に蓄積されると、そのリソースに対する新しいリクエストは拒否され、蓄積されたスレッドはタスクの完了後もリクエストを受信し続けます。
応答時間を通じてリソースを低下させ、応答時間を通じて不安定なリソースをすぐにダウングレードできます。依存リソースの応答時間が長すぎる場合、リソースへのすべてのアクセスは、指定された時間枠まで直接拒否され、その後再開されます。
システム負荷保護。システム次元での自己適応型保護機能を提供します。システム負荷が高い場合、リクエストへのアクセスが続くと、システムがクラッシュして応答しなくなる可能性があります。クラスタ環境では、マシンがトラフィックは他のマシンに転送されます。この時点で他のマシンも限界状態にある場合、Sentinel はオブジェクト保護メカニズムを提供して、システムの受信トラフィックとシステム負荷のバランスをとり、システムが容量の範囲内に収まるようにします。 . 内でほとんどのリクエストを処理します。
6. センチネル ルール
1)、フロー制御ルール。フロー制御の原理は、アプリケーション トラフィックの QPS や同時スレッド数などの指標を監視し、指定されたしきい値に達したときにフローを制御することです。瞬間的なトラフィックのピークに圧倒されるため、アプリケーションの高可用性が確保されます。
リソース名: 一意の名前、デフォルトはリクエスト パスで、カスタマイズ可能
ソースの場合: フローを制限するマイクロサービスを指定、ソースに関係なく、すべての制限がデフォルトになります
しきい値タイプ/スタンドアロンしきい値:
QPS (1秒あたりのリクエストデータ量) : このインターフェースを呼び出すQPSが閾値に達した場合にフローを制限する
スレッド数: インターフェースを呼び出すスレッド数が閾値に達した場合にフローを制限する