##システム開発
1. 高凝集性/低結合性
高い凝集性とは、ソフトウェア モジュールが関連性の高いコードで構成されており、1 つのタスクのみを担当することを意味します。これは、単一責任原則とよく呼ばれます。モジュールの凝集度は、モジュール内の内部接続の緊密さを反映します。
モジュール間の接続が密になるほど、結合は強くなり、モジュールの独立性は悪くなります。モジュール間の結合のレベルは、モジュール間のインターフェイスの複雑さ、呼び出しメソッド、および転送される情報によって異なります。完全なシステムでは、モジュールは可能な限り独立して存在する必要があります。一般に、プログラム構造内の各モジュールの凝集度が高くなるほど、モジュール間の結合度は低くなります。
2. 過剰設計
過剰設計とは、過度に未来志向の設計を行ったり、比較的単純なものを過度に複雑にしたり、モジュール性、拡張性、設計パターンなどを過度に追求したりすることを意味します。
3. 時期尚早の最適化
時期尚早の最適化とは、開発プロセスの初期段階ではなく、将来の要件変更の方向性がまだ理解されていない段階を指します。最適化の結果、新しい要件を適切に実装できなくなるだけでなく、期待される最適化の推測が間違っている可能性があり、その結果、実際にはコードが複雑になるだけで何も得られない可能性があります。
正しい方法は、まずニーズを高品質で実装し、十分なテスト ケースを作成し、次にプロファイリングを行ってパフォーマンスのボトルネックを見つけ、その後でのみ最適化を行うことです。
4. リファクタリング
リファクタリングとは、プログラム コードを調整し、プログラムの設計パターンとアーキテクチャをより合理的にし、ソフトウェアの拡張性とパフォーマンスを向上させることにより、ソフトウェアの品質とパフォーマンスを向上させることです。メンテナンス性。
5. 割れ窓効果
割れ窓理論としても知られる割れ窓理論は、犯罪学の理論です。この理論は、環境内の望ましくない現象が存在することを許可すると、人々はそれらを模倣したり、さらには悪化させたりする誘惑に駆られるだろうと考えています。いくつかの窓が壊れた建物の場合、それらの窓が修復されないと、破壊者がさらに多くの窓を破壊する可能性があります。最終的には建物に侵入し、無人であることが判明した場合は、そこに住み着くか放火する可能性もあります。
ソフトウェア エンジニアリングに適用されるように、システム コードやアーキテクチャ設計に隠れた危険が表面化することを許してはなりません。そうしないと、時間の経過とともに、隠れた危険がますます深刻になってしまいます。逆に、高品質なシステムは、人々が無意識のうちに高品質なコードを書くようになります。
6. 相互不信の原則
# は、プログラム動作の上流および下流のリンク全体において、絶対的な信頼性を保証できるポイントはなく、どのポイントでも障害が発生するか、失敗する可能性があることを意味します。マシン ネットワーク、サービス自体、依存関係環境、入力とリクエストなどを含む予測不可能な動作があるため、常に警戒してください。
7. 永続性
永続性は、プログラム データを一時的な状態と永続的な状態の間で変換するためのメカニズムです。平たく言えば、一時データ (永続的に保存できないメモリ内のデータなど) は、永続データ (データベースまたはローカル ディスクに保存される、長期間保存できるデータなど) に永続化されます。
8. クリティカル セクション
クリティカル セクションは、複数のスレッドで使用できる共通リソースまたは共有データを表すために使用されますが、一度に使用できるのは 1 つのスレッドのみです。クリティカル セクションのリソースが占有されている場合、他のスレッドがこのリソースを使用したい場合は待機する必要があります。
9. ブロッキング/ノンブロッキング
ブロッキングとノンブロッキングは、通常、複数のスレッド間の対話を表します。たとえば、スレッドがクリティカル セクションのリソースを占有している場合、このリソースを必要とする他のすべてのスレッドはこのクリティカル セクションで待機する必要があり、待機するとスレッドがハングします。この状況はブロックされています。この時点で、リソースを占有しているスレッドがリソースを解放することに消極的であれば、このクリティカル セクションでブロックされている他のすべてのスレッドは動作できなくなります。ノンブロッキングでは、複数のスレッドが同時にクリティカル セクションに入ることができます。
10. 同期/非同期
通常、同期と非同期は関数/メソッドの呼び出しを指します。
同期とは、関数呼び出しを発行するときに、結果が取得されるまで呼び出しが返されないことを意味します。非同期呼び出しは即座に戻りますが、非同期呼び出しの即時戻りは、タスクが完了したことを意味するものではありません。バックグラウンドでスレッドを開始してタスクを続行し、タスクが完了した後、コールバックまたは他のメソッドを通じて呼び出し元に通知します。完成しました。
11. 同時実行/並列
並列とは、複数の命令が複数のプロセッサ上で同時に実行されることを意味します。したがって、ミクロの観点から見てもマクロの観点から見ても、この 2 つは同時に実行されます。
同時実行性とは、同時に実行できる命令は 1 つだけですが、複数のプロセス命令が高速回転で実行されることを意味します。これにより、マクロの観点からは複数のプロセスが同時に実行されるという効果がありますが、実際にはそうではありません。ミクロな視点で見ると同じ効果があり、同時に実行されるのではなく、時間をいくつかに分けて複数の処理を交互に素早く実行することができます。
アーキテクチャ設計
1. 高い同時実行性
分散システムの出現により、高い同時実行性 (High Concurrency) は通常、設計を通じてシステムが確実に実行されることを指します。多くのリクエストを同時に並行して処理できます。平たく言えば、高い同時実行性とは、多くのユーザーが同じ時点で同じ API インターフェイスまたは URL アドレスに同時にアクセスすることを意味します。これは、多数のアクティブ ユーザーが存在し、ユーザーが集中しているビジネス シナリオでよく発生します。
2. 高可用性
高可用性 HA (高可用性) は、分散システム アーキテクチャの設計において考慮する必要がある要素の 1 つであり、通常、特別に強化されたシステムを指します。サービスの高レベルの可用性を維持しながら、ダウンタイムを削減するように設計されています。
3. 読み取りと書き込みの分離
データベース製品の安定性を確保するために、多くのデータベースにはデュアルマシンのホット バックアップ機能が搭載されています。つまり、第 1 のデータベース サーバーは外部の追加、削除、および変更サービスを提供する運用サーバーであり、第 2 のデータベース サーバーは主に読み取り操作を実行します。
4. コールド スタンバイ/ホット スタンバイ
コールド スタンバイ: 2 台のサーバー (1 台は実行中、もう 1 台はバックアップとして実行されていません)。このようにして、実行中のサーバーがダウンしても、バックアップ サーバーが実行されます。コールド スタンバイ ソリューションは実装が比較的簡単ですが、ホストに障害が発生した場合にスタンバイ マシンが自動的に引き継ぎを行わず、サービスをアクティブに切り替える必要があるという欠点があります。
ホット スタンバイ: 一般にアクティブ/スタンバイ モードとして知られており、データベース データを含むサーバー データが 2 つ以上のサーバーに同時に書き込まれます。アクティブ サーバーに障害が発生すると、ソフトウェア診断 (通常はハートビート診断) によってスタンバイ マシンがアクティブ化され、アプリケーションが短期間で通常の使用状態に完全に復元されることが保証されます。 1 つのサーバーがダウンすると、自動的に別のバックアップ サーバーに切り替わります。
5. 遠隔地でのマルチアクティブ
遠隔地でのマルチアクティブとは、通常、異なる都市に独立したデータ センターを設立することを指します。「ライブ」とはコールド バックアップを指します。すべてのデータをバックアップします。通常、ビジネス ニーズはサポートされておらず、メイン コンピューター ルームに障害が発生した場合にのみバックアップ コンピューター ルームに切り替えられます。Duohuo は、これらのコンピューター ルームもトラフィックを処理し、日常業務でビジネス サポートを提供する必要があることを意味します。
6. 負荷分散
負荷分散は、トラフィックを複数のサーバーに分散する負荷分散サービスです。アプリケーションの外部サービス機能を複数のインスタンス間で自動的に割り当てることができ、単一障害点を排除してアプリケーション システムの可用性を向上させ、より高いレベルのアプリケーションのフォールト トレランスを実現できるため、アプリケーションの分散に必要な負荷をシームレスに提供できます。バランスの取れた容量により、効率的で安定した安全なサービスを提供します。
7. 動的と静的な分離
動的と静的な分離とは、静的ページを動的ページ、または静的コンテンツ インターフェイスと Web のさまざまなシステム アクセス用の動的コンテンツ インターフェイスから分離するアーキテクチャ設計方法を指します。サーバー アーキテクチャを改善し、全体的なサービス アクセスのパフォーマンスと保守性を向上させます。
8. クラスター
単一サーバーの同時処理能力は常に制限されており、単一サーバーの処理能力がパフォーマンスのボトルネックに達すると、複数のサーバーを組み合わせてサービスを提供します。この組み合わせをクラスターと呼び、クラスター内の各サーバーをクラスターの「ノード」と呼び、各ノードが同じサービスを提供できるため、システム全体の同時処理能力が 2 倍になります。
9. 分散
分散システムは、ビジネス機能に応じて、完全なシステムを多数の独立したサブシステムに分割します。各サブシステムは「サービス」と呼ばれます。分散システムは、ソートを要求し、異なるサブシステムに分散します。 、異なるサービスが異なるリクエストを処理できるようになります。分散システムでは、サブシステムは独立して実行され、ネットワーク通信を通じて接続され、データの相互運用性と複合サービスを実現します。
10. CAP理論
CAP理論とは、分散システムにおいては、Consistency（一貫性）、Availability（可用性）、Partition Tolerance（パーティションの耐障害性）を同時に確立することができないという事実を指します。 。
- 一貫性 : 分散システム内のすべてのデータ バックアップが、同じ時点で同じであるか、同じ状態であることが必要です。
- 可用性: システム クラスタ内の一部のノードがダウンした後でも、システムはユーザーのリクエストに正しく応答できます。
- パーティションフォールトトレランス: システムは、ノード間のネットワーク通信の障害を許容できます。
簡単に言えば、分散システムでは、上記の属性のうち最大 2 つをサポートできます。しかし、分散されているので当然パーティション分割する必要があり、パーティション分割されているため、パーティション エラーを 100% 回避することはできません。したがって、一貫性と可用性のどちらかを選択することしかできません。
分散システムでは、一貫性よりも重要な可用性が追求されることが多いため、高可用性を実現する方法について、CAP 理論をさらに拡張した BASE 理論という別の理論を紹介します。
11. BASE 理論
BASE 理論の指摘事項:
BASE 理論は、CAP における一貫性と可用性の間のトレードオフの結果です。理論の中心的な考え方は、「強力な一貫性を実現することはできませんが、すべてのアプリケーションは独自のビジネス特性に応じて、適切な方法を採用することができます」です。システムが最終的な一貫性を達成できるようにします。
12. 水平拡張/垂直拡張
水平拡張 スケールアウトでは、サーバーまたはプログラム インスタンスを追加することで負荷を分散し、ストレージ容量とコンピューティング能力を向上させます。さらに、Programming Technology Circle の公式アカウント バックエンドを検索して「モール」と返信すると、サプライズのギフトパッケージがプレゼントされます。
垂直方向の拡張スケールアップにより、単一マシンの処理能力が向上します。
垂直方向に拡張するには 2 つの方法があります:
- (1) スタンドアロン ハードウェアのパフォーマンスを強化します。例: CPU コアの数 (32 コアなど) を増やす、より優れたネットワーク カード (10G など) へのアップグレード、より優れたハード ドライブ (など) へのアップグレード。 SSD として、2T などのハード ドライブ容量を拡張し、128G などのシステム メモリを拡張します。
- (2) スタンドアロン ソフトウェアまたはアーキテクチャのパフォーマンスを向上します。たとえば、キャッシュを使用してパフォーマンスを削減します。 IO 時間、非同期を使用して単一サービスのスループットを向上、ロックフリーのデータ構造を使用して応答時間を短縮;
13. 並列拡張
# は水平拡張に似ています。 。クラスターサーバー内のノードはすべて並列ピアノードであり、拡張が必要な場合は、さらにノードを追加してクラスターのサービス機能を向上させることができます。一般に、サーバー内のクリティカル パス (ログイン、支払い、コア ビジネス ロジックなど) は、実行時に動的な並列拡張をサポートする必要があります。
14. 弾力的な拡張
は、デプロイされたクラスターの動的なオンライン拡張を指します。柔軟な拡張システムは、実際のビジネス環境や特定の戦略に応じて、さらに多くのノード (ストレージ ノード、コンピューティング ノード、ネットワーク ノードを含む) を自動的に追加して、システム容量の増加、システム パフォーマンスの向上、システムの信頼性の向上、またはこれら 3 つの目標を達成できます。同じ時間です。
15. 状態同期/フレーム同期
状態同期: 状態同期とは、サーバーがすべてのゲーム ロジックを計算し、これらの計算結果をブロードキャストする責任を負い、クライアントがプレイヤーの操作の送信と、受信したゲーム結果のパフォーマンスのみを担当します。
特徴: 状態同期は安全性が高く、ロジック更新は便利、切断・再接続は速いが、開発効率は低い ゲームやサーバーの複雑化に伴いネットワークトラフィックが増加より大きなプレッシャーに耐える必要があります。
フレーム同期: サーバーは論理処理を行わずにメッセージを転送するだけであり、各クライアントは 1 秒あたりのフレーム数が同じであり、各フレームで同じ入力データを処理します。
機能: フレーム同期では、システムが同じ入力の下で同じ出力を持つことを保証する必要があります。フレーム同期は、開発効率が高く、トラフィック消費量が少なく、安定性があり、サーバーへの負担がほとんどありません。ただし、ネットワーク要件は高く、切断と再接続に時間がかかり、クライアントのコンピューティング負荷が高くなります。
ネットワーク通信
1. 接続プール
接続バッファ プールを事前に確立し、一連の接続使用、割り当て、および管理戦略を提供して、接続プール の接続は効率的かつ安全に再利用できるため、頻繁な接続の確立と終了によるオーバーヘッドが回避されます。
2. 切断と再接続
ネットワークの変動により、ユーザーがサーバーから断続的に切断されます。ネットワークが回復すると、サーバーはユーザーを前回の状態に接続しようとします。接続されていません。データも残っています。
3. セッションの永続性
セッションの永続性とは、クライアントとサーバー間の対話プロセス間の相関関係を識別できるロード バランサー上のメカニズムを指します。一連の関連するアクセス要求が 1 台のマシンに分散されることを意味します。人間の言葉で言うと、セッション中に開始された複数のリクエストはすべて同じマシンに送られます。
4. ロングコネクション/ショートコネクション
通常、TCP のロングコネクションとショートコネクションを指します。長い接続とは、TCP 接続が確立された後、接続が維持されることを意味します。一般に、ハートビートを相互に送信して、通信の有無を確認します。途中で複数のビジネス データの送信が行われ、通常、接続は積極的に行われません。切断されました。短い接続とは通常、接続を確立し、トランザクション (http リクエストなど) を実行してから接続を閉じることを指します。
5. フロー制御/輻輳制御
フロー制御は、送信者が送信が速すぎて受信者のリソースを使い果たし、受信者が処理する時間がなくなることを防ぎます。
輻輳制御は、送信者がメッセージをあまりにも速く送信して、ネットワークが処理する時間がなくなって輻輳を引き起こし、その結果、この部分やネットワーク全体のパフォーマンスが低下することを防ぎます。 、ネットワーク通信サービスが停止する可能性もあります。
6. 雷鳴の群れ効果
雷鳴の群れ効果は雷鳴のグループ効果とも呼ばれますが、何と呼ぶのでしょうか? つまり、雷鳴の群れ現象とは、複数のプロセス (複数のスレッド) が実行されることです。 ) ブロックし、同じプロセスを同時に待機します。イベント中 (スリープ状態)、待機しているイベントが発生すると、待機中のすべてのプロセス (またはスレッド) がウェイクアップされますが、最終的には 1 つのプロセスのみがウェイクアップされます。 (スレッド) が今回の「制御」を取得する可能性があります。このイベントを処理すると、他のプロセス (スレッド) は「制御」の取得に失敗し、スリープ状態に戻ることしかできなくなります。この現象とパフォーマンスの浪費はパニック グループと呼ばれます。
7. NAT
NAT (Network Address Translation) は、IP パケットのヘッダー内のアドレス情報を置き換えることです。 NAT は通常、組織のネットワーク出口に導入され、内部ネットワーク IP アドレスを出口 IP アドレスに置き換えることにより、パブリック ネットワークへの到達可能性と上位層プロトコル接続を提供します。
障害例外
1. ダウンタイム
ダウンタイムとは、通常、予期せぬ障害によりコンピューター ホストがクラッシュすることを指します。次に、データベースのデッドロックなどの一部のサーバーはダウンタイムとも呼ばれ、サーバー上の一部のサービスがいわばハングアップします。
2. coredump
プログラム エラーが発生して異常中断されると、OS はプログラムの現在の作業ステータスを coredunmp ファイルに保存します。通常、コアダンプ ファイルには、プログラム実行時のメモリ、レジスタ ステータス、スタック ポインタ、メモリ管理情報などが含まれます。
3. キャッシュ侵入/ブレークダウン/雪崩
キャッシュ侵入: キャッシュ侵入とは、存在してはいけないデータをクエリすることを指します。キャッシュがヒットしないため、キャッシュを取得する必要があります。 from データベースにクエリを実行するときに、データが見つからない場合、そのデータはキャッシュに書き込まれません。これにより、リクエストされるたびにデータベース内に存在しないデータがクエリされることになり、データベースに負荷がかかります。
キャッシュ ブレークダウン : キャッシュ ブレークダウンとは、ホットスポット キーが特定の時点で期限切れになり、この時点でこのキーに対して多数の同時リクエストが発生し、その結果、大量のリクエストがデータベースにヒットします。
キャッシュなだれ: キャッシュなだれとは、キャッシュ内の大量のデータのバッチと膨大な量のクエリ データの有効期限を指し、データベースに過剰な負荷がかかったり、ダウンタイムが発生したりすることもあります。
キャッシュ ブレークダウンとの違いは、キャッシュ ブレークダウンはホットスポット キーの障害であり、キャッシュ アバランチは同時に多数のキーの障害であることです。
4. 500/501/502/503/504/505
500 内部サーバー エラー: 内部サービス エラー 通常、サーバーは予期しない状況に遭遇し、リクエストを完了できません。考えられる理由:
501 未実装: サーバーは、要求された HTTP リクエストを理解またはサポートしていません。
502 Bad Gateway: WEB サーバーに障害があります。プログラムのプロセスが不十分である可能性があります。要求された php-fpm は実行されましたが、何らかの理由で完了せず、最終的に php-fpm プロセスが発生します終了します。考えられる理由:
503 サービスを利用できません: サーバーは現在利用できません。システム保守サーバーは一時的にクライアントの要求を処理できませんが、これは一時的な状態にすぎません。サーバープロバイダーに問い合わせることができます。
504 ゲートウェイ タイムアウト: サーバー 504 エラーはタイムアウトを示します。これは、クライアントによって送信されたリクエストがゲートウェイに到達せず、リクエストが実行可能な php-fpm に到達しないことを意味します。これは通常、 nginx.conf の設定に関連します。
505 HTTP バージョンがサポートされていません: サーバーは、リクエストで使用されている HTTP プロトコルのバージョンをサポートしていません。 (HTTP バージョンはサポートされていません)
プログラミング言語エラーである可能性がある 500 エラーを除いて、残りのエラーはおそらくサーバーまたはサーバー構成の問題として理解できます。
5. メモリ オーバーフロー/メモリ リーク
メモリ オーバーフロー: メモリ オーバーフロー (メモリ不足) とは、プログラムがメモリを要求したときに、プログラムに必要なメモリが不足していることを意味します。つまり、int 型データを格納するためのストレージ領域が与えられているのに、long 型データを格納すると、結果としてメモリが不足し、OOM エラーが報告されます。いわゆるメモリオーバーフロー。
メモリ リーク: メモリ リークとは、プログラム内で動的に割り当てられたヒープ メモリが解放されていないか、何らかの理由で解放できないことを指します。その結果、システム メモリが無駄に消費され、プログラムの実行速度が低下します。システムクラッシュなどの重大な結果を引き起こす可能性もあります。
6. ハンドル リーク
ハンドル リークとは、プロセスがシステム ファイルを呼び出した後に開いているファイル ハンドルを解放しないことを意味します。ハンドル リーク後の一般的な現象は、マシンの速度が低下し、CPU の使用率が急上昇し、ハンドル リークが発生した CGI またはサーバーの CPU 使用率が増加することです。
7. デッドロック
デッドロックとは、実行中に 2 つ以上のスレッドがリソースを競合したり通信したりすることによって引き起こされるブロック現象を指します。外部の力がなければ、すべてのスレッドがブロックされ、実行できなくなります。このとき、システムはデッドロック状態にある、またはシステムにデッドロックが発生していると言われます。
8. ソフト割り込み/ハード割り込み
ハード割り込み: 通常、割り込みとはハード割り込み (hardirq) を指します。
主に、システム周辺機器のステータスの変化をオペレーティング システムに通知するために使用されます。
ソフト割り込み: 1. 通常、カーネルはハード割り込みサービス ルーチンによって割り込まれます; 2. リアルタイム システムの要件を満たすために、割り込み処理は次のようにする必要があります。できるだけ早く。
Linux この機能を実現するために、割り込みが発生した場合、短時間で完了する作業はハード割り込みで処理し、割り込み後にイベントを処理する長時間の作業は完了します。つまり、ソフト割り込みは短時間で完了できる作業を処理します。割り込み (softirq) を実行して完了します。
9. 不具合
ある瞬間に、サーバーのパフォーマンス指標 (トラフィック、ディスク IO、CPU 使用率など) が、その瞬間の前後の期間よりも大幅に大きくなります。不具合が発生するということは、サーバー リソースが不均一かつ不十分に利用されていることを意味しており、他のより深刻な問題に簡単につながる可能性があります。
10. リプレイ攻撃
攻撃者は、宛先ホストが受信したパケットを送信してシステムを欺き、主に身元認証プロセスに使用され、認証の正当性を破壊します。リプレイ攻撃は、有効なデータ送信を悪意を持って継続的に繰り返す攻撃の一種であり、開始者またはデータを傍受して再送信する攻撃者によって実行される可能性があります。攻撃者は、ネットワーク監視またはその他の方法を使用して認証資格情報を盗み、認証サーバーに再送信します。
11. ネットワーク アイランド
ネットワーク アイランドとは、一部のマシンがクラスター全体とのネットワーク接続を失い、小さなクラスターに分割され、データの不整合が発生するクラスター環境の状況を指します。
12. データ スキュー
クラスター システムの場合、キャッシュは通常分散されます。つまり、異なるノードが特定範囲のキャッシュ データを担当します。キャッシュされたデータが十分に分散されていないため、大量のキャッシュされたデータが 1 つまたは複数のサービス ノードに集中します。これをデータ スキューと呼びます。一般に、データ スキューは負荷分散の実装が不十分なことが原因で発生します。
13. スプリットブレイン
スプリットブレインとは、クラスタシステム内の一部のノード間でネットワークが到達できないことによりシステムが分割されることを指し、分割された小規模なクラスタがそれぞれの状態に応じてサービスを提供します。クラスターでは同時に一貫性のない応答が発生し、ノード間でリソースの競合が発生し、システムが混乱し、データが破損します。
アラームの監視
1. サービス監視
サービス監視の主な目的は、サービスに問題が発生した場合に正確かつ迅速に検出し、問題を軽減することです。または問題が発生しようとしている。影響範囲が狭い。一般に、サービス監視には多くの方法があり、次のレベルに分類できます。
- システム層 (CPU、ネットワークステータス、IO、マシン負荷など)
- アプリケーション層 (プロセスステータス、エラーログ、スループットなど) )
- ビジネス層 (サービス/インターフェイスのエラー コード、応答時間)
- ユーザー層 (ユーザーの行動、世論監視、フロントエンド)トラッキング)
2. リンク全体の監視
サービス ダイヤル テスト: サービス ダイヤル テストは、サービス (アプリケーション) の可用性を検出する監視方法です。 ). ダイヤル テスト ノードを通じて、ターゲット サービスは主に可用性と応答時間によって測定され、定期的に検出されます。通常は、異なる場所に複数のテスト ノードがあります。
ノード検出: ノード検出は、主に応答時間とパケット損失率を通じて、異なるコンピュータ ルーム (データ センター) にあるノード間のネットワークの可用性とスムーズさを検出および追跡するために使用される監視方法です。ホップ数が測定され、検出方法は通常、ping、mtr、またはその他のプライベート プロトコルです。
アラーム フィルタリング : 特定の予測可能なアラームをフィルタリングし、少数のクローラのアクセスによって引き起こされる http 応答 500 エラー、ビジネス システムのカスタム例外情報などのデータをアラーム統計から除外します。
アラーム重複排除: アラームが担当者に通知されると、アラームが復旧するまで同じアラームは再度受信されません。
アラーム抑制: システム ジッターによって引き起こされる干渉を軽減するには、抑制も実装する必要があります。たとえば、サーバーに対する一時的な高負荷は正常である可能性があります。高負荷を一定時間継続する必要がありますので注意してください。
アラーム復旧: 開発/運用/保守担当者は、アラーム通知を受け取るだけでなく、障害が解消され、アラームが正常に戻ったという通知も受け取る必要があります。
アラームのマージ: 同時に生成された複数の同一のアラームをマージします。たとえば、複数のサブサービス負荷アラームがマイクロサービス クラスターに同時に表示される場合、それらをマージする必要があります。 1つのアラームにまとめられます。
アラームの収束: アラームが発生すると、他のアラームも同時に発生することがあります。現時点では、根本原因に対するアラームのみを生成でき、他のアラームはサブアラームにまとめられ、通知が一緒に送信されます。たとえば、クラウド サーバーに CPU 負荷アラームがある場合、多くの場合、クラウド サーバーが搭載するすべてのシステムの可用性アラームも伴います。
障害自己修復: アラームのリアルタイム検出、事前診断と分析、自動障害回復、および周囲のシステムを開放してプロセス全体の閉ループを実現します。
サービス ガバナンス
1. マイクロサービス
マイクロサービス アーキテクチャは、単一のアプリケーションを一連の小さなサービスに分割して調整および連携することを推奨するアーキテクチャ パターンです。相互に連携し、ユーザーに究極の価値を提供します。各サービスは独自の独立したプロセスで実行され、サービスは軽量の通信メカニズム (通常は HTTP ベースの Restful API) を使用して相互に通信します。各サービスは特定のビジネスを中心に構築されており、実稼働環境、実稼働環境に似た環境に独立してデプロイできます。 、など。
2. サービス ディスカバリ
サービス ディスカバリとは、登録センターを使用して分散システム内のすべてのサービスに関する情報を記録し、他のサービスがこれらの登録されたサービスをすぐに見つけられるようにすることを指します。サービス ディスカバリは、大規模な SOA およびマイクロサービス アーキテクチャをサポートするコア モジュールであり、可能な限り高可用性である必要があります。
3. トラフィックのピークの削減
宝くじやフラッシュセール システムのリクエスト監視曲線を観察すると、このタイプのシステムはアクティビティが開始されている時間帯にピークがあることがわかります。アクティビティが開いていないときはピークがあり、システムのリクエスト量とマシン負荷は一般に比較的安定しています。マシン リソースを節約するため、短期的なピーク リクエストをサポートできる最大のリソース容量を常に提供できるわけではありません。したがって、瞬間的なリクエストのピークを弱め、リクエストのピーク時にシステムのスループットを制御可能に保つには、何らかの技術的手段を使用する必要があります。ピーク クリッピングを使用すると、不具合を排除し、サーバー リソースの使用率をよりバランスよく完全なものにすることもできます。一般的なピークシェービング戦略には、キュー、周波数制限、階層フィルタリング、マルチレベル キャッシュなどが含まれます。
4. バージョンの互換性
バージョンをアップグレードするプロセスでは、新しいデータ構造がアップグレード後の古いデータを理解して解析できるかどうか、また新しく変更されたデータ構造が新しいデータ構造にあるかどうかを考慮する必要があります。プロトコルは古いデータの合意を理解し、適切かつ期待される決定を下すことができます。これには、サービス設計プロセス中にバージョンの互換性が必要です。
5. 過負荷保護
過負荷とは、現在の負荷がシステムの最大処理能力を超えていることを意味します。過負荷が発生すると、一部のサービスが利用できなくなります。適切に処理しないと、サービスが利用できなくなります。サービス障害が発生する可能性が非常に高く、雪崩が発生した場合でも完全に利用できなくなります。過負荷保護は、この異常事態に対して、サービスが完全に利用できなくなることを防ぐための措置です。
6. サービスヒューズ
サービスヒューズの機能は家庭用ヒューズと同様で、サービスが利用できなくなったり、応答がタイムアウトになったりした場合に、システム全体の雪崩を防ぐために、サービスを一時的に遮断します。停止しました。転送します。
7. サービスのダウングレード
サービスのダウングレードは、サーバーの負荷が急激に増加した場合であり、サーバーのリソースを解放し、確実なサービスを確保するために、現在のビジネス状況とトラフィックに基づいて一部のサービスとページが戦略的にダウングレードされます。コアタスクの通常の動作。多くの場合、低下ではさまざまなレベルが指定され、さまざまな例外レベルに直面したときにさまざまな処理が実行されます。さらに、パブリック アカウント Java Architect Technical Backend を検索して「Spring」と返信すると、サプライズ ギフト パッケージが届きます。
サービス方法に応じて、サービスを拒否したり、サービスを遅らせたり、場合によってはランダムなサービスを提供したりできます。
サービスの範囲に応じて、特定の機能が削除されたり、特定のモジュールが削除されたりする可能性があります。
つまり、サービスのダウングレードには、さまざまなビジネス ニーズに応じてさまざまなダウングレード戦略が必要です。主な目的は、サービスに損害は発生しますが、何もしないよりはマシであるということです。
8. メルトダウン VS ダウングレード
同じ点: システムのクラッシュを防ぐための可用性と信頼性から始まり、目標は同じです。ユーザー エクスペリエンスは似ており、最終的にはユーザーが特定の機能が一時的に利用できないという経験;
相違点: トリガーの理由が異なります。サービスの中断は通常、特定のサービス (ダウンストリーム サービス) の障害によって引き起こされますが、サービスの低下は一般に全体の負荷から考慮されます。
9. サービス制限フロー
電流制限は、システムの保護という目的を達成するために、システムの入出力トラフィックを制限するサービス低下の一種と考えられます。一般的にシステムのスループットを測定することができますが、システムの安定稼働を確保するためには、制限すべき閾値に達した場合にはトラフィックを制限し、目的を達成するために何らかの措置を講じる必要があります。交通量を制限すること。例: 処理の遅延、処理の拒否、または処理の一部の拒否など。
10. 障害マスキング
障害のあるマシンをクラスターから削除して、新しいリクエストが障害のあるマシンに配信されないようにします。
テスト方法
1. ブラック ボックス/ホワイト ボックス テスト
ブラック ボックス テストは、プログラムの内部構造や論理構造を考慮せず、主に機能が機能するかどうかをテストするために使用されます。システムの要求仕様を満たしています。一般に、入力値、入力値、および比較のための期待値が存在します。
ホワイト ボックス テストは、主に単体テストの段階で主にコードレベルのテストに使用され、プログラムの内部論理構造については、ステートメント カバレッジ、判定カバレッジ、条件カバレッジ、パス カバレッジなどのテスト方法が行われます。 、および条件の組み合わせのカバレッジ
2. 単体/統合/システム/受け入れテスト
ソフトウェア テストは、通常、単体テスト、統合テスト、システム テスト、および受け入れテストの 4 つの段階に分かれています。
単体テスト: 単体テストとは、モジュール、プロセス、メソッドなど、ソフトウェア内の検証可能な最小単位をチェックして検証することです。単体テストは粒度が最も小さく、通常は開発チームによってホワイトボックスアプローチを使用してテストされ、主に単体が「設計」に準拠しているかどうかがテストされます。
統合テスト: 統合テストはアセンブリ テストとも呼ばれ、通常は単体テストに基づいて、すべてのプログラム モジュールを順序立てて段階的にテストします。結合テストは単体テストとシステムテストの間の「橋渡し」の役割を果たし、一般的に開発チームはホワイトボックス＋ブラックボックスのアプローチでテストを行い、「設計」だけでなく「要件」も検証します。
システム テスト: システム テスト中、統合テストされたソフトウェアはコンピュータ システムの一部として使用され、システムの他の部分と組み合わせて、一連の厳密なテストが実行されます。実際の動作環境での効果的なテスト ソフトウェアの潜在的な問題を発見し、システムが正常に動作することを確認するためのテスト。システムテストは最も粒度が高く、一般にブラックボックスアプローチを使用して独立したテストチームによってテストされ、主にシステムが「要求仕様」を満たしているかどうかがテストされます。
受け入れテスト: 受け入れテストは、配信テストとも呼ばれ、システムが受け入れ基準を満たしているかどうかを判断するために、ユーザーのニーズとビジネス プロセスに対して実施される正式なテストです。顧客またはその他の権限のある機関は、システムを受け入れるかどうかを決定します。受け入れテストはシステム テストに似ていますが、主な違いはテスターが異なることです。受け入れテストはユーザーによって実行されます。
3. 回帰テスト
欠陥が見つかって修正されるか、ソフトウェアに新しい機能が追加された後、再テストします。発見された欠陥が修正され、修正によって新たな問題が発生していないかを確認するために使用されます。
4. スモークテスト
この用語はハードウェア業界から来ています。ハードウェアまたはハードウェア コンポーネントに変更または修復を行った後は、デバイスに直接電源を供給します。煙が出なければ、コンポーネントはテストに合格します。ソフトウェアでは、「スモーク テスト」という用語は、コードの変更を製品のソース ツリーに組み込む前に検証するプロセスを指します。
スモーク テストは、ソフトウェア開発プロセス中のソフトウェア バージョン パッケージの基本機能を迅速に検証する戦略です。これは、ソフトウェアの基本機能を確認および検証する手段であり、ソフトウェアの詳細なテストではありません。ソフトウェアのバージョンパッケージ。
例: ログイン システムのスモーク テストの場合、ログインのコア機能ポイントを検証するために、正しいユーザー名とパスワードをテストするだけで済みます。入力ボックス、特殊文字などについては、スモークテストでテストできます。その後に進みます。
5. パフォーマンス テスト
パフォーマンス テストは、自動テスト ツールを使用して、さまざまな正常、ピーク、および異常な負荷条件をシミュレートすることにより、システムのさまざまなパフォーマンス指標をテストすることです。負荷テストとストレス テストはどちらもパフォーマンス テストであり、この 2 つを組み合わせることができます。
負荷テストを通じて、さまざまなワークロード下でのシステムのパフォーマンスを決定します。目標は、負荷が徐々に増加したときのシステムのさまざまなパフォーマンス指標の変化をテストすることです。
ストレス テストは、システムが提供できる最大のサービス レベルを得るために、システムのボトルネックまたは許容できないパフォーマンス ポイントを特定するテストです。
6. ベンチマーク テスト
ベンチマーク テスト (Benchmark) は、マシンのハードウェアの最大実際の動作パフォーマンスとソフトウェアの最適化によるパフォーマンス向上効果を測定するために使用されるパフォーマンス テスト手法でもあります。特定のコード部分における CPU またはメモリ効率の問題を特定するためにも使用されます。多くの開発者は、ベンチマーク テストを使用してさまざまな同時実行モードをテストしたり、ベンチマーク テストを使用して、システムのスループットを確保するためにワーカー プールの数の構成を支援したりします。
7. A/B テスト
A/B テストとは、ランダムに割り当てられた 2 つ以上の同様の数値を持つサンプルを比較することです。グループが比較され、ターゲット指標に関して統計的に有意である場合、実験グループの関数が目的の結果につながる可能性があることを示すことができ、それによって仮説の検証や製品の決定に役立ちます。
8. コード カバレッジ テスト
コード カバレッジ (コード カバレッジ) はソフトウェア テストにおける測定値であり、テストされるプログラム内のソース コードの割合と範囲を表します。結果として得られる割合はコードと呼ばれます。カバレッジ。単体テストを行う場合、コード カバレッジはテストの品質を測定する指標としてよく使用されます。コード カバレッジは、テスト タスクの完了を評価するためにも使用されます。たとえば、コード カバレッジは 80% または 90% に達する必要があります。それ以来、テスターはケース カバレッジ コードの設計に多大な労力を費やしてきました。
リリース展開
1. DEV/PRO/FAT/UAT
DEV (開発環境): 開発者によるデバッグに使用される開発環境。バージョンが大幅に変わります。
FAT (機能受け入れテスト環境): ソフトウェア テスターがテストに使用する機能受け入れテスト環境。
UAT (ユーザー受け入れテスト環境): ユーザー受け入れテスト環境。運用環境での機能検証に使用され、プレリリース環境として使用できます。
PRO (実稼働環境): 実稼働環境、正式なオンライン環境。
2. グレースケール リリース
グレースケール リリースとは、バージョンのアップグレードのプロセスにおいて、最初に一部のユーザーに対してパーティション制御、ホワイトリスト制御などを通じて製品機能がアップグレードされ、残りのユーザーに対しては製品機能がアップグレードされることを意味します。製品機能をアップグレードしたユーザーが一定期間経過してもフィードバックがない場合、範囲は徐々に拡大され、最終的には新しいバージョンの機能がすべてのユーザーに公開されます。グレースケール リリースにより、システム全体の安定性が確保されます。初期グレースケール中に発見される可能性があります。その影響を確実にするために質問を変更してください。
3. ロールバック
とは、プログラムまたはデータ処理エラーが発生した場合に、プログラムまたはデータを最後の正しい状態 (または以前の安定したバージョン) に復元する動作を指します。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
