基礎
私も以前にいくつかのピットを踏んだことがあります。私が参加した起業家プロジェクトは、初期段階でサービス指向アーキテクチャを採用していましたが、当時の限られた人員と不十分なチーム技術の蓄積のために、それを制御することは不可能であることがわかりました実際のプロジェクト開発プロセスでは複雑なアーキテクチャです。、問題の特定の難しさやシステムの全体的なパフォーマンスなど、多くの問題もありました。システムがダウンしている場合でも、根本原因を追跡することは困難です。最後に、サービスを統合して、単純なモノリシックアーキテクチャに戻す必要があります。
したがって、一般的なシステムの進化は、次のアイデアに従う必要があることをお勧めします。
最も単純なシステム設計がビジネスニーズと現在のフローステータスを満たし、最も馴染みのあるテクノロジーシステムが選択されます。トラフィックの増加とビジネスの変化に伴い、シングルポイントの問題、水平方向の拡張の問題、パフォーマンスが需要を満たすことができないコンポーネントなど、アーキテクチャの問題のあるポイントを修正します。このプロセスでは、コミュニティで成熟し、チームに馴染みのあるコンポーネントを選択して、問題の解決に役立てます。コミュニティに適切な解決策がない場合は、独自のホイールを作成します。アーキテクチャのマイナーな修理や補足がニーズを満たせない場合は、既存の問題を解決するために、リファクタリングや書き換えなどの主要な調整を検討してください。
淘宝網を例にとると、当時の0から1までのビジネスは、購入を通じて迅速にシステムを構築することでした。その後、トラフィックの増加に伴い、Taobaoは、MyISAMからInnoDBへのデータベースストレージエンジンの移行、データベースサブデータベースサブテーブル、キャッシュの増加、ミドルウェア研究の開始など、同時実行性の高い処理機能を改善するための一連の技術的変革を行いました。および開発など。これらが満たされない場合は、アーキテクチャ全体の大規模な再構築を検討してください。たとえば、有名な「カラフルストーン」プロジェクトにより、淘宝網のアーキテクチャは単一のアーキテクチャからサービス指向アーキテクチャに進化しました。淘宝網が現在1億QPSを超える技術アーキテクチャを進化させたのは、徐々に技術が進化したことによるものです。
システムのプロセッシングコアの数を増やす
データベース
この講義から、正式に進化の章に入ります。パートから始めて、これらの目標を達成するために使用されるいくつかの方法を理解するために、これらの方法を1つずつ紹介します。これらの方法は、高さの設計で発生する問題を具体的に解決します。 -並行性システム。たとえば、第15回の講義では、ブルームフィルターについて説明します。このコンポーネントは、キャッシュの浸透が多い場合に、キャッシュのヒット率を可能な限り改善する方法の問題を解決するためのものです。
もちろん、理論を説明して計画を説明するだけではつまらないので、コース全体を通して仮想システムをメインラインとして、システムが特定の段階に達したときにどのような問題が発生し、どのような用途になるかを説明します。対応プロセスに関係する技術的なポイントは何ですか？このようなナレーションを通じて、さまざまな問題に遭遇したときに、さまざまな問題を解決する方法を理解できるように、ケースの問題を引き出すように努めています。もちろん、このプロセスでは、もっと考えて、知識を学ぶことができれば幸いです。実際のプロジェクトで使用してください。
データベースを水平に分割する方法
キャッシュ
キャッシュはデータを格納するコンポーネントであり、その機能はデータの要求をより速く返すことです。
キャッシュをメモリに保存することが多いため、メモリとキャッシュを同一視する人もいます。これは完全に素人の意見です。業界関係者として、シナリオによっては、コールドデータのキャッシュとしてSSDを使用する場合があることを知っておく必要があります。たとえば、360オープンソースのPikaはSSDを使用してデータを保存し、Redisの容量のボトルネックを解決します。
実際、速度の差が大きい2種類のハードウェア間のデータ転送速度の差を調整するために使用される構造は、キャッシュと呼ばれます。したがって、これに関しては、一般的なハードウェアコンポーネントの遅延がどのように見えるかを知る必要があります。これにより、計画を立てるときに遅延をより直感的に把握できます。
ユーザーのリクエストをCDNノードに到達させる方法
メッセージキュー
コースの冒頭で、同時実行性の高いシステム設計の3つの目標であるパフォーマンス、可用性、スケーラビリティについて理解しました。システムパフォーマンスの向上という観点から、システムのクエリパフォーマンスに重点を置いてきました。また、データベースの分散変換、さまざまなキャッシュの原則と使用スキルについて説明するために多くのスペースを費やしました。その理由は、特にシステムの初期段階では、発生するシナリオのほとんどが書き込みよりも読み取りが多いためです。
たとえば、コミュニティシステムの初期段階では、コンテンツを作成するシードユーザーはごく少数である必要があり、ほとんどのユーザーは他のユーザーの発言を「監視」しています。現時点では、全体のトラフィックは比較的少なく、書き込みトラフィックは全体のトラフィックの1％しか占めていない可能性があります。全体のQPSが1秒あたり10,000回に達しても、書き込み要求は1秒あたり100回にしか達しません。パフォーマンスの最適化、そのコストパフォーマンスは確かにそれほど高くありません。ただし、ビジネスの発展に伴い、同時書き込み要求が多いシナリオが発生する場合があります。
典型的なシーン。ショッピングモールが5日目の00:00に開始し、上位200に制限されるスパイクキャンペーンを計画しているとします。スパイクが開始されようとしているとき、背景には、ユーザーがAPPまたはブラウザを必死に更新していることが示されます。彼らができるだけ早く製品を見ることができること。
現時点では、まだ高い読み取り要求に直面していますが、どのような対策がありますか？
ユーザーはクエリのホットデータに属する少量の製品データをクエリしているため、キャッシュ戦略を使用して、上位レベルのキャッシュでリクエストを可能な限りブロックできます。モール内の写真やビデオデータとして、CDNノードキャッシュにヒットし、Webサーバーのクエリ量と帯域幅の負担を軽減できるように、静的にするように最善を尽くしてください。NginxなどのWebサーバーは、分散キャッシュノードに直接アクセスできるため、Tomcatなどのビジネスサーバーにリクエストが到達するのを防ぐことができます。
もちろん、特定のユーザー、特定のIP、または特定のデバイスからの繰り返しの要求を短期間で破棄するなど、現在の制限戦略を追加することもできます。
これらのいくつかの方法を通じて、データベースから可能な限りリクエストをブロックできることがわかります。
読み取り要求をわずかに緩和した後、00：00分のスパイクアクティビティが時間どおりに開始され、ユーザーは即座にeコマースシステムに注文を生成して在庫を差し引くように要求しました。ユーザーのこれらの書き込み操作は、データベースに直接送信されました。キャッシュされています。1秒以内に同時に10,000のデータベース接続に到達し、システムのデータベースは崩壊の危機に瀕していました。このような高い同時実行性に対応できる書き込み要求ソリューションを見つけることは非常に緊急です。このとき、あなたはメッセージキューについて考えます
カフカでは、消費者の消費の進捗状況はバージョンによって異なります。
分散サービス
前の章の内容を通じて、データベース、キャッシュ、およびメッセージキューの観点から、パフォーマンス、可用性、およびスケーラビリティの観点から垂直eコマースシステムを最適化しました。
現在、プロジェクトの展開方法は統合アーキテクチャを採用しています。つまり、eコマースシステムの注文モジュール、ユーザーモジュール、支払いモジュール、ロジスティクスモジュールなどのすべての機能モジュールがパッケージ化されています。大規模なWebプロジェクトで、アプリケーションサーバーにデプロイされます。
この展開方法には問題があるかもしれないと漠然と思っていたので、Googleで検索したところ、システムが特定の段階に発展したときに、マイクロサービスに分割する必要があることがわかりました。また、Taobaoの「ColorfulStone」プロジェクトもご覧いただけます。全体的なアーキテクチャは大きな影響を及ぼします。これらすべてがあなたを魅了します。
しかし、あなたの心に残っている質問があります。統合アーキテクチャをマイクロサービスアーキテクチャに分割するようになったきっかけは何ですか。システムの全体的なQPSが10,000に達することを意味しますか、それとも20,000に達すると、マイクロサービスに分割する必要がありますか？
サイドカーにトラフィックを転送する方法
維持する
プロジェクトのライフサイクルでは、運用と保守が大きな割合を占めており、重要性の点では、プロジェクトの研究開発とほぼ同じです。システムの運用・保守の過程で、問題をタイムリーに発見・解決するのが各チームの仕事です。したがって、垂直eコマースシステムの開始時に、運用および保守チームは、マシンのCPU、メモリ、ディスク、ネットワークなどの基本的な監視を完了し、問題をタイムリーに見つけて対処することを望んでいる必要があります。すべてが順調に進んでいると思っていましたが、システムの運用中にユーザーから頻繁に苦情が来るとは思っていませんでした。理由は次のとおりです。
使用するデータベースのマスタースレーブ遅延が長くなり、ビジネス機能に問題が発生しています。
インターフェイスの応答時間が長くなり、ユーザーフィードバック製品ページに空白のページが表示されます。システムで多数のエラーが発生し、ユーザーの通常の使用に影響を与えています。
あなたはこれらの問題を時間内に発見して対処すべきでした。しかし、現実には、ユーザーからのフィードバックの後にのみ、問題を受動的に修正することができます。このとき、チームは、ビジネスシステムの問題をすばやく発見して特定するには、完全なサーバー側の監視システムを構築する必要があることに気付きました。ことわざにあるように、「何万もの道路があり、最初の道路は監視されるべきであり、監視は実施されておらず、2人の指導者は引き裂かれます。」ただし、構築の過程で、チームは再び問題に直面しました。
まず第一に、監視された指標を選択する方法は？
これらの指標を収集するためにどのような方法とアプローチを使用できますか？
指標を収集した後、どのように処理して表示するのですか？
これらの問題は、次々とシステムの安定性と可用性に関係しています。このレッスンでは、これらの問題を解決し、サーバー側の監視システムを構築します。
固定ウィンドウとスライディングウィンドウアルゴリズム
実際の戦闘
前のコースでは、データベース、キャッシュ、メッセージキュー、および分散サービスの観点から、高い同時実行性に直面してシステムの高パフォーマンス、高可用性、および高スケーラビリティを確保する方法を理解しました。コースには理論的な知識を理解するのに役立つ例がたくさんありますが、知識をまとめるのに役立つ完全な例はありません。
したがって、前述の知識を実装するために、実際の戦闘記事では、Weiboを背景として使用し、2つの完全なケースを使用して、高い同時実行性と大量のトラフィックの影響に対処するための実用的な観点から説明します。より具体的なものを提供します。の知覚知識は、同様のシステムを実装するときにいくつかのアイデアを提供します。今日お話ししたい最初のケースは、高い同時実行性と大容量のストレージをサポートするカウントシステムを設計する方法です。
高い同時実行性をサポートするカウントシステムを設計する方法
内容が多いため、1つずつ紹介することはしません。このメモが必要な友達[下の写真を見て、小さなアシスタントを追加してください]
