バックエンドアーキテクトテクノロジエンサイクロペディア (69 ポイント、収集価値あり)

職人が自分の仕事をうまくやりたいなら、まず自分の道具を研がなければなりませんし、学者が自分の正しさを宣言したいなら、まず自分の本を読まなければなりません。インターネット技術の分野における最重要課題として、バックグラウンド開発は常に開発者による追求の頂点でした。この記事では、誰もがバックグラウンド開発を理解できるよう、システム開発、アーキテクチャ設計、ネットワーク通信などを踏まえ、バックグラウンド開発に関わる専門用語から、網羅的にわかりやすく解説します。

システム開発

1. 高凝集性/低結合性

高い凝集性とは、ソフトウェアモジュールが関連性の高いコードで構成されており、1 つのタスクのみを担当することを意味します。これは、単一責任原則とよく呼ばれます。モジュールの凝集度は、モジュールの内部接続の緊密さを反映します。

モジュール間のリンクが近づくほど結合が強くなり、モジュールの独立性が低くなります。モジュール間の結合のレベルは、モジュール間のインターフェイスの複雑さ、呼び出し方法、渡される情報によって異なります。完全なシステムでは、モジュール間で可能な限り独立して存在します。一般に、プログラム構造内のモジュール間の凝集度が高くなるほど、モジュール間の結合度は低くなります。

2. オーバーデザイン

過剰設計とは、過度に未来志向の設計を行ったり、比較的単純なものを複雑にしたり、モジュール性、拡張性、デザインパターンなどを追求しすぎて、システムに不必要な複雑さを加えることです。

3. 時期尚早な最適化

時期尚早とは、開発プロセスの初期段階を意味するのではなく、要件の将来の変更がどのような方向に向かうかが明確でない場合を意味します。最適化によって新しい要件を適切に実装できなくなるだけでなく、最適化の期待に関する推測が依然として間違っている可能性があり、実際にはコードが複雑になる以外に何も得られません。

正しい方法は、まず要件を高品質で実現し、テストケースを作成し、次にプロファイルを実行してパフォーマンスのボトルネックを見つけてから最適化を行うことです。

4. リファクタリング

リファクタリングとは、プログラムコードを調整することでソフトウェアの品質や性能を向上させ、プログラムの設計様式や構造をより合理的にし、ソフトウェアの拡張性や保守性を向上させることです。

5. 割れ窓効果

割れ窓理論とも呼ばれる、割れ窓効果（Broken window Theory）は、犯罪学の理論です。この理論は、環境内の悪い現象が存在することを許可すると、人々が模倣することを誘発し、さらにはそれが激化するというものです。たとえば、壊れた窓が数枚ある建物の場合、それらの窓が修復されなければ、破壊行為によってさらに多くの窓が破損する可能性があります。最終的には建物に侵入することさえあり、人がいないのを見つけたらそこに住み着くか放火するかもしれません。

ソフトウェアエンジニアリングに適用する場合、システムコードやアーキテクチャ設計の隠れた危険性が表面化することを許してはなりません。そうしないと、時間の経過とともに隠れた危険性がますます深刻になってしまいます。逆に、システム自体の品質が高ければ、人々は思わず高品質のコードを書くようになります。

6. 相互不信の原則

これは、プログラムの上流と下流の間のリンク全体において、各ポイントが絶対的に信頼できるという保証はなく、マシンネットワーク、サービス自体、依存環境、入力、やリクエストなどがあるので、どこでも強化してください。

7. 永続性

永続化は、プログラムデータを一時的な状態と永続的な状態の間で遷移させるメカニズムです。平たく言えば、一時データ (永続的に保存できないメモリ内のデータなど) は、永続データ (長期間保存できるデータベースまたはローカルディスクへの保存など) に保存されます。

8. クリティカルセクション

クリティカルセクションは、複数のスレッドで使用できる共通リソースまたは共有データを表すために使用されますが、毎回、それを使用できるのは 1 つのスレッドだけです。クリティカルセクションのリソースが占有されると、他のスレッドがこのリソースを使用しようとします。待って。

9. ブロッキング/ノンブロッキング

ブロッキングとノンブロッキングは通常、複数のスレッド間の相互作用を表します。たとえば、スレッドがクリティカルセクションのリソースを占有している場合、このリソースを必要とする他のすべてのスレッドはこのクリティカルセクションで待機する必要があり、待機するとスレッドがハングします。この状況はブロッキングとして知られています。この時点で、リソースを占有しているスレッドがリソースを解放することに消極的であれば、このクリティカルセクションでブロックされている他のすべてのスレッドは動作できません。ノンブロッキングでは、複数のスレッドがクリティカルセクションに同時に入ることができます。

10. 同期/非同期

通常、同期と非同期は関数/メソッド呼び出しの側面を指します。

同期とは、関数呼び出しが発行されたときに、結果が取得されるまで呼び出しが返されないことを意味します。非同期呼び出しは即座に戻りますが、非同期呼び出しの即時戻りはタスクが完了したことを意味するものではありません。バックグラウンドでスレッドを開始してタスクを続行し、タスク終了後にコールバックまたはその他の手段で呼び出し元に通知します。完成しました。

11. 同時実行性/並列性

並列とは、複数の命令が複数のプロセッサ上で同時に実行されることを意味します。したがって、ミクロの観点から見てもマクロの観点から見ても、この 2 つは同時に実行されます。

同時実行性とは、同時に実行できる命令は 1 つだけですが、複数のプロセス命令がローテーションで迅速に実行されるため、マクロレベルでは複数のプロセスが同時に実行されますが、ミクロレベルでは同時に実行されないことを意味します。 , ただ時間を複数のセグメントに分割し、複数のプロセスを素早く交互に実行できるようにします。

建築デザイン

1. 高い同時実行性

分散システムの出現により、高同時実行性 (High Concurrency) とは、通常、システムが多数のリクエストを同時に並行して処理できるようにする設計を指します。一般に、高い同時実行性とは、多くのユーザーが同じ時点で同じ API インターフェイスまたは URL アドレスに同時にアクセスすることを意味します。これは、多数のアクティブユーザーが存在し、ユーザーが集中しているビジネスシナリオでよく発生します。

2. 高可用性

高可用性 HA (高可用性) は、分散システムアーキテクチャの設計で考慮する必要がある要素の 1 つであり、通常、システムがダウンタイムを削減し、サービスの高可用性を維持するように特別に設計されていることを意味します。

3. 読み取りと書き込みの分離

データベース製品の安定性を確保するために、多くのデータベースにはデュアルマシンホットバックアップ機能が搭載されています。つまり、第 1 のデータベースサーバーは外部の追加、削除、および変更サービスを提供する運用サーバーであり、第 2 のデータベースサーバーは主に読み取り操作を実行します。

4. コールドスタンバイ/ホットスタンバイ

コールドスタンバイ: 2 台のサーバー。1 台は実行中で、もう 1 台はバックアップとして実行されていません。このようにして、実行中のサーバーがダウンしても、バックアップサーバーが実行されます。コールドバックアップソリューションは実装が比較的簡単ですが、コールドバックアップの欠点は、ホストに障害が発生した場合にバックアップマシンが自動的に引き継ぎを行わず、サービスをアクティブに切り替える必要があることです。

ホットスタンバイ：いわゆるアクティブ/スタンバイ方式であり、データベースデータを含むサーバデータを複数のサーバに同時に書き込みます。アクティブサーバーに障害が発生すると、ソフトウェア診断 (通常はハートビート診断) によってスタンバイマシンがアクティブ化され、アプリケーションが短時間で通常の使用を完全に再開できるようになります。サーバーがダウンすると、自動的に別のスタンバイマシンに切り替わって使用されます。

5. さまざまな場所にもっと住む

「マルチアクティブ」とは、一般に各都市に独立したデータセンターを設置することを指します。「アクティブ」とはコールドバックアップに相当します。コールドバックアップは全量のデータをバックアップするものであり、平時のビジネスニーズには対応しておりません。メインコンピュータ室に障害が発生した場合にのみ使用されますが、バックアップコンピュータ室に切り替えてよりアクティブになるということは、これらのコンピュータ室もビジネスサポートを提供するために日常業務でトラフィックを必要とすることを意味します。

6. 負荷分散

負荷分散は、トラフィックを複数のサーバーに分散する負荷分散サービスです。アプリケーションの外部サービス機能を複数のインスタンス間で自動的に分散し、単一障害点を排除することでアプリケーションシステムの可用性を向上させ、より高いレベルのアプリケーションのフォールトトレランスを実現できるため、分散に必要な負荷をシームレスに提供できます。アプリケーショントラフィックバランスのとれた容量により、効率的で安定した安全なサービスを提供します。

7. 静的と動的の分離

動的分離と静的分離とは、サービス全体のアクセスパフォーマンスと保守性を向上させるために、Webサーバーアーキテクチャにおいて静的ページと動的ページ、または静的コンテンツインターフェイスと動的コンテンツインターフェイスを分離するアーキテクチャ設計方法を指します。

8. クラスター

1 台のサーバーの同時実行能力には常に限界があります。1 台のサーバーの処理能力がパフォーマンスのボトルネックに達すると、複数のサーバーを組み合わせてサービスを提供します。この組み合わせをクラスターと呼び、クラスター内の各サーバーをこの A と呼びます。クラスターの「ノード」の場合、各ノードは同じサービスを提供できるため、システム全体の同時処理能力が 2 倍になります。

9. 分散型

分散システムとは、完全なシステムをビジネス機能に応じて多数の独立したサブシステムに分割することです。各サブシステムは「サービス」と呼ばれます。分散システムはリクエストを分類して異なるサブシステムに分散し、異なるサービスが異なるリクエストを処理できるようにします。分散システムでは、サブシステムが独立して動作し、それらをネットワーク通信で接続することでデータの相互通信や複合的なサービスを実現します。

10. CAP理論

CAP理論とは、分散システムにおいては、Consistency（一貫性）、Availability（可用性）、Partition Tolerance（分割耐性）を同時に確立することはできないという理論です。

一貫性: 分散システム内のすべてのデータバックアップが同じ時点で同じであるか、同じ状態であることが必要です。
可用性: システムクラスタの一部のノードがダウンした後でも、システムはユーザーの要求に正しく応答できます。
パーティション耐性: システムは、ノード間のネットワーク通信の障害を許容できます。

簡単に言うと、分散システムでは、最大でも上記 2 つの属性がサポートされます。しかし、当然のことながら、分散されているため、必ずパーティション分割が行われ、パーティション化の際にパーティションエラーを 100% 回避することはできません。したがって、一貫性と使いやすさのどちらかを選択するしかありません。

分散システムでは一貫性よりも可用性を追求することが多いのですが、ではどうすれば高可用性を実現できるかというもう一つの理論があり、CAP理論をさらに拡張したBASE理論です。

11. BASE理論

BASE 理論では次のように述べられています。

基本的に利用可能
ソフトな状態
最終的に一貫性のある (最終的な一貫性)

BASE 理論は、CAP における一貫性と可用性の間のトレードオフの結果です。この理論の核となる考え方は、「強力な一貫性を実現することはできませんが、各アプリケーションは、それぞれのビジネス特性に応じて適切な方法を使用して、システムは最終的な整合性を達成します。

12. 横展開・縦展開

水平拡張スケールアウトでは、サーバーまたはプログラムインスタンスを追加して負荷を分散し、ストレージ容量とコンピューティング容量を増加します。

垂直方向の拡張スケールアップにより、単一マシンの処理能力が向上します。

垂直方向に拡張するには 2 つの方法があります。

(1) スタンドアロンハードウェアのパフォーマンスを強化します。たとえば、32 コアなどの CPU コア数を増やし、10 ギガビットなどのより優れたネットワークカードをアップグレードし、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 に、データベースのデッドロックなどの一部のサーバーはダウンタイムとも呼ばれ、一部のサーバーの一部のサービスがいわばハングアップします。

2.コアダンプ

プログラムが失敗して異常中断された場合、OS はプログラムの現在のステータスを coredunmp ファイルとして保存します。通常、コアダンプファイルには、プログラム実行時のメモリ、レジスタステータス、スタックポインタ、メモリ管理情報などが含まれます。

3. キャッシュの侵入/破壊/なだれ

キャッシュペネトレーション: キャッシュペネトレーションとは、存在してはいけないデータをクエリすることを指します。キャッシュはミスであるため、データベースからクエリする必要があります。データが見つからない場合、データはキャッシュに書き込まれません。これにより、次のような問題が発生します。存在しないデータを毎回リクエストする必要があるため、データベースにアクセスしてクエリを実行する必要があり、データベースに負担がかかります。

キャッシュブレークダウン: キャッシュブレークダウンとは、ホットスポットキーが特定の時点で期限切れになり、この時点でこのキーに対する同時リクエストが多数あるため、大量のリクエストがデータベースにヒットすることを指します。

キャッシュなだれ: キャッシュなだれとは、有効期限までにキャッシュ内に大量のデータが存在し、クエリデータの量が膨大になり、データベースに過剰な圧力がかかったり、マシンがダウンしたりすることを指します。

キャッシュブレークダウンとの違いは、キャッシュブレークダウンはホットキーの失敗であるのに対し、キャッシュアバランチは同時に多数のキーが失敗することであることです。

4. 500/501/502/503/504/505

500 内部サーバーエラー: 内部サービスエラー。通常、サーバーは予期しない状況に遭遇し、リクエストを完了できません。考えられる原因：

1. プログラムエラー。例: ASP または PHP の構文エラー。
2. 同時実行性が高いため、システムリソースの制限により、あまりにも多くのファイルを開くことができません。

501 未実装: サーバーは要求された HTTP リクエストを理解していないか、サポートしていません。

502 Bad Gateway: WEB サーバーに障害があります。プログラムのプロセスが不十分である可能性があります。要求された php-fpm は実行されましたが、何らかの理由で実行されず、最終的に php-fpm プロセスが終了します。。考えられる原因：

1. Nginx サーバー、php-cgi プロセスの数が十分ではありません。
2. PHP の実行時間が長すぎます。
3. php-cgi プロセスが停止します。

503 サービスを利用できません: サーバーは現在利用できません。システム保守サーバーは一時的にクライアントの要求を処理できませんが、これは一時的な状態にすぎません。サーバープロバイダーに問い合わせることができます。

504 ゲートウェイタイムアウト: サーバー 504 エラーはタイムアウトを示します。これは、クライアントによって送信されたリクエストがゲートウェイに到達せず、リクエストが実行可能ファイル php-fpm に到達していないことを意味します。これは通常、nginx.conf の設定に関連します。。

505 HTTP バージョンがサポートされていません: サーバーは、リクエストで使用されている HTTP プロトコルのバージョンをサポートしていません。(HTTP バージョンはサポートされていません)

プログラミング言語エラーである可能性がある 500 エラーを除いて、残りのエラーはおそらくサーバーまたはサーバー構成の問題として理解できます。

5. メモリオーバーフロー/メモリリーク

メモリオーバーフロー: メモリオーバーフロー (メモリ不足) とは、プログラムがメモリを申請したときに、申請者が使用できる十分なメモリがないことを意味します。つまり、int 型データを保存するための記憶領域が与えられているにもかかわらず、 long 型データの場合、結果としてメモリが不足し、この時点でエラー OOM が報告されます。これは、いわゆるメモリオーバーフローです。

メモリリーク: メモリリーク (メモリリーク) とは、プログラム内で動的に割り当てられたヒープメモリが解放されない、または何らかの理由で解放できず、システムメモリが無駄に消費され、システムの速度が低下するなどの重大な結果を引き起こすことを指します。プログラムの実行速度が低下したり、システムがクラッシュしたりする場合もあります。

6. 漏れに対処する

ハンドルリークとは、プロセスがシステムファイルの呼び出し後に開いているファイルハンドルの解放に失敗することです。ハンドルリーク後の一般的な現象は、マシンの速度が低下し、CPU が急上昇し、ハンドルリークが発生した CGI またはサーバーの CPU 使用率が増加することです。

7. デッドロック

デッドロックとは、実行処理中に複数のスレッドがリソースの奪い合いや相互の通信により発生するブロック現象のことで、外力がなければすべてブロックされた状態で抑制され、先に進むことができなくなると言われています。システムがデッドロック状態にあるか、システムにデッドロックが発生しています。

8. ソフト割り込み/ハード割り込み

ハード割り込み: 通常、割り込みと呼ばれるものは、ハード割り込み (hardirq) です。

これは主に、システム周辺機器のステータスの変化をオペレーティングシステムに通知するために使用されます。

ソフト割り込み: 1. 通常、ハード割り込みサービスプログラムによるカーネルの割り込みです; 2. リアルタイムシステムの要件を満たすために、割り込み処理はできるだけ高速である必要があります。

Linux のこの機能を実現するために、割り込みが発生した場合、短時間で完了する作業はハード割り込みで処理し、長時間のイベントを処理する作業は割り込み後に完了する、つまりソフト割り込みが行われます。完了するための割り込み (softirq)。

9. グリッチ

一瞬のうちに、サーバーのパフォーマンス指標 (トラフィック、ディスク IO、CPU 使用率など) が、この瞬間の前後の期間よりも大幅に大きくなります。不具合の出現は、このサーバーのリソース使用率が不均一で不十分であることを意味し、他のより深刻な問題を誘発しやすいことを意味します。

10.リプレイアタック

攻撃者は、システムを欺く目的を達成するために、宛先ホストが受信したパケットを送信します。これは主に ID 認証プロセスで使用され、認証の正確性を破壊します。これは、開始者またはデータを傍受して再送信する敵対者によって、有効なデータ送信を悪意を持って繰り返し、または不正に繰り返す攻撃の一種です。攻撃者はネットワーク監視またはその他の手段を使用して認証資格情報を盗み、認証サーバーに再送信します。

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. サービスのダウングレード

サービスのダウングレードとは、サーバーへの負荷が急激に増加した場合に、サーバーリソースを解放し、コアタスクの正常な動作を確保するために、現在のビジネス状況とトラフィックに応じて一部のサービスとページを戦略的にダウングレードすることを意味します。多くの場合、低下ではさまざまなレベルが指定され、さまざまな例外レベルに応じてさまざまな処理が実行されます。さらに、公式アカウント Internet Architect を検索して「9」と返信すると、サプライズのギフトパッケージがプレゼントされます。

サービスの方法によっては、サービスが拒否されたり、サービスが遅れたり、サービスがランダムになる場合があります。

サービス範囲に応じて、特定の機能を削除したり、一部のモジュールを削除したりすることができます。

つまり、サービスの低下には、さまざまなビジネスニーズに応じてさまざまな低下戦略を採用する必要があります。主な目的は、サービスに損害は発生しますが、何もしないよりはマシであるということです。

8. 融合 VS 劣化

同じ点: システムのクラッシュを防ぐための使いやすさと信頼性から始まる目標は同じであり、ユーザーエクスペリエンスも同様で、最終的にユーザーが経験することは、一部の機能が一時的に使用できなくなることです。

相違点: トリガーの理由が異なります。サービスの融合は通常、サービス (ダウンストリームサービス) の障害によって引き起こされますが、サービスの低下は一般に全体の負荷から考慮されます。

9. サービス電流制限

電流制限は、システムの保護という目的を達成するために、システムの入出力トラフィックを制限するサービス低下の一種と見なすことができます。一般に、システムのスループットを測定できますが、システムの安定稼働を確保するには、制限する必要があるしきい値に達した場合、フローを制限し、目的を達成するために何らかの措置を講じる必要があります。流れを制限すること。例: 処理の遅延、処理の拒否、または処理の一部の拒否など。

10. 障害マスキング

障害のあるマシンはクラスターから削除され、新しいリクエストが障害のあるマシンに配信されないようにします。

試験方法

1. ブラックボックス/ホワイトボックステスト

ブラックボックステストはプログラムの内部構造や論理構造を考慮せず、主にシステムの機能が要求仕様を満たしているかどうかをテストするために使用されます。一般に、入力値、入力値、および比較のための期待値が存在します。

ホワイトボックステストは主に単体テストの段階で、主にコードレベルのテストに使用され、プログラムの内部論理構造については、ステートメントカバレッジ、ディシジョンカバレッジ、条件カバレッジ、パスカバレッジ、条件組み合わせカバレッジなどのテスト方法が行われます。

2. 単体/統合/システム/受け入れテスト

ソフトウェアテストは通常、単体テスト、統合テスト、システムテスト、受け入れテストの4段階に分かれます。

単体テスト: 単体テストは、モジュール、プロセス、メソッドなど、ソフトウェア内の検証可能な最小単位をチェックおよび検証することです。単体テストは最も粒度が小さく、主に単体が「設計」に準拠しているかどうかをテストするために、開発チームによってホワイトボックス手法を使用してテストされます。

統合テスト: 統合テストはアセンブリテストとも呼ばれ、通常は単体テストに基づいて、すべてのプログラムモジュールが順序正しく段階的にテストされます。結合テストは単体テストとシステムテストの間の「橋渡し」の役割を果たし、一般的に開発チームはホワイトボックスとブラックボックスの手法を用いてテストを行い、「設計」だけでなく「要件」も検証します。

システムテスト: システムテストでは、統合テストに合格したソフトウェアがコンピュータシステムの一部としてシステムの他の部分と結合され、実際の動作環境で一連の厳格かつ効果的なテストが実行され、ソフトウェア内の潜在的な問題を検出し、システムの整合性を確保します。通常の動作。システムテストは最も粒度が高く、主にシステムが「要求仕様」を満たしているかどうかをテストするために、ブラックボックス手法を使用して独立したテストチームによってテストされます。

受け入れテスト: 納品テストとも呼ばれる受け入れテストは、システムが受け入れ基準を満たしているかどうかを判断するために、ユーザーのニーズとビジネスプロセスを目的とした正式なテストであり、ユーザー、顧客、またはその他の認可された組織がシステムを受け入れるかどうかを決定します。受け入れテストはシステムテストに似ていますが、主な違いはテスターが異なるのに対し、受け入れテストはユーザーによって実行されることです。

3. 回帰テスト

欠陥が見つかって修正されたり、ソフトウェアに新しい機能が追加されたりした場合には、再テストが実行されます。見つかった欠陥が修正され、修正によって新たな問題が発生していないかを確認するために使用されます。

4. 発煙試験

この用語はハードウェア業界に由来します。1 つのハードウェアまたはハードウェアコンポーネントに変更または修復を行った後、デバイスの電源を直接入れます。煙が出なければ、コンポーネントはテストに合格しています。ソフトウェアでは、「スモークテスト」という用語は、コードの変更を製品のソースツリーに埋め込む前に検証するプロセスを指します。

スモークテストは、ソフトウェア開発プロセスにおけるソフトウェアバージョンパッケージの迅速な基本機能検証戦略であり、ソフトウェアバージョンパッケージの詳細なテストではなく、ソフトウェアの基本機能を確認および検証する手段です。

例: ログインシステムのスモークテストの場合、ログインのコア機能ポイントを検証するために、正しいユーザー名とパスワードの入力をテストするだけで済みます。入力ボックスや特殊文字などについては、発煙試験後に行われます。

5. 性能テスト

パフォーマンステストは、自動テストツールを使用して、さまざまな正常、ピーク、および異常な負荷状態をシミュレートすることにより、システムのさまざまなパフォーマンス指標をテストします。負荷テストとストレステストはどちらもパフォーマンステストであり、組み合わせることができます。

負荷テストを通じて、さまざまなワークロード下でのシステムのパフォーマンスを確認します。目標は、負荷が徐々に増加したときのシステムのさまざまなパフォーマンス指標の変化をテストすることです。

ストレステストは、システムのボトルネックまたは許容できないパフォーマンスポイントを特定することにより、システムが提供できる最大のサービスレベルを取得するテストです。

6. ベンチマーク

ベンチマーク (ベンチマーク) は、マシンのハードウェアの最大実際の動作パフォーマンスやソフトウェア最適化によるパフォーマンス向上効果を測定するために使用されるパフォーマンステスト方法でもあり、CPU やメモリ効率の問題を特定するためにも使用できます。多くの開発者は、ベンチマークをさまざまな同時実行モードをテストするために使用したり、ベンチマークを使用してワーカープールの数を構成して最大のシステムスループットを確保したりすることができます。

7. A/B テスト

A/B テストは、同じ量のランダムに割り当てられた 2 つ以上のサンプルを比較に使用するもので、実験グループと比較グループの実験結果を比較すると、対象の指標に統計的有意性があり、実験グループについて説明します。機能によって望ましい結果が得られるため、仮説を検証したり、製品を決定したりするのに役立ちます。

8. コードカバレッジテスト

コードカバレッジ (コードカバレッジ) は、ソフトウェアテストにおける測定値であり、テスト対象のプログラム内のソースコードの割合と程度を表し、結果として得られる割合をコードカバレッジと呼びます。単体テストを行う場合、コードカバレッジレートは、テストの品質を測定する指標としてよく使用されます。コードカバレッジレートは、テストタスクの完了を評価するためにも使用されます。たとえば、コードカバレッジレートは 80 に達する必要があります。 %または90%。それ以来、テスターはケースカバレッジコードの設計に熱心に取り組んできました。

リリース展開

1.開発/プロ/ファット/UAT

DEV（開発環境）：開発者がデバッグして使用するための環境であり、バージョンが大きく変わります。

FAT (機能受け入れテスト環境): ソフトウェアテスターがテストするための機能受け入れテスト環境。

UAT（ユーザー受け入れテスト環境）：本番環境での機能検証に使用されるユーザー受け入れテスト環境をプレリリース環境として利用できます。

PRO (本番環境): 本番環境、正式なオンライン環境。

2. グレースケールのリリース

グレーリリースとは、バージョンアップグレードプロセス中に、一部のユーザーが最初にパーティションコントロールやホワイトリストコントロールなどを通じて製品機能をアップグレードされ、残りのユーザーは変更されないことを意味します。段階的に範囲を拡大し、最終的には新バージョンの機能をすべてのユーザーに公開します。グレースケールのリリースにより、システム全体の安定性が保証されます。最初のグレースケールで問題を見つけて修正し、その影響を確実にすることができます。

3. ロールバック

プログラムやデータが誤って処理された場合に、プログラムやデータを最後の正しい状態（または最後の安定したバージョン）に復元する動作を指します。