最近、スパイクシステム設計ダイジェストを観察し、我々は多くのデザインとマーケティング関連システムは前に他のシステムアーキテクチャ設計に適用されますまた、契約の多くを持っていたことがわかった。とてもシンプルな記録を行います。
「どのようなシステムがキーポイントをスパイクするために設計されている」から6月に始まり、毎年のマーケティングの11月には、インターネットでも、主要なビジネスプラットフォームコモディティ関連の交通システムのユーザー最も活発な期間である2つの暑い季節、あり;およびトラフィックスパイクがありますピーク代表、非常に多くの企業がビジネスのこの部分に着手する単一のシステムを分割します。
だから、どのように私たちはより良いスパイクシステムを理解していますか？私はプログラマーとして、あなたが最初に全体として考えるのは、高次元から開始する必要があると思います。私の意見では、実際にはスパイクは、主に二つの問題を解決するためには、同時読み取り、同時書き込み1です。同時読み取りの最適化の中核概念は、サーバーにデータを「読み」、またはそれらは以下のデータを読み聞かせするユーザーを最小限にすることで、同じ原則を同時書き込み、それは特別な操作を行うために、データベース・レベルでライブラリを分離するために私たちを必要とし処理。加えて、我々は起きてから最悪の事態を防ぐために、予想外のフォールバック計画を設計したスパイクシステムに対する何らかの保護を行う必要があります。
ビューの建築家の視点から、構築するために、我々はいくつかの原則に従わなければならないサーバに大流量の同時読み取りと書き込み、高性能、高可用性システム、ブラウザからのルート全体のユーザーの要求を維持する、つまり、 、できるだけ少しなど、ユーザーによって要求され、そのデータを確保するために可能な依存など少しとして、要求の数、できる限り短くパスを最小限に抑えるために、単一のポイントを持っていません。これらは、今後の記事でキーポイントを説明するに焦点を当てます。
実際には、全体スパイクアーキテクチャは、「安定した、正確な、高速で、」いくつかのキーワードのように要約することができます。
いわゆる「安定性」は本当にトラフィックが安定していることが期待されている高可用性を、満たすために、システム・アーキテクチャで、トラフィックが予想以上でもボールが落下することはできません、あなたは必要不可欠である活動の円滑な完了を確認する必要があります。
その後、10 iphoneスパイク「準」で、それだけで10を扱います、より多くの在庫がないいったん小さな一は仕事、そのプラットフォームが損失を負担するはありませんよりも、その「正確な」データの一貫性を確保することです。
彼は、「高速」の性能が十分に高い、またはどのようにそれのような大規模な流れをサポートすることであると結論しましたか？究極のサーバーのパフォーマンスの最適化を行い、全体の通話リンクの各点は、システム全体の共同の最適化を行う完璧なことができないだけで。
だから、技術的な観点、「安定した、正確で、速い」から、それは次のように私たちのカラムは主に、これらの分野を中心に展開されます、私たちのインフラ、一貫性とパフォーマンスの要件の高可用性に対応しています。
- 高性能。 同時並行読み取りと書き込みの多数を含むスパイク、したがって、この臨界点に高いの同時アクセスをサポートしています。本実施形態の分離カラムの設計データから移動し、見つかったホット階層フィルタリング要求、サービスは、4つの側面に焦点を当て、この最適化の最終端をクリップ単離されました。
- 一貫性。 商品の在庫削減で実装スパイクもキーです。一つは、大規模な同時更新では、「テイク在庫削減」「支払マイナス在庫」と源泉徴収いくつかに分割して、在庫を減らす在庫を減らすために、同時に何度も要求によって同時に商品の限られた数を想像することができますプロセスは、データの正確性を確保する必要があり、その困難は想像します。したがって、私はスパイク在庫削減プログラムを設計する方法に専念記事を使用します。
- 高可用性。 私は極度の最適化のたくさんのアイデアを紹介しますが、現実は常に我々は状況を考慮することができないいくつかのため、システムの可用性と正確性を確保することにバインドされ、我々は最悪の場合に発生するように、すべての詳細を明らかにするPlanBを設計しているが、それでも冷静時間に対処することができます。最後の列は、私はすべての詳細を明らかにするために設計されたプログラムにリンクする考え方から行くことができます。
要約すると、スパイクのシステムは、基本的には大きな出会いの同時実行性、高いパフォーマンスと可用性の高い分散システムです。その後、我々は究極のパフォーマンスの向上を実現するために、この事業のためのスパイクに基づいて、よく分散システムアーキテクチャを満たすために、どのように話を持っています。
アーキテクトの視点がある：プロファイルを概説する最初の、大流量の同時読み取りと書き込み、高性能、および考慮する必要がある要素があるその可用性の高いシステムを構築する方法を考えます。私は「としてまとめ、これらの要素を入れないように4〜1」
できるだけわずか1.データ（絶対的に全体的なバランスとを持っている必要があることを意味しないようにしてください）
第1のユーザによって要求されたデータを意味する、いわゆる「できるだけにデータが」少し小さくすることができます。データアップロード要求は、システムデータを含み、システムデータは、ユーザー（通常はウェブサイト）に返されます。
なぜ「できるだけへデータ」意味ですか？これらの最初のサーバを処理する要求されたデータまたは戻りデータニーズのいずれかに続いて、ネットワーク上で時刻データ伝送がかかりますし、サーバは通常の伝送を減らすため、これらは非常にCPUを消費している、ネットワークを書き込むとき圧縮と文字エンコーディングを行う必要があるため大幅にCPUで使用されるデータの量を減らすことができます。例えば、我々は、スパイクのページサイズを簡素化し、不要なページの装飾効果を削除し、上のようにすることができます。
第二に、「できるだけ小さななどのデータは、」また、通常のデータベースとバックエンドサービスであると扱っている、データを読み込み、保存するために、システムのニーズを完了するために、いくつかのビジネスロジックを含め、システムはより少ないデータにあまり依存し得る必要です。直列化とデータのデシリアライズを伴うだろう、他のサービスを呼び出し、これはCPUの主要なキラーである、それはまた、遅延が増加します。また、データベース自体は簡単なので、可能性とデータベースと対話するように少しと、データがシンプルで、小さく、より良いボトルネックになることができます。
2.要求の数を最小限に抑えるために、
ユーザーが要求されたページを返すと、またページをレンダリングするブラウザは、これらの追加要求すべきで、例えば、など、CSS / JavaScriptや画像、Ajaxリクエストのこのページに依存し、「追加要求」として定義され、他の追加の要求が含まれていますできるだけわずか。ブラウザが行われることへの接続を確立するために、このような3ウェイハンドシェイクとして、いくつかの消費があるだろう、すべての番号を持つ要求を送信するので、時々ページ依存または制限は接続の数があり、（JavaScriptなど）いくつかの要求はシリアルロードなどを必要としています。またDNSは、要求されたドメイン名と異なる場合は、同じものではありません、また、これらのドメイン名が少し長く服用することができる解決します。あなたは覚えているようである大幅にこれらの要因を減らすことができ、リソースの消費量を削減する要求の数。
例えば、最も一般的な方法の数を削減する要求は、ファイルを複数のマージにマージCSSやJavaScriptファイル、JavaScriptファイルにある、URLは、（カンマで間隔https://g.xxx.com/tm/xx-b /4.0.94/mods/ ?? Module1のプレビュー/ index.xtpl.js、JHS-Module1の/ index.xtpl.js、Module1のフォーカス/ index.xtpl.js）。このように、サーバは、まだ各店舗単一のファイルですが、サーバー側のコンポーネントが存在することになるURLを解析し、その後リターンと一緒にファイルをマージするために移動。
できるだけ短い3.パス
「パス」の中間ノードの需要の後、このプロセスでは、データを返すために、ユーザ要求です。一般に、これらのノードは、（転送新しいソケット接続要求を作成するようなプロキシサーバなど）を、システムあるいは新しいソケット接続のように表すことができます。各ノードの後、通常は新しいソケット接続を生成します。ただし、各追加の接続は、新たな不確実性が増加します。確率と統計から、5つのノードの後に要求を参加、各ノードの可用性は、次いで、要求全体の可用性は99.9％である：5乗の99.9％、約99.5％に等しいです。経路が短縮されるだけ可用性要求を増加させることができない、また、効果的に（中間ノードが減少し、シリアル化されたデータを逆シリアル化することができる減らすために）性能を向上させることができ、および（ネットワークトラフィックを削減処理された）遅延を低減します。
複数のアプリケーションを統合する方法があるアクセス経路を短くすることは一緒に配備強い相互依存性であり、リモートプロシージャコール（RPC）は、内部JVM間のメソッド呼び出しとなります。では、「大規模なサイトのアーキテクチャの進化の技術とパフォーマンスの最適化、」本は、私は、この技術の詳細な実装の章を持っています。
4.依存を最小限に抑えるために
いわゆる依存、ユーザーの要求を完了するために参照するシステムやサービスに依存しなければならない、ここで依存の強い依存性を指します。たとえば、あなたがスパイクのページを表示したいと言うと、このページが強い製品情報、ユーザー情報、ならびにクーポン、トランザクションリストなど他人に依存する必要があり、これらの情報は、（弱い依存性）をスパイクしていないことができない、これらの弱いです依存性は、緊急時に削除することができます。
依存度を減らすために、我々は、システムに0などのシステム、レベル1システム、2つのシステムレベル3のシステム、それが最も重要なシステムである場合は0、システムを分類することができ、その後、0システムに強く依存システムも、最もありクリティカルなシステム、そして上のようにします。
0システムが重要でないシステムの崩壊である重要なシステムを防ぐために、レベル1のシステムに強く依存を最小限に抑えることに注意してください。このような決済システムとして0システムであり、クーポンは、クラス1つのシステムです、あなたはクーポンシステムの支払いを防ぐために、極端な場合には、クーポンにダウングレードすることができ崩壊にレベル1のシステムです。
5. Doが単一のポイントを持っていません
バックアップがない一点を意味するので、シングルポイントシステムは、システムのアーキテクチャ上のタブーであると言うことができ、リスクは制御可能ではない、我々は、分散システムを設計した最も重要な原則があるんです「シングルポイント。」
その後のシングルポイントを回避する方法？私は重要なポイントは、このようなサービスのサービスのない状態は、マシンの中で自由に動くことができていること、ステートマシンおよびサービスバインディングを回避することだと思います。
そして、どのようにステート・マシン・サービスは、それをデカップリング？実装の多くもあります。例えば、マシンに依存し、動的構成、これらのパラメータは動的にするとき、サービス開始ダウンダイナミックプルの中心を通ってプッシュするように構成することができ、我々は簡単にこれらのマッピングを変更する構成中心にいくつかのルールを設定します。
ステートレスのアプリケーションは、単一のポイントを回避するための方法ですが、データをディスクに保存するため、サービス自体は、非国家のストレージとして困難であり、機械自体が冗長性によって、一般的には、このシーンをバインドする必要があります一点の問題を解決するために、バックアップ、複数の方法。
注：これらの設計原則のいくつかの前に導入されていますが、見つかっていない、私はいつも、むしろ「絶対」よりも「してみてください」と言いますか？
私は必ずしも少なくとも最高のリクエストはありませんが、私の答えはあなたが尋ねる必要があると思う「は必ずしもありません。」私たちは、ページにいくつかのCSS内ユナイテッドを入れている、そうすることはCSSのホーム・ページのレンダリングスピードアップするために、要求の依存度を減らすだけでなく、ページのサイズが大きくなり、ない原則「できるだけわずかにデータ」に準拠し、このことができます私たちは、レンダリング速度を倍に改善する必要がある場合には、HTMLとCSSの唯一の最初の画面では、負荷に依存してさらに他のCSSファイルに入って来たスピードと折り目のページ全体のロード・パフォーマンスを開くためにバランスを達成しようと異なります。
だから、アーキテクチャはバランスの芸術、シーンのうち一度それに適応するための最良のアーキテクチャであり、すべてのものは空の話になります。
異なるシナリオの下で異なるアーキテクチャの例
建築の原則は、異なる要求の下で体の量をコーミング、淘宝網スパイク初期のシステムアーキテクチャの進化と組み合わせて、そのシステムの前でスパイク、最適なシステム・アーキテクチャのスパイクは何ですか。
すばやく簡単なスパイクシステムを構築したい場合は、単に製品の購入ページを追加する必要が完売在庫がオーバーになるとき、スパイクが始まったときに、ユーザーが唯一の購入ボタンを見ることができるように、機能「棚を時限」 。これが初めてのスパイクシステムの実装のバージョンです。
しかし、（例えば1ワット/秒の10ワット/ sのオーダーからなど）の要求量の増加とともに、このシンプルなフレームワークはすぐにボトルネックが発生し、そのため、システムのパフォーマンスを向上させるためのアーキテクチャを変換するために行われる必要があります。これらのアーキテクチャは、変換が含まれます：
- 独立したシステムは、ページの複雑さを軽減、お店の装飾機能を減らすなど、私たちは、目標と最適化を行うことができますので、スパイクの独立したシステムは、単一のシステムを作成します。
- 独立したシステムの展開でも、マシンのクラスタを行い、このような大きなスパイクは、マシンのクラスタの負荷を購入された商品の通常の流れに影響を与えません。
- 「リードパフォーマンス」を改善するために、単一の緩衝系に（例えば、インベントリデータなど）ホットスポットデータ。
- スパイクは、単一のデバイスをつかむ防ぐため、回答スパイクの増加。
この時点で、システムアーキテクチャは、このような次のチャートになります。最も重要なことは、スパイクは、新しいシステムの独立した内容になった、キャッシュ（キャッシュ）へのコアデータの一部に加えて、他のシステムも展開に別のクラスタ・アプローチに関連付けられています。
：しかし、このアーキテクチャはまたさらに、システムのパフォーマンスを向上させる、我々はさらにインフラのアップグレードなどのためにスパイクよう要求された量は、100ワット/秒を超えることはできませんサポート
- ページには、それによってページの更新データ最小までユーザーは、ときスパイクページ全体を更新する必要がありますが、グラブの宝物にあるボタンをクリックするだけしないように、完全に静的および動的な分離です。
- 商品のスパイクのサービス側はローカルにキャッシュされ、そうであってもシステムコールを減らすことができ、だけでなく、公共のキャッシュ・クラスタのクラッシュを避けるためだけでなく、公共の問い合わせクラスタキャッシュデータに行っていない、データを取得するために呼び出すために、システムのバックオフィスのサービスに依存する必要はありません。
- 電流制限保護システムを増やす、起きてから最悪の事態を防ぎます。
これらの最適化の後、システムアーキテクチャは次の図のようになります。サーバはわずか数の動的データを要求する必要がある一方、ここでは、静的の更なるページは、スパイク・プロセスは、ページ全体を更新する必要はありません。また、最も重要な情報や取引システムは、ホットスポットデータベースは、スタンドアロン展開を行って、というようにしている、商品のキャッシュスパイク事前情報に、ローカルキャッシュを増加しています。
以前のいくつかのアップグレードからは、実際には、より多くのあなたは、より多くの「普通でない」であるところの背中をカスタマイズする必要があります。スタンドアロンメモリは常に限られているとして例えば、各マシンのコモディティキャッシュメモリのスパイクは、このアプローチは、同じ時間の状況スパイクで明らかにあまりにも多くの商品には適していません。だから我々は他の場所（たとえば、汎用性、使いやすさ、コスト、など、などの用語）で犠牲を払う必要があり、究極のパフォーマンスを取得します。
概要
私たちは、上記の下に戻って見てみましょう、私は最初のデザインスパイクシステムを検討するために、3つのキーポイントを紹介し、「着実な、正確な、高速で、」対応する大規模な同時実行、高性能、一般オプティマイザ内のシステムの高可用性がありますできるだけ小さななどのデータは、要求の数を最小限にするために、パスはできるだけ短くすること、できるだけ依存し、単一のポイントを持っていない：アイデア、抽象的であること、原則として「4ないに1」としてまとめました。もちろん、これらの点は、あなたが仕事に持っている、または実際のシーンと、特定の操作の具体的な条件が行われ閉鎖する方向です。要するに、単に思考のメインライン、特定の実装では、特定のシーンと組み合わせることが必要です。
