マイクロサービスアーキテクチャの進化過程＝「Spring Cloud」 Alibaba

1. システムアーキテクチャの進化

インターネットの発展に伴い、Web サイトのアプリケーションの規模も拡大し続けており、システムのアーキテクチャも継続的に変化しています。インターネットの黎明期から現在に至るまで、システムアーキテクチャは、
モノリシックアプリケーションアーキテクチャ→垂直アプリケーションアーキテクチャ→分散アーキテクチャ→SOAアーキテクチャ→マイクロサービスアーキテクチャ→サービスメッシュ（サービスグリッド）というプロセスを経てきました。 。

1.1 モノリシックアプリケーションアーキテクチャ

インターネットの初期には、一般的な Web サイト アプリケーションのトラフィックは少なく、すべての機能コードが 1 つのアプリケーションにデプロイされていたため、開発、デプロイ、およびメンテナンスのコストを削減できました。
  たとえば、電子商取引システムには、ユーザー管理、商品管理、注文管理、物流管理などの多くのモジュールが含まれます。これらを Web プロジェクトとして作成し、Tomcat サーバーにデプロイします。

利点:
プロジェクト構造がシンプルで、小規模なプロジェクトの場合は開発コストが低く、プロジェクトは 1 つのノードにデプロイされるため、保守が容易です。
欠点:
すべての機能が 1 つのプロジェクトに統合されている 大規模プロジェクトの場合、プロジェクトモジュール間の密結合の開発と維持が容易ではない 単一点耐障害性率が低く、異なるモジュールの最適化と水平拡張が不可能。

1.2 垂直アプリケーションアーキテクチャ

訪問数が徐々に増加すると、単一のアプリケーションはそれに対処するためにノードを追加することしかできなくなりますが、現時点では、すべてのモジュールの訪問数が比較的大きいわけではないことがわかり、ユーザーの訪問数の増加は、モジュールに影響を与えるだけである可能性があります。 user モジュールと order モジュールが追加されていますが、メッセージ モジュールへの影響は比較的小さいため、現時点では、メッセージ モジュールの代わりにさらにいくつかの注文モジュールを追加するだけでよいと考えています。このとき、単独適用は不可能であり、垂直適用が登場する。
  いわゆる垂直アプリケーション アーキテクチャでは、効率を向上させるために、元のアプリケーションをいくつかの独立したアプリケーションに分割します。たとえば、上記の単一の電子商取引アプリケーションを次のように分割できます。

• ECシステム（ユーザー管理、商品管理、注文管理）
• バックグラウンドシステム（ユーザー管理・受注管理・顧客管理）
• CMSシステム（広告管理・マーケティング管理）

分割完了後、ユーザーの訪問数が増えたら、バックグラウンドやCMSのノードを増やすことなく、ECシステムのノードを増やすだけで済みます。

利点:
システムの分割によりトラフィックの共有が実現され、同時実行性の問題が解決され、モジュールごとに最適化および水平拡張が可能
1 つのシステムの問題が他のシステムに影響を与えないため、耐障害性が向上します
欠点:
システムは互いに独立しており、相互接続できません呼び出し
システムは互いに独立しており、開発タスクが繰り返し発生します。

1.3 分散アーキテクチャ

垂直アプリケーションが増えると、重複するビジネスコードがますます増えます。このとき、重複しているコードを抽出して、ビジネス層を独立したサービスとして統一し、フロントエンド制御層が別のビジネス層のサービスを呼び出すことができないか考えました。
  これは、新しい分散システム アーキテクチャにつながります。プロジェクトはプレゼンテーション層とサービス層の 2 つの部分に分割され、サービス層にはビジネス ロジックが含まれます。プレゼンテーション層はページとのやり取りを処理するだけでよく、ビジネスロジックはサービス層のサービスを呼び出すことで実現されます。

利点:
共通の機能をサービス層として抽出し、コードの再利用性を向上させます。
デメリット：
システム間の結合度が高くなり、呼び出し関係が複雑になり、維持が困難になる。

1.4 SOA アーキテクチャ

分散アーキテクチャでは、サービスの数が増えると、容量評価や小規模なサービス リソースの無駄などの問題が徐々に顕在化し、その際、クラスタをリアルタイムで管理するためにスケジューリング センターを追加する必要があります。この時点で、リソースのスケジューリングおよびガバナンス センター (SOA サービス指向アーキテクチャ、サービス指向アーキテクチャ) が鍵となります。

利点:
登録センターを使用すると、サービス間の呼び出し関係の自動調整が解決されます。
デメリット：
サービス間に依存関係が存在し、一度リンクが狂うと影響が大きい（サービス雪崩）、サービスの懸念が複雑、運用保守、テスト展開が難しい。

1.5 マイクロサービスアーキテクチャ

マイクロサービス アーキテクチャは、ある程度、サービス指向アーキテクチャ SOA の継続的な開発における次のステップであり、サービスの「完全な分離」に重点が置かれています。

利点:
サービスの細分化、独立したパッケージ化、デプロイメント、アップグレード、各マイクロサービスの明確なタスク分割の確保、拡張されたマイクロサービス間で相互に呼び出すための Restful などの軽量 http プロトコルの使用を容易にします。
短所:
分散システム開発の技術コストは高くなります (フォールト トレランス、分散トランザクションなど)。

2. マイクロサービス アーキテクチャの概要

マイクロサービス アーキテクチャとは、簡単に言うと、単一のアプリケーションをさらに小さなサービスに分割し、各サービスは独立して実行できるプロジェクトです。

2.1 マイクロサービス アーキテクチャの一般的な問題

マイクロサービス システム アーキテクチャを採用すると、次の問題が必ず発生します。

• 小規模なサービスがたくさんありますが、それらをどのように管理すればよいでしょうか? (サービスガバナンスレジストリ[サービス登録検出の排除])
• 小規模なサービスが多数ある中で、それらはどのように相互に通信するのでしょうか? (安静な RPC)
• 小規模なサービスが多数ある中で、クライアントはどのようにしてそれらのサービスにアクセスするのでしょうか? （ゲートウェイ）
• 小規模なサービスが数多くある中で、一度問題が発生した場合、どのように対処すればよいのでしょうか。(耐障害性)
• 非常に多くの小規模なサービスで、問題が発生した場合、どのようにトラブルシューティングを行えばよいでしょうか? (リンク追跡)
  上記の問題については、マイクロサービス設計者が回避できないため、ほとんどのマイクロサービス製品はあらゆる問題を対象としており、それらを解決するために対応するコンポーネントが提供されています。

2.2 マイクロサービス アーキテクチャの共通概念

2.2.1 サービスガバナンス

サービス ガバナンスはサービスの自動管理であり、その中心となるのはサービスの自動登録と検出です。

• サービス登録: サービス インスタンスは、独自のサービス情報を登録センターに登録します。
• サービス検出: サービス インスタンスは、登録センターを通じてサービス インスタンスに登録されているサービス インスタンスの情報を取得し、この情報を使用してサービス インスタンスが提供するサービスを要求します。
• サービスの削除: サービス登録センターは、問題のあるサービスを利用可能なリストから自動的に削除するため、そのサービスは呼び出されなくなります。

2.2.2 サービスコール

マイクロサービス アーキテクチャでは、通常、複数のサービス間でリモート呼び出しが必要になります。現在、主流のリモート通話テクノロジーには、HTTP ベースの RESTful インターフェイスと TCP ベースの RPC プロトコルが含まれます。

• REST (Representational State Transfer): これは、HTTP プロトコルをサポートする言語に関係なく、より標準的でより一般的な HTTP 呼び出し形式です。
• RPC（Remote Promote Call）：プロセス間通信方式の一つ。リモート サービスをローカル サービスであるかのように呼び出すことができます。RPC フレームワークの主な目的は、リモート サービス呼び出しをより簡単かつ透過的に行うことです。RPC フレームワークは、基礎となる送信方法、シリアル化方法、および通信の詳細を保護する責任があります。これを使用する場合、開発者は誰がどの場所でどのような種類のリモート サービス インターフェイスを提供するかを知るだけでよく、基礎となる通信の詳細や呼び出しプロセスを気にする必要はありません。
  違いとつながり

2.2.3 サービスゲートウェイ

マイクロサービスの継続的な増加に伴い、通常、異なるマイクロサービスは異なるネットワーク アドレスを持ち、外部クライアントはビジネス要件を完了するために複数のサービス インターフェイスを呼び出す必要がある場合があります。クライアントが各マイクロサービスと直接通信する場合、次のように表示される場合があります。

• クライアントは別の URL アドレスを呼び出す必要があるため、難易度が高くなります。
• 特定のシナリオでは、クロスドメイン要求の問題が発生します。
• 各マイクロサービスには個別の認証が必要です。
    
    これらの問題に対処するために、API ゲートウェイが誕生しました。API ゲートウェイは、すべての API 呼び出しが API ゲートウェイ層に均一に接続され、ゲートウェイ層が均一に接続されて出力されることを直接意味します。ゲートウェイの基本機能には、統合アクセス、セキュリティ保護、プロトコル適応、トラフィック制御、長いリンクと短いリンクのサポート、およびフォールト トレランスが含まれます。ゲートウェイを使用すると、各 API サービス プロバイダー チームは独自のビジネス ロジックの処理に集中できますが、API ゲートウェイはセキュリティ、トラフィック、ルーティングなどの問題により重点を置くことができます。

2.2.4 サービスのフォールトトレランス

マイクロサービスでは、多くの場合、リクエストには複数のサービスの呼び出しが含まれます。サービスのフォールト トレランスがなければ、サービスの 1 つが利用できなくなると、一連のサービスが利用できなくなる可能性が非常に高くなります。これが雪崩効果です。
雪崩現象の発生を防ぐことはできず、フォールトトレラントになるよう最善を尽くすことしかできません。サービス フォールト トレランスの 3 つの中心的な考え方は次のとおりです。

• 外部環境の影響を受けない
• 上流のリクエストに圧倒されない
• 下流側の対応に悩まされない

2.2.5 リンク追跡

マイクロサービス アーキテクチャの人気により、サービスはさまざまな次元に応じて分割され、多くの場合、1 つのリクエストに複数のサービスが関与する必要があります。インターネット アプリケーションは、さまざまなソフトウェア モジュールのセットに基づいて構築されています。これらのソフトウェア モジュールは、さまざまなチームによって開発されたり、さまざまなプログラミング言語を使用して実装されたり、複数の異なるデータ センターにまたがる数千台のサーバーに展開されたりすることがあります。したがって、リクエストに含まれる複数のサービス リンクをログに記録する必要があり、パフォーマンス監視はリンク追跡です。

2.3 マイクロサービスアーキテクチャの一般的なソリューション

2.3.1 サービスコム

2.3.2 スプリングクラウド

Spring Cloud はフレームワークのコレクションです。Spring Boot の開発利便性を利用して、サービス検出登録、構成センター、メッセージ バス、ロード バランシング、サーキット ブレーカー、データ監視などの分散システム インフラストラクチャの開発を微妙に簡素化し、すべてを開発スタイルで実行できます。 Spring Boot をワンクリックで起動してデプロイすることができます。

Spring Cloud はホイールの製造を繰り返すのではなく、現在さまざまな企業によって開発されている成熟した実用的なサービス フレームワークを組み合わせただけであり、複雑な構成と実装原則を保護するために Spring Boot スタイルを通じて再パッケージ化し、最終的に開発者が残した理解しやすく、展開し、保守しやすい分散システム開発キットのセット。

2.3.3 SpringCloud アリババ

Spring Cloud Alibaba は、マイクロサービス開発のためのワンストップ ソリューションを提供することに尽力しています。このプロジェクトには分散アプリケーション マイクロサービスを開発するために必要なコンポーネントが含まれているため、開発者はこれらのコンポーネントを簡単に使用して、Spring Cloud プログラミング モデルを通じて分散アプリケーション サービスを開発できます。

2.3.3.1 Spring Cloud Alibaba の概要

Spring Cloud Alibaba は、マイクロサービス開発のためのワンストップ ソリューションを提供することに尽力しています。このプロジェクトには分散アプリケーション マイクロサービスを開発するために必要なコンポーネントが含まれているため、開発者はこれらのコンポーネントを簡単に使用して、Spring Cloud プログラミング モデルを通じて分散アプリケーション サービスを開発できます。
  Spring Cloud Alibaba を利用すると、いくつかのアノテーションと少量の構成を追加するだけで、Spring Cloud アプリケーションを Alibaba マイクロサービス ソリューションに接続し、Alibaba ミドルウェアを通じて分散アプリケーション システムを迅速に構築できます。

2.3.3.1.1 主な機能

• サービスレート制限とダウングレード: デフォルトでは、WebServlet、WebFlux、OpenFeign、RestTemplate、Spring Cloud Gateway、Zuul、Dubbo、RocketMQ へのアクセスをサポートします フロー低下メトリクスの監視。

• サービスの登録と検出: Spring Cloud サービスの登録と検出の標準に適応し、デフォルトでリボンのサポートを統合します。

• 分散構成管理: 分散システムでの外部構成をサポートし、構成が変更されると自動的に更新されます。

• メッセージ駆動型機能: Spring Cloud Stream に基づいて、マイクロサービス アプリケーションのメッセージ駆動型機能を構築します。

• 分散トランザクション: @GlobalTransactional アノテーションを使用して、分散トランザクションの問題を効率的に、ビジネスへの侵入をゼロに解決します。

• Alibaba Cloud Object Storage: Alibaba Cloud が提供する、大容量、安全、低コスト、信頼性の高いクラウド ストレージ サービス。いつでも、どこでも、あらゆるアプリケーションであらゆる種類のデータの保存とアクセスをサポートします。

• 分散タスク スケジューリング: 第 2 レベルの、正確で信頼性が高く、可用性の高いタイミング (Cron 式に基づく) タスク スケジューリング サービスを提供します。同時に、グリッド タスクなどの分散タスク実行モデルも提供します。グリッド タスクは、実行のためにすべてのワーカー (schedulerx-client) への sea quantum タスクの均等な分散をサポートします。

• Alibaba Cloud SMS サービス: 世界中をカバーする SMS サービス、フレンドリーで効率的、インテリジェントな相互接続通信機能により、企業が顧客アクセス チャネルを迅速に構築できるようにします。

2.3.3.1.2 コンポーネント

• Sentinel: トラフィックをエントリ ポイントとして、トラフィック制御、サーキット ブレーカーの劣化、システム負荷保護などの多面からサービスの安定性を保護します。
• Nacos: クラウドネイティブ アプリケーションの構築を容易にする、動的なサービス検出、構成管理、およびサービス管理プラットフォーム。
• RocketMQ: 可用性の高い分散クラスター テクノロジーに基づくオープン ソースの分散メッセージング システムは、低遅延で信頼性の高いメッセージ パブリッシュおよびサブスクリプション サービスを提供します。
• Dubbo: Apache Dubbo™ は、高性能 Java RPC フレームワークです。
• Seata: Alibaba のオープンソース製品で、使いやすい高性能マイクロサービス分散トランザクション ソリューションです。
• Alibaba Cloud ACM: 分散アーキテクチャ環境でアプリケーション構成を一元管理し、プッシュするアプリケーション構成センター製品。
• Alibaba Cloud OSS: Alibaba Cloud Object Storage Service (略して OSS) は、Alibaba Cloud が提供する大規模で安全、低コスト、信頼性の高いクラウド ストレージ サービスです。いつでも、どこでも、あらゆる種類のデータをあらゆるアプリケーションに保存してアクセスできます。
• Alibaba Cloud SchedulerX: Alibaba ミドルウェア チームによって開発された分散タスク スケジューリング製品で、第 2 レベルの正確で信頼性が高く、可用性の高いスケジュールされた (Cron 式に基づく) タスク スケジューリング サービスを提供します。
• Alibaba Cloud SMS: 世界中をカバーする SMS サービス、フレンドリーで効率的、インテリジェントな相互接続通信機能により、企業が顧客アクセス チャネルを迅速に構築できるようにします。

2.3.4 SpringCloudとSpringCloudAlibaba

Spring Cloud のマイクロサービス フレームワークがあるのに、なぜ再び Spring Cloud Alibaba のフレームワークを使用するのかと疑問に思う人も多いかもしれません。最も重要な理由は、Spring Cloud のほぼすべてのコンポーネントが Netflix の製品を使用しており、それに基づいてカプセル化の層が作成されていることです。しかし、Netflixのサービスディスカバリコンポーネント「Eureka」が更新を停止し、利用プロセスにも軽微な問題が発生しているため、現在その代替製品であるspring Cloud alibabaの開発が精力的に行われている状態である。SpringCloud コンポーネントの停止と置き換えの手順の詳細については、Baidu を参照してください。

2 つの類似点:
1. 通信方法: httprestful
2. 分散追跡リンク: sleuth+zipkin

したがって、マイクロサービスのワンストップ ソリューションの観点でも、長期的なプロジェクトのメンテナンスの観点でも、アリババが Springcloud に代わるのは避けられない傾向となっています。