-
このシリーズの最後の記事は一般のプログラマ向けに書かれています。興味がない場合は、この記事の最後の数段落だけ読んでください。
コード構造の設計を開始する前に、これまでに準備したものを確認してみましょう。負荷分散された WEB サーバー、マスター/スレーブ DB サーバー、および場合によってはシャーディング、キャッシュ、およびスケーラブルなストレージがあります。コードを整理するすべての側面は、これらの準備と密接に関連しています。それらを 1 つずつ、2 つずつリストします。簡単に比較できるように、それぞれを「前述の」古典的な文から始めます。
古典的な文型を急いで読まないでください。私の心が飛び上がったので、段落を挿入します。実際の開発では、パフォーマンスとコードの優雅さの間で常に妥協を図ります。今日のコンピュータと言語インタプリタにとって、オブジェクト呼び出しの層が何層あるのか、変数を Map として宣言するか HashMap として宣言するのかという問題は、常にシステムの最も遅い部分を考慮して解決する必要があります。最も遅い部分から。たとえば、使用している ORM が不要な処理を多く実行しているかどうか、データ呼び出しが繰り返し行われているかどうかを確認します。私たちが行っているのは Web アプリケーションの開発であり、基礎となるフレームワーク API ではありません。プログラムの設計目的は、品質を確保するために非常に重要です。このトピックは忘れてください。この記事は別の話になります。連絡したい場合は、私の Weibo をフォローしてください: http://t.sina.com.cn/liuzhiyi 。
前述したように、WEB サーバーは負荷分散する必要があり、画像サーバーは分離する必要があります。この点に関しては、コードがクライアントのステータスを処理する場合、たとえばファイル セッションを使用しないでください。可能であれば、ドメイン全体のステータスを判断する方法、静的ページでのステータスを判断する方法、ログイン時のジャンプおよびリターンパラメータの定義など、ユーザーのシングルポイント認証用の統一インターフェイスを最初から開発することが最善です。 . 最下層に適切なインターフェイスを提供し、それを適用します。この層は直接使用されます (GAE のユーザー サービスを参照)。ログインの設計では、モバイル デバイスの特性を考慮する必要があります。たとえば、コンピュータはフローティング レイヤ ウィンドウを使用できますが、NOKIA 独自のブラウザや UCWEB はこの形式の表現を処理できません。プログラムは、Ajax リクエストと URL 経由の直接の両方を処理できなければなりません。 。 聞く。画像サーバーは分離されており、リソース ファイルは画像サーバーに最適に配置されます。つまり、WEB サーバーは動的プログラムのみを提供します。開発とテストは少し複雑ですが (アクセスするには絶対 URI が必要なため)、将来的にはページのフロントエンドの最適化がはるかに簡単になり、WEB サーバーの IO 最適化も行われます。はるかに簡単になります。プログラムがリソース ファイルを参照する場合、CSS/js をファイルに結合したり、フロント エンドで生成された URI の後に QUERYSTRING を自動的に追加したりするなど、多くの処理をメソッド内で自動的に完了できるようにする必要があります。キャッシュ サービスが使用されている場合、クエリストリングの生成がサーバー キャッシュとクライアント キャッシュを更新する最も簡単な方法です。
前述したように、データベースは複製され、複数のマスターと複数のスレーブが存在し、シャーディングされる場合があります。プログラムでデータを処理するプロセスでは、データを抽象化して別のレイヤーに置くことが最善です。一般的な MVC モデルを例に挙げると、M 層の下にデータ層が配置されます。このデータ層は、一般的に知られている JDBC/PDO/ActiveRecord などではなく、メソッドを公開するだけの独自のアクセス データ層です。データアクセスの詳細を非表示にします。このデータ層内に醜い記述があることを恐れる必要はありませんが、他のレベルでデータベースを扱う言葉はすべてのデータ ストレージ機能を提供する必要があります。その理由は、単一のリレーショナル データベースの場合、SELECT...JOIN... または直接 INSERT...INTO... を実行できるが、一部のテーブルをキーと値のデータベースに格納する可能性があるためです。その後、元のステートメントとメソッドをすべて変更する必要があります。分散しすぎると、移植時に多大な労力が費やされ、非常に大きなモデルが作成されます。データレベルの設計に関しては、JOIN クエリを避けるようにしてください。各種類のデータに必要なクエリは 1 つだけで済み、それをプログラム内で組み合わせることができます。より複雑なデータの組み合わせの場合、リアルタイム要件が高くない場合は、非同期処理を使用でき、ユーザーはアクセス時にのみ処理結果を取得できます。主キーを扱うときは、自動インクリメント ID の使用を避け、特定のルールによって生成された一意の値を主キーとして使用します。この主キーは最も単純なシャーディング分散戦略です。自動インクリメント ID を使用する場合でも、自動インクリメント ID ジェネレーターを使用することをお勧めします。そうしないと、スレーブ データベースが誤って書き込まれると、主キーが競合しやすくなります。
前述したように、データベースの前面をブロックしているキャッシュがいくつかあります。 MySQL のクエリ キャッシュをキャッシュとして扱わないでください。アプリケーションが少し複雑になると、QUERY CACHE が負担になります。キャッシュはデータベースおよびビジネスと密接に統合されており、ビジネスと密接に関係しているため、万能のアプローチはありません。しかし、私たちにはまだ従うべきルールがいくつかあります。ルール 1: フロントエンドに近づくほど、キャッシュの粒度は大きくなります。たとえば、ページ全体が WEB のフロントエンドでキャッシュされ、ページの一部が次のレベルでキャッシュされ、領域内の 1 つのレコードが次のレベルでキャッシュされます。バックエンドに近づくほど操作性が柔軟になり、最も変更が多いフロントエンドのコードが書きやすくなるからです。実際には、製品の要件は非常に急速に変化し、反復サイクルはますます短くなっているため、コントローラーとモデルを明確に区別することが難しい場合があります。コントローラー レベルでは部分キャッシュが避けられませんが、これが確実に行われるようにする必要があります。つまり、このキャッシュされたデータがこのコントローラーによってのみ使用されることを保証する必要があります。ルール 2: プログラムはキャッシュなしではエラーを起こすことはできません。キャッシュの無効化による雪崩効果を考慮しない場合、プログラムにはキャッシュがあり、キャッシュがない場合と同じである必要があります。キャッシュが失敗すると、ファン Weibo は空になり、アプリケーション全体が停止します。めちゃくちゃ。キャッシュが不可欠な場合は、誤解を招くメッセージを与えるよりも、エラー メッセージをユーザーに与える方が良いでしょう。ルール 3: キャッシュの更新はアトミックまたはスレッドセーフである必要があります。特にパッシブ キャッシュが使用されている場合、2 人のユーザーがアクセスしたときに同じキャッシュが更新される可能性が非常に高くなります。通常、これは大きな問題ではなく、キャッシュは再構築できます。これが連鎖反応の原因の 1 つである可能性があります。ルール 4: キャッシュにもコストがかかります。技術コストだけでなく、人件費もかかります。キャッシュを使用する関数と使用しない関数では、予想されるアクセス量の差は小さいですが、キャッシュを使用すると複雑さが増す場合は、TODO マークを追加し、次のイテレーションでキャッシュ処理を追加する必要はありません。
前述したように、ファイル ストレージは独立しているため、すべてのファイル操作はリモート呼び出しです。ファイル サーバー上に非常に単純な RESTful インターフェイスを提供することも、Web サーバーによって生成および処理されたすべてのファイルをファイル サーバーに通知して処理することもできます。あらゆるファイルストレージを提供します。このため、多くの大規模 Web サイトでは、画像のアップロードと記事の保存が 2 ステップで完了します。
上記の「前に述べたこと」は、実際に数え切れないほどの人が言ったことですが、これまでの記事に基づいて私自身の言葉で繰り返しました。実際の分析の本質は非常にシンプルです。適切な機能ロジックの階層化に加えて、デザインも必要です。データベース ストレージ、キャッシュ、キュー、ファイル サービスなどの外部リソース呼び出し用の個別のインターフェイス。プログラムは Amazon EC2 上で実行され、そのすべての Web サービスを使用します。データベースはその SimpleDB であり、キューはその SQS です。唯一の違いは、Amazon のインターフェイスはリモート呼び出しであり、あなたのインターフェイスは内部呼び出しであることです。
サポート サービスのインターフェイスとは、MySQL を PostgreSQL に置き換える際にビジネス処理プログラムを変更する必要がないことを意味し、移行チームはビジネス開発チームとあまりやり取りする必要さえなく、むしろビジネス開発チームがインターフェイスをプログラミングしていることを意味します。データベースをプログラミングするよりも、ビジネス開発者のミスによってパフォーマンスが低下することはありません。
プログラムリテラシーに興味がない方は、ここを見てください——
製品設計が完了し、プログラム フレームワークが構築された後、この時点で競合が発生する可能性があります。製品設計者からは自分のアイデアが望ましい結果を達成できないという苦情が絶えず、プログラマーからは製品設計が非現実的であるという苦情が絶えません。この種の苦情は、製品担当者が技術を理解していない、技術担当者が製品を理解していないことが主な原因です。広い意味での製品には、市場戦略、マーケティング手法、機能設計などが含まれます。製品や技術について議論するとき、その機能に焦点が当てられることがよくありますが、実際にはその機能を実現するためのコストと、その機能がもたらすメリットに焦点が当てられます。変換できるかどうか、考慮できるかどうか。可能であれば、紛争を解決してください。そうでない場合は、コインを投げて運を見てください。機能強化でインジケーターがパンクしたり、プロジェクトの遅れで戦闘が遅れたりする例は多々あります。急進的な意思決定者は利益に焦点を当て、保守的な意思決定者は損失に焦点を当て、賢明な意思決定者は問題が本当に深刻かどうかを検討します。
そうでなければ、起業の半分は運に左右されます。しかし、正確に言えることは常にあり、それを語るにはデータに頼る必要があります。
100% ではありませんが、99.9% の Web サイトにアクセス統計コードがインストールされています。私のhttp://zhiyi.usも例外ではありません。新文ネットワークでは常に科学的な意思決定と科学の発展について話しています。統計を使用すると、判断できることがたくさんあります。たとえば、ソースとターゲットのコンバージョン率に基づいて 1 人当たりの獲得コストが最も低いチャネルを分析したり、ソース コンテンツへのアクセスに基づいてユーザーの直帰率の理由を推測したり、ユーザーのクリックに基づいてリンクの位置が適切かどうかを判断したりできます。行動。さまざまな方法でデータを組み合わせて、内部のつながりを見つけ、内部および外部の要因を分析し、対応する戦略を策定し、額をたたくような意思決定を減らします。運用をサポートするためにデータに依存することは非常に専門的な問題です。私は深い数学モデルや複雑な数式計算を理解していませんが、B は A のせいであり、C は A と B のせいであることが徐々にわかりました。それでも比較的単純です。 。
記事の著者: Liu Zhiyi (転載する場合は出典リンクと著者を明記してください)
記事のソース: http://zhiyi.us/