システムデザインシリーズの初志
システム設計入門書： 和文档 GitHub - donnemartin/system-design-primer: 大規模システムを設計する方法を学びます。システム設計面接の準備をします。Anki フラッシュカードが含まれています。
中国語版: https://github.com/donnemartin/system-design-primer/blob/master/README-zh-Hans.md
本来の目的は主にシステム設計を学ぶことですが、中国語版は機械翻訳っぽいので、今でも手作業で簡単なメモを取り、わかりにくい部分はAIを活用して英語版と比較しながら学習しています。翻訳と知識の拡大。
アプリケーション層
出典: スケーラブルなシステム アーキテクチャの概要
まず、サービス層とアプリケーション層の概念を理解する必要があります。
サービス層
主にシステムのビジネスロジックの処理を担当します。サービス層は、データ検証、データ処理、ビジネス プロセス制御などを含む機能サポートをアプリケーション層に提供します。サービス層は、基礎となるデータ処理とロジックをカプセル化することでアプリケーション層に高いレベルの抽象化を提供し、アプリケーション層がこれらのサービスをより便利に使用できるようにします。
アプリケーション層
ソフトウェア システムの最上位であり、ユーザーに機能とサービスを直接提供します。アプリケーション層には、さまざまなアプリケーション、クライアント、サーバーなどが含まれます。アプリケーション層は、サービス層が提供する機能を呼び出すことで、ユーザーのニーズに応えます。アプリケーション層は、ユーザーインタラクション、ユーザーエクスペリエンス、さまざまなアプリケーションの実装に焦点を当てる必要があります。
関係
サービス層とアプリケーション層の関係は、主に次の側面に反映されます。
サービス層は、アプリケーション層にサービスを提供します。サービス層は、基礎となるデータ処理とロジックをカプセル化することにより、アプリケーション層に高いレベルの抽象化を提供します。アプリケーション層は、サービス層が提供する機能を呼び出すことで、ユーザーのニーズに応えます。
アプリケーション層はサービス層に依存します。アプリケーション層はさまざまな機能とサービスを実装する必要があり、これらの機能とサービスはサービス層によって提供されるサポートに大きく依存します。サービス層の設計の品質は、アプリケーション層のパフォーマンス、安定性、保守性に直接影響します。
サービス層とアプリケーション層は互いに分離されています。サービス層とアプリケーション層は機能的に互いに独立しており、それらの間のインターフェイスは明確です。このようにして、ニーズが変化した場合でも、柔軟に調整や修正を行うことができます。サービス層とアプリケーション層の間の相互分離の設計は、システムの保守性と拡張性の向上に役立ちます。
初期のサービス層はアプリケーション層に基づいて存在し、同じプラットフォーム上にデプロイされ、一緒に運用、保守されていました。
マイクロサービスの提案では、Web サービス層とアプリケーション層 (プラットフォーム層とも呼ばれます) が分離され、2 つの層は独立して拡張および構成できます。新しい API を追加するには、アプリケーション サーバーを追加するだけでよく、Web サーバーを追加する必要はありません。
単一責任の原則は、小規模で自律的なサービスの連携を促進します。小規模なチームは、小規模なサービスを提供することで、より積極的に成長を計画できます。
アプリケーション層の作業プロセスは非同期にすることもできます。
マイクロサービス
マイクロサービスは、独立してデプロイできる一連の小さなモジュール式サービスとして説明できます。各サービスは独立したスレッドで実行され、明確に定義された軽量メカニズムを通じて通信して、ビジネス目標を共同で達成します。
たとえば、Pinterest には、ユーザー プロフィール、フォロワー、フィード ストリーム、検索、写真のアップロードなどのマイクロサービスが含まれる場合があります。
アドバンテージ
マイクロサービスの主な利点は次のとおりです。
柔軟性: マイクロサービスは独立して開発、テスト、デプロイできるため、ソフトウェア開発の反復が高速化されます。同時に、各サービスは実際のニーズに基づいて適切なテクノロジー スタックを選択できるため、開発者はさまざまなビジネス シナリオにより柔軟に対応できます。
スケーラビリティ: 複雑なアプリケーションを複数の単純なマイクロサービスに分割することで、システムは必要に応じてより簡単に水平方向に拡張できます。これにより、システムはビジネス ニーズの変化に応じてリソースを迅速に調整し、システム全体のパフォーマンスを向上させることができます。
高可用性: 各マイクロサービスは独立しているため、1 つのサービスの障害がシステム全体のクラッシュを直接引き起こすことはありません。さらに、マイクロサービス アーキテクチャは通常、分散設計を採用しており、これによりシステムの耐障害性がさらに向上します。
疎結合: マイクロサービス間の通信には軽量の HTTP API が使用され、サービス間の依存関係がより緩やかになります。これにより、システム間の結合が軽減され、要件の変化に対してシステムの柔軟性が高まります。
欠点がある
マイクロサービスの欠点:
複雑さ: マイクロサービス アーキテクチャは通常、モノリシック アーキテクチャよりも複雑です。開発者は、複数のテクノロジー スタックを習得し、さまざまなサービスがどのように連携するかを理解し、サービス間の通信やデータの一貫性などの問題に対処する必要があります。
導入と運用のコスト: マイクロサービスは複数のプロセスで実行する必要があるため、導入と運用のコストが高くなる可能性があります。さらに、分散システムの監視、ログ管理、トラブルシューティングも困難です。
通信オーバーヘッド: マイクロサービス間の通信は通常 HTTP API に基づいており、これにより特定のネットワーク オーバーヘッドと遅延が発生する可能性があります。同時実行性が高いシナリオでは、通信のオーバーヘッドがパフォーマンスのボトルネックになる可能性があります。
データの一貫性: マイクロサービス アーキテクチャでは、異なるサービス間のデータの一貫性には特別な注意が必要です。サービス間のデータのやり取りは API を介して行われるため、データの同期やトランザクション処理に問題が発生する可能性があります。
セキュリティ: マイクロサービス アーキテクチャ内の複数のサービスにより、システムが攻撃に対してより脆弱になる可能性があります。開発者は、サービスのセキュリティ保護と、分散環境におけるセキュリティ問題への対処方法を十分に考慮する必要があります。
小規模プロジェクトに適しています: 一部の小規模プロジェクトではマイクロサービス アーキテクチャが複雑すぎて、リソースと時間が無駄になる場合があります。したがって、開発者は、プロジェクトの実際のニーズと規模に基づいて、適切なアーキテクチャを選択する必要があります。
サービスディスカバリ
Consul、Etcd、 Zookeeper などの システムは 、登録名、アドレス、ポート、その他の情報を追跡することで、サービスが相互に検出できるように支援します。ヘルスチェックは、 サービスの整合性と HTTP パスが定期的に使用されているかどうかを確認するのに役立ちます。 Consul と Etcd はどちらも、構成情報やその他の共有情報を保存するための組み込みの キー/値ストアを備えています。
主な工程
サービス検出の主なプロセスは次のとおりです。
- サービス登録: マイクロサービスが開始されると、そのアドレス、プロトコル、および関連するメタデータがサービス登録センターに登録されます。サービス レジストリは、他のサービスが見つけられるように、利用可能なサービスのリストを維持する責任があります。
- サービスの検出: マイクロサービスが別のマイクロサービスを呼び出す必要がある場合、サービス レジストリから利用可能なサービスのリストを取得します。マニフェスト内の情報に基づいて、呼び出し側サービスは呼び出し先のサービス アドレスとポートを見つけて、リモート呼び出しを行うことができます。
- サービス ヘルス チェック: サービス検出プロセス中に、呼び出されたサービスが正常に実行されていることを確認するために、サービスのヘルス チェックも実行する必要があります。サービス登録センターは、サービスによって提供される健康情報を定期的に受信して、サービスの状態を監視できます。
- サービスのログアウト: マイクロサービスの実行が停止すると、その情報がサービス登録センターからログアウトされます。このようにして、他のサービスがそのサービスを呼び出すと、そのサービスがもう存在しないことがわかり、呼び出しの失敗が回避されます。
サービス ディスカバリは、マイクロサービス アーキテクチャにおいて重要な役割を果たし、サービス間の位置と通信の問題を解決します。サービス ディスカバリを通じて、マイクロサービスはより柔軟かつ効率的に通信および連携できるため、システム全体のパフォーマンスとスケーラビリティが向上します。
アプリケーションはマイクロサービスを使用します
アプリケーション層が特定のマイクロサービスを呼び出すときは、次の手順を実行する必要があります。
- サービス登録: マイクロサービスが開始されると、そのアドレス、プロトコル、および関連するメタデータがサービス登録センターに登録されます。サービス レジストリは、他のサービスが見つけられるように、利用可能なサービスのリストを維持する責任があります。
- サービス検出: アプリケーションがマイクロサービスを呼び出す必要がある場合、アプリケーションはサービス レジストリから利用可能なサービスのリストを取得します。マニフェスト内の情報に基づいて、アプリケーションは呼び出す必要があるサービスのアドレスとポートを見つけて、リモート呼び出しを行うことができます。
- サービス呼び出し: アプリケーションは、HTTP またはその他のプロトコルを通じてマイクロサービスにリクエストを送信し、リクエストされたデータをマイクロサービスに渡します。マイクロサービスはリクエストを受信すると、データを処理して応答を生成し、その応答をアプリケーションに返します。
- 応答処理: アプリケーションは、マイクロサービスから返された応答を受信し、応答データを処理します。応答にエラー情報が含まれている場合、アプリケーションはエラー情報に基づいて、再試行やエラーの報告などの対応する処理を実行できます。
- 例外処理: サービス呼び出しプロセス中に、ネットワーク例外、タイムアウト、またはその他の異常な状況が発生した場合、アプリケーションはシステムの安定性と信頼性を確保するために、対応する例外処理を実行する必要があります。
- 負荷分散とサーキット ブレーカー: システムの可用性とパフォーマンスを向上させるために、負荷分散テクノロジーを使用してマイクロサービスを分散できます。さらに、マイクロサービスに障害が発生した場合、サーキット ブレーカー メカニズムを使用してマイクロサービスをサービス登録センターから削除し、他のアプリケーション呼び出しの失敗を回避できます。
上記のプロセスを通じて、アプリケーションはマイクロサービスを呼び出すことができるため、マイクロサービス アーキテクチャの利点が最大限に活用され、システムの柔軟性、拡張性、高可用性が向上します。同時に、呼び出しプロセス中は、マイクロサービス アーキテクチャの安定性と信頼性を確保するために、サービスのセキュリティやデータの一貫性などの問題にも注意を払う必要があります。