シリーズ記事の目次
システムアーキテクチャ設計の高度なスキル ・ソフトウェアアーキテクチャの概念、アーキテクチャスタイル、ABSD、アーキテクチャ再利用、DSSA (1) 【システムアーキテクト】 システムアーキテクチャ設計の高度なスキル ・システムの品質属性とアーキテクチャ評価 (2) 【
システムアーキテクト
】システムアーキテクチャ設計・ソフトウェア信頼性解析・設計(3) 【システムアーキテクチャ設計者】
现在的一切都是为将来的梦想编织翅膀，让梦想在现实中展翅高飞。
Now everything is for the future of dream weaving wings, let the dream fly in reality.
システムアーキテクチャ設計における高度なスキル・クラウドネイティブアーキテクチャ設計の理論と実践
1. クラウド ネイティブ アーキテクチャの意味
1.1 定義
クラウド ネイティブ アーキテクチャは、クラウド ネイティブ テクノロジに基づくアーキテクチャ原則と設計パターンの集合であり、クラウド アプリケーションの非ビジネス コード部分を最大限に除去し、クラウド施設がクラウド アプリケーションの多くの元の非機能機能を引き継ぐことを可能にすることを目的としています。アプリケーション（弾力性、回復力、セキュリティ、コード部分など）が最大限に取り除かれ、クラウド機能が元の非機能機能（弾力性、回復力、セキュリティ、可観測性、グレースケールなど）の多くを引き継ぐことができます。 .) をアプリケーションに組み込むことで、機能外のビジネス中断に悩まされることはなくなりますが、軽量で機敏で、高度に自動化されています。
1.2 特徴
クラウド ネイティブ アーキテクチャに基づくアプリケーション機能は次のとおりです。
(1)コード構造が大幅に変化し、ファイルやその分散処理技術、複雑なネットワーク技術を習得する必要がなくなり、簡略化することでビジネス開発をより俊敏かつ迅速に行うことが可能になりました。
(2)高可用性、災害復旧、セキュリティ機能、操作性、使いやすさ、テスト容易性、グレースケール リリース機能など、多くの非機能的な機能がクラウド ネイティブ アーキテクチャに委ねられて解決されています。
(3)高度に自動化されたソフトウェア配信: クラウドネイティブに基づく自動化されたソフトウェア配信により、アプリケーションを数千のノードに自動的にデプロイできます。
1.3 クラウドネイティブの原則
クラウド ネイティブには次の原則があります。
(1)サービタイゼーションの原則: サービタイゼーションのアーキテクチャを通じて異なるライフサイクルのモジュールを分離し、ビジネスの反復を個別に実行します。
(2)弾力性の原理：弾力性とは、業務量の変化に応じてシステムの導入規模が自動的に拡大・縮小できることを意味します。
(3)可観測性の原則: ログ、リンク追跡、測定を通じて、時間のかかる複数のサービス呼び出しの戻り値とパラメータが明確に可視化されます。
(4)レジリエンス原理：ソフトウェアおよびそのソフトウェアが依存するハードウェアコンポーネントにさまざまな異常が発生した場合に、ソフトウェアが耐える能力。
(5)全プロセス自動化の原則：自動化ツールに配信目標と環境の違いを理解させ、ソフトウェア全体の配信と運用保守の自動化を実現します。
(6)ゼロトラスト原則: ネットワーク内外のいかなる人/デバイス/システムも信頼されるべきではなく、アクセス制御の信頼基盤は認証と認可に基づいて再構築される必要があります。
(7)アーキテクチャの継続的進化の原則：アーキテクチャは進化し続ける能力を持っています。
1.4 主なアーキテクチャ パターン
クラウド ネイティブに関係する主なアーキテクチャ パターン。
1.4.1 サービス指向アーキテクチャモデル
アプリケーションソフトウェアをアプリケーションモジュールの粒度で分割し、インターフェースコントラクト(IDLなど)で相互のビジネス関係を定義し、標準プロトコル(HTTP、gRPCなど)との相互接続を確保し、ドメイン駆動設計と組み合わせることが必要(DDD)、テスト駆動設計 (TDD)、およびコンテナー化されたデプロイメントにより、各インターフェイスのコードの品質と反復速度が向上します。
1.4.2 メッシュアーキテクチャモデル
メッシュ アーキテクチャは、ミドルウェア フレームワーク (RPC、キャッシュ、非同期メッセージなど) をビジネス プロセスから分離し、ミドルウェア SDK をビジネス コードからさらに切り離します。そのため、ミドルウェアのアップグレードはビジネス プロセスに影響を与えず、さらには移行さえも行います。プラットフォームのミドルウェアもビジネスに対して透過的です。
1.4.3 サーバーレスモード
ビジネストラフィックの到着またはビジネスイベントの発生時に、クラウドは開始されたビジネスプロセスの処理を開始またはスケジュールし、処理が完了すると、クラウドは自動的にビジネスプロセスを終了/スケジュールし、次のトリガーを待ちます。開発者はアプリケーションの実行場所、OS、ネットワーク構成、CPU性能などを気にする必要がなく、アプリケーションの運用をすべてクラウドに任せることができます。サーバーレス モードは、イベント駆動型のデータ コンピューティング タスク、コンピューティング時間の短い要求/応答アプリケーション、複雑な相互呼び出しのないサイクルの長いタスクに適しています。
1.4.4 記憶と計算の分離モード
分散環境における CAP の難しさは主にステートフル アプリケーションにあり、一貫性 (Consistency、C)、可用性 (Available、A)、および分割許容度 (Partition Tolerance、P) を同時に満たすことができないため、次のうち最大 2 つが満たされます。彼らは満足できるでしょう。したがって、ステートレス アプリケーションには一貫性という次元はなく、良好な可用性とパーティションのフォールト トレランスを実現できるため、より優れた弾力性を実現できます。
1.4.5 分散トランザクションモデル
ビジネスは複数のマイクロサービスにアクセスする必要があるため、分散トランザクションの問題が発生し、そうでないとデータに不整合が生じます。
(1) XA モード: XA 仕様は分散トランザクション処理を実現するための標準であるため、2 段階コミット (2 Prepare Commit、2PC )この方法は強い一貫性を持っていますが、2 つのネットワーク インタラクションが必要なため、パフォーマンスは低くなります。
(2) メッセージベースの結果整合性 (BASE): 可用性と整合性が矛盾する場合、両者を比較検討するために、BASE は、基本可用性 (BA) と結果整合性 (E) が満たされる限り、データを受け入れるソフトウェアを使用しないことを提案します。状態または不定状態 (S) を使用してパフォーマンスを優先するため、このタイプのシステムは通常、高いパフォーマンスを発揮します。ただし、アプリケーションの特性により、可用性と一貫性の間で妥協が選択されるため、汎用性が低くなります。
(3) TCC モデル: Try-confirm-Cancel の 2 段階モデルを使用すると、トランザクション分離は制御可能かつ効率的ですが、ビジネス モデルを 2 段階に分割するアプリケーション コードが必要となるため、ビジネスとコストへの負担が非常に大きくなります。設計、開発、メンテナンスのレベルが高いです。
(4) SAGA モード: 各フォワード トランザクションは補償トランザクションに対応しており、フォワード トランザクションの実行に失敗した場合、ロールバックのために補償トランザクションが実行されます。そのため、開発コストや保守コストが高くつきます。
(5) オープンソース プロジェクト SEATA の AT モード: TCC モードの第 2 フェーズを基盤となるコード フレームワークに委任し、行ロックを解除するため、非常に高性能でコード開発負荷がなく、自動的にロールバックを実行できます。ただし、使用シナリオにいくつかの制限があります。
1.4.6 観察可能なアーキテクチャ
監視可能なアーキテクチャには、ログ、トレース、およびメトリクスが含まれます。ログは、情報/デバッグ/警告/エラーなどの複数のレベルのトレースを提供します。トレースは、リクエストのフロントエンドからバックエンドまでのアクセス ログの集約を収集して、完全なログを形成します。コール リンク トレース、メトリクスは、同時実行性、時間消費、利用可能な時間、容量などを含むシステム定量化の多次元測定を提供します。
1.4.7 イベント駆動型アーキテクチャ
イベント駆動アーキテクチャ (EDA) は、アプリケーション/コンポーネント間の統合アーキテクチャ パターンです。サービス回復力の強化、データ変更通知、オープン インターフェイスの構築、イベント ストリーム処理、およびコマンド クエリ責任分離 (コマンド クエリ責任分離、CQRS) に適しています。サービス ステータスに影響を与えるコマンドは、サービス ステータスに影響を与えることなく、イベントを使用して開始されます。クエリ同期的に呼び出される API インターフェイスのみを使用します。
1.5 クラウド ネイティブ アーキテクチャの典型的なアンチパターン
アーキテクチャ設計では、さまざまなビジネス シナリオに基づいてさまざまな方法を選択する必要がある場合があります。一般的なクラウド ネイティブのアンチパターンには次のようなものがあります。
(1)巨大な単一アプリケーション: 依存関係の分離の欠如、コードの結合、責任とモジュールの間の境界の不明確、モジュール間のインターフェイスのガバナンスの欠如、変更の拡散、異なるモジュール間での開発の進捗とリリース時期の調整の困難、および 1 つのアプリケーションの不安定性その結果、アプリケーション全体の速度が低下し、拡張する際には全体としての容量拡張しかできず、ボトルネックに達しているモジュールを個別に拡張することはできません。
(2)モノリシックアプリケーションのマイクロサービスへの「ハード分割」：結合度が高く、コード品質が低いモジュールをサービスに強制的に分割します、分割後のサービスデータは密結合されますが、差別化後は分散呼び出しとなり、パフォーマンスに重大な影響を与えます。
(3)自動化機能のないマイクロサービス：担当者あたりのモジュール数が増加し、一人あたりの作業量が増加し、ソフトウェア開発コストも増加します。
2. クラウドネイティブアーキテクチャ関連技術
1.1 コンテナ技術
標準化されたソフトウェアの基本単位として、コンテナはアプリケーションとその依存関係をパッケージ化してリリースします。依存関係が完全であるため、アプリケーションは環境によって制限されなくなり、さまざまなコンピューティング環境ですばやく読み取って確実に実行できます。
コンテナ デプロイメント モードと他のモードの比較 (図に示すように、従来型、仮想化、およびコンテナ デプロイメント モードの比較):
1.2 コンテナオーケストレーションテクノロジー
コンテナ オーケストレーション テクノロジーには、リソース スケジューリング、アプリケーションのデプロイと管理、自動修復、サービスの検出と負荷分散、エラスティック スケーリング、宣言型 API、スケーラビリティ アーキテクチャ、移植性が含まれます。
1.3 マイクロサービス
マイクロサービス モデルは、バックエンドのモノリシック アプリケーションを、疎結合された複数のサブアプリケーションに分割し、各サブアプリケーションが一連のサブ機能を担当します。これらのサブアプリケーションは「マイクロサービス」となり、複数の「マイクロサービス」が集まって、物理的には独立しているが、論理的には完全な分散マイクロサービス システムを形成します。このマイクロサービスは比較的独立しており、開発、テスト、デプロイのプロセスを分離することで全体的な反復効率を向上させます。
マイクロサービス設計の制約は次のとおりです。
(1)マイクロサービスの個別の制約:
適切に設計されたマイクロサービス アプリケーションの場合、完成した機能はビジネス ドメインの分割に関して互いに独立している必要があります。言語と技術スタックに強制的にバインドされた単一のアプリケーションと比較して、この利点は、異なるビジネス ドメインが異なる技術オプションを備えていることであり、たとえば、Python を使用したレコメンデーション システムは Java よりもはるかに効率的である可能性があります。組織の観点から見ると、マイクロサービスは小規模なチームとより高い開発効率に対応します。「マイクロサービス チームは 1 回の食事でピザ 2 枚を食べることができる」と「マイクロサービス アプリケーションは少なくとも 2 週間ごとにイテレーションを完了できる必要がある」はすべて、ビジネス ドメイン内のマイクロサービスの境界を正しく分割する方法の比喩であり標準です。要約すると、マイクロサービスの「マイクロ」とは、マイクロであるためにマイクロであるのではなく、問題領域に応じて単一のアプリケーションを合理的に分割することです。さらに、マイクロサービスは、特定のビジネスに焦点を当て、SOLID 原則の単一責任原則 (SRP) である責任分担の観点から適切に実行する、直交的な分解特性も持つ必要があります。マイクロサービスが変更またはリリースされた場合、同じシステム内の別のマイクロサービスのビジネス相互作用に影響を与えるべきではありません。
(2)マイクロサービス間の水平関係
マイクロサービス間の境界を合理的に分割した後、サービス間の水平関係は主にマイクロサービスの発見可能性と対話性から扱われます。マイクロサービスの検出可能性とは、サービス A がリリース、拡張、または縮小されたときに、サービス A に依存するサービス B が、サービス A を再リリースせずにサービス A の変更をどのように自動的に検出できるかということを意味します? ここでサードパーティ サービスを導入する必要があります。サービスの発見可能性を満たすための登録センター。特に大規模なマイクロサービス クラスターの場合、サービス登録センターのプッシュおよび拡張機能が特に重要です。マイクロサービスの対話性とは、サービス A がサービス B を呼び出す方法を指します。サービスの自律性の制約により、サービス間の呼び出しには言語に依存しないリモート呼び出しプロトコルを使用する必要があります。たとえば、REST プロトコルは、「言語に依存しない」と「標準化」という 2 つの重要な要素を十分に満たしています。シナリオでは、IDL ベースのバイナリ プロトコルの方が良い選択となる可能性があります。さらに、業界における現在のマイクロサービスの実践のほとんどは、HATEOAS ヒューリスティック REST 呼び出しに到達しないことが多く、サービスは事前に合意されたインターフェイスを通じて呼び出しを完了する必要があります。サービス間の分離をさらに実現するために、マイクロサービス システムではサービスのメタデータ情報を保存する独立したメタデータ センターが必要で、サービスはそのセンターに問い合わせを行って通話内容を把握します。サービス リンクが増加し続けると、マイクロサービス システム全体がますます脆弱になるため、
マイクロサービス システムでは障害指向設計の原則が特に重要になります。個々のマイクロサービス アプリケーションでは、電流制限、サーキット ブレーカー、絶縁、負荷分散など、サービスの復元力を強化するメカニズムが標準になっています。システムのスループットをさらに向上させ、マシン リソースを最大限に活用するには、コルーチン、Rx モデル、非同期呼び出し、バックプレッシャーなどの手段を通じてこれを実現できます。
(3)マイクロサービスとデータ層間の垂直制約
マイクロサービスの分野では、データ ストレージ分離 (DSS) 原則が採用されています。つまり、データはマイクロサービスのプライベート資産であり、データへのアクセスは、現在のマイクロサービスが提供する API を介してアクセスする必要があります。そうしないと、データ層でカップリングが発生し、高結合性と低結合性の原則に違反します。同時に、パフォーマンス上の理由から、通常は読み取り/書き込み分離 (CQRS) が採用されます。同様に、コンテナーのスケジューリングが基盤となる施設の安定性に予測できない影響を与えるため、マイクロサービスの設計ではステートレスな設計原則に従うように努める必要があります。これは、上位のアプリケーションと基盤となるインフラストラクチャが分離され、マイクロサービスをそれらの間で自由にスケジュールできることを意味します。違う容器です。データ アクセス (つまりステートフル) を持つマイクロサービスの場合、通常、コンピューティングとストレージの分離を使用してデータを分散ストレージにシンクし、ある程度のステートレス性を実現できます。
(4)グローバルな観点から見たマイクロサービスの分散制約
マイクロサービス システムの設計の開始時から、システム全体の効率的な運用と保守、需要を満たす完全に自動化された CI/CD パイプラインの技術的準備などの要素を考慮する必要があります。これに基づいて、Blue-Green や Canary などのさまざまなリリース戦略をサポートし、ビジネス リリースの安定性の要求に応えます。複雑なシステムに直面して、フルリンク、リアルタイム、多次元の可観測性機能が標準になりました。運用保守のさまざまなリスクをタイムリーかつ効果的に防止するには、マイクロサービス システムの複数のイベント ソースから関連データを収集および分析し、集中監視システムで多次元的に表示する必要があります。マイクロサービスの分割が進む中、障害検出の適時性と根本原因の正確性は常に、開発担当者、運用保守担当者の中核的な要求となっています。
1.4 サービスレステクノロジー
サービスレステクノロジーの特徴:
(1) フルマネージド コンピューティング サービス。顧客はアプリケーションを構築するためのコードを記述するだけでよく、サーバーやその他のインフラストラクチャに基づいた同種かつ煩雑な開発、運用保守、セキュリティ、高可用性などの作業に注意を払う必要がありません。
(2) 汎用性とクラウド BaaS API の機能を組み合わせることで、クラウド上のすべての重要な種類のアプリケーションをサポートできます。
(3) 自動伸縮スケーリングにより、ユーザーはリソース使用量に応じて容量を事前に計画する必要がなくなります。
(4) 従量課金制により、企業はアイドル状態のリソースに料金を支払うことなく、使用コストを効果的に削減できます。
1.5 サービスネットワーク
Service Mesh は、マイクロサービス ソフトウェア アーキテクチャに基づいて分散アプリケーション用に開発された新しいテクノロジであり、マイクロサービス間の接続、セキュリティ、フロー制御、可観測性などの共通機能をプラットフォーム インフラストラクチャに組み込み、アプリケーションとプラットフォーム インフラストラクチャの分離を実現することを目的としています。この分離は、開発者がマイクロサービス関連のガバナンス問題に注意を払う必要がなくなり、ビジネス ロジック自体に集中できるようになり、アプリケーション開発効率が向上し、ビジネスの探索とイノベーションが加速されることを意味します。言い換えれば、サービス メッシュにより、大量の非機能性がビジネス プロセスから他のプロセスに取り除かれるため、非侵入的な方法でアプリケーションの軽量化が可能になります。
図に示すように、サービス グリッドの一般的なアーキテクチャは次のとおりです。
このアーキテクチャ図では、サービス A からサービス B を呼び出すすべてのリクエストは、その下のサービス プロキシによってインターセプトされます。プロキシ サービス A は、サービス B のサービス検出、サーキット ブレーカー、電流制限、およびその他の戦略を完了します。これらの戦略の全体的な制御は、コントロール プレーンで設定します。