Q: ますます多くの Web 2.0 Web サイトがアプリケーション プラットフォームに移行していますが、そのようなプラットフォームを構築するための鍵は何だと思いますか?
A: 簡単に言えば、アプリケーション プラットフォームは API です。Ajax または Web 2.0 タイプの Web サイトは、アプリケーション プラットフォーム上の API を使用して、ビジュアル インターフェイスのインタラクティブな効果を作成します。たとえば、Yahoo Mail は、単純な Request 呼び出しを通じて後続の電子メールを読み取ります。この種の Web サイトを構築する場合、Web サイトの発展を決定するパフォーマンスではなく、問題をどのように解決するかを計画するかによって、Web サイトの将来の拡張性 (スケーラビリティ) が決まります。
Q: スケーラブルになるように Web サイトの構造を計画するにはどうすればよいですか?
A: Web サイトのアプリケーションを数十の独立した小さなプログラムに分割し、フロントエンドは API を通じてサービスを提供し、バックエンドはアプリケーション エンジンになります。アプリケーションの各部分には異なる使用レベルがあり、異なるスケーリング レベルが必要であり、それを処理するには異なるメカニズムが必要であるためです。 Yahoo Mail の開発では、アドレス サービス プログラム、メール読み取りサービス、およびメール送信サービスを開発する必要があります。メール送信プログラムは、メール読み取りプログラムとは何の関係もありません。 Yahoo の規模を考えると、スケーラブルにするためには、これらのタスクを完全に分離する必要があります。
Q: この方法でウェブサイトを計画する上で最も重要な鍵は何ですか?
A: 重要なのは、すべてを同じ大きなバスケットに入れるのではなく、個別のモジュール式の独立したエンドポイントを構築する必要があるということです。現在の MVC アーキテクチャの開発フレームワーク (MVC フレームワーク) のほとんどは、いわゆるフロントエンド コントローラー (フロント コントロール) を使用します。ブラウザーが Request リクエストを行うたびに、このフロントエンド コントローラーが呼び出され、次にフロントエンド コントローラーが呼び出されます。エンドコントローラーは、ユーザーが実行したいプログラムを識別します。そんなことをしてもまったく意味がありません。
ブラウザ レベルでは、プログラムはユーザーが何をしたいのかを完全に把握できます。たとえば、ユーザーが単に手紙を読みたいだけの場合、プログラムはサーバーにリクエストを送信して、サーバーに判断させる必要がなくなりました。ユーザーは手紙を読みたい、または手紙を送りたいと考えています。この種の意思決定作業をブラウザーから取り出してサーバーで処理させると、ユーザーにとって実際には使用しない作業に多くのサーバー リソースが無駄になります。スケーラビリティはアーキテクチャから生まれ、多くの開発フレームワークはすべてを結び付けてアーキテクチャを制限します。間違った開発フレームワークを選択すると、スケーラビリティが得られません。
Q: MVC モデルは Web サイトのスケーラビリティに役立たないと言っているのですか?
A: MVC モデルは、ページ コントローラー (ページ コントロール) レベルでの使用により適しています。基本的に各Webコントローラは独立したモジュールであり、メール読み込みとアドレスチェックは別のWebコントローラとなるため、メール読み込みプログラムがアドレスチェックプログラムを干渉することはありません。したがって、MVC パターンを使用して各エンドポイントに小さな Web コントローラーを作成することに問題はありません。ただし、MVC モデルを使用するほとんどのフレームワークは、デフォルトで Web コントローラーではなくフロントエンド コントローラーを使用します。この MVC モデルは、小規模な Web サイトまたは単一サーバーの Web サイトにのみ適しています。
Q: 開発フレームワークはどのように選択しますか?
A: 単一のフレームワークを使用しないでください。ただし、フレームワーク全体を適用するのではなく、これらの開発フレームワークの中から必要な機能を見つけ出し、必要なプログラムモジュールを使用したり、その中の設計思想を参考にしたりすることになります。私がこれまで見てきたフレームワークのほとんどは、効率的な拡張性と MOD 対応性の構築に焦点を当てていませんでした。
Q: 開発者にはフレームワークやアーキテクチャは必要ありませんか?
A: ウェブサイトには構造が必要です。フレームワークは問題を解決するための手段です。ただし、通常は機能しないフロントエンド コントローラーに関するすべての問題を解決するための一般的なフレームワークは必要ありません。すべての問題は異なるため、フレームワークをブートストラップし、適切な設計パターンを使用して、対処している実際の問題に直接対処する必要があります。たった一種類の車を生産して、どうして世界中の人々のニーズに応えることができるのでしょうか？
プロトタイプ システムを開発するためにフレームワークを使用するのは問題ありませんが、それらすべてを実際の製品に適用しないでください。フレームワークから始めるほうが簡単ですが、フレームワーク全体を解体し、実行時チェックを削除し、不要な機能を削除して、使用するプログラム モジュールだけを残す必要があります。将来の拡張性を提供しない汎用フレームワークは必要ありませんが、最初から始める必要はなく、中間のものが必要です。
Q: Web サイトの拡張ニーズに対応する計画を立てるのにどれくらい時間がかかりますか?
A: 私は将来のことを考えすぎるのがいつも嫌いです。未来を予測できないときは、将来について決断を下すしかありません。
インターネットの変化はとても早いので、私は通常半年以内にしか計画を立てません。半年後に何が起こるかを今決めてしまうと、誤った決定につながり、状況がさらに悪化する可能性があります。現在の問題を解決するのではなく、将来起こる問題を想像するのであれば、目の前にある問題を解決して、自分の製品に真剣に取り組みたいと思います。今必要です。
Q: では、建築家が従うべきガイドラインはありますか?
A: 主な原則は、プログラム モジュールをどのように割り当てるかを慎重に検討し、プログラムを可能な限り小さなコンポーネントに分解し、適切な API を調整することです。計画する必要があるのは、ブラウザー リクエストの種類などのユーザー エンドポイントです。それは...ですか？アプリケーションはどのように応答すべきでしょうか?カットできますか？これらのタスクを完全に別のサーバーに分散することは可能ですか?同じサーバー上でも、ユーザー エンドポイントの観点からアプリケーションを設計できます。いつか、規模が大きくなったら、フロントエンド サーバーに 2 台目のサーバーを簡単に追加できるようになります。トラフィックを保存せずに共有できます。あらゆるデータ。開発者がよく犯す最大の間違いは、プログラム コード間の相互関係が深くなりすぎて、各コンポーネントが他の外部コンポーネントと通信する必要があるため、非常にクリーンな API を調整することが困難になることです。開発者は遅い API を抽出してセカンダリ サーバーに置くことができなくなり、プライマリ サーバーは必要な API のみを実行することになります。
Q: 切断サービスと分解プロセスの難しさは何ですか?
A: 始める前に問題をよく理解する必要があります。プログラムの最初のバージョンを書き終えると、問題を分解し始めることはほとんど不可能であり、その後対処するのは困難です。質問がコロコロ変わるので本当に難しいです。ただし、単純なアーキテクチャから開始し、この精神を維持してアプリケーション モジュールを分離する場合は、ウェブサイトが変更されるたびに、問題の変更はほんの一部にのみ影響します。その場所をよく知ることができ、問題を直接解決することができます。レゴゲームと同じように、小さな積み木をひとつずつ作っていくと、不足があれば小さなピースを追加するだけでよく、全体を大きく変える必要はありません。
Q: スケーラビリティに加えて、Web サイトのパフォーマンスを向上させるにはどうすればよいですか?
A: パフォーマンスを向上させるには、まず各プログラムにどれくらいの時間がかかるかを知る必要があります。ユーザーが Request リクエストを送信した後、データの最初のバイトを受信するまでにどのくらい時間がかかりますか?多くの開発者は、この時間 (最初のバイトのレイテンシー) がどれくらいなのか、またはコードにどれくらいの時間がかかるのかを知りません。プロファイルを使用してパフォーマンスを追跡し、視覚的なパフォーマンス フローチャートを描画してボトルネックがどこにあるかを理解できます。
単一マシンのレイテンシーを考慮しても、システムレベルの追跡プログラムを通じて、プログラムによって実行される各システムコール (システムコール) にかかる時間を知ることができます。また、ブラウザーの遅延を考慮し、ユーザーが体感する実際の速度に基づいて Web ページの実行方法を改善する必要もあります。
新しい機能を追加するたびに、新しい機能が何ミリ秒増加するかを計算し、それに価値があるかどうかを考えることができる必要があります。
Q: では、Web サイトのセキュリティについてはどのような原則に注意を払う必要がありますか?
A: 基本的な精神は非常にシンプルで、データ ファイアウォールの概念を使用して Web サイトを設計するだけです。インターネット ファイアウォールはすべての通信ポートを厳密に監視し、セキュリティ上の懸念がないパケットのみの通過を許可します。しかし、Web サイト開発者は逆に、危険だと思われるコンテンツのみをブロックします。開発者は、外部から取得したデータを信頼できません。ファイアウォールの概念と技術を借用してデータ ファイアウォールを確立することで、Web サイトのセキュリティを向上させることができます。
Q: 優れた建築家の要件は何ですか?
A: テクノロジーをよく理解し、データ ストレージ メカニズムの設計など、あらゆる詳細を理解する必要があります。保存できるデータの種類、ファイルのサイズ、保存できるデータの量などを理解する必要があります。 、1秒あたりどれくらいの速さで保存できるのでしょうか？データをコピーするにはどうすればよいですか?フロントエンドでどのデータ形式を使用する必要があるかなど。アーキテクトは、DBA のように Oracle データベースのエラーを修正する方法を知る必要はありませんが、Oracle データベースの機能を理解できなければなりません。このような人はなかなか見つかりません。十分な経験を積むまでは、何度も失敗しなければなりません。
Q: 台湾にはまだ PHP 4 を使用している古い Web サイトがたくさんあります。今すぐ PHP 5 にアップグレードする必要がありますか?それともPHP 6を待ちますか?
A: できるだけ早く PHP 5 にアップグレードしてください。いくつかのテストと変更を加えれば、パフォーマンスとセキュリティを向上させることができます。なぜそうしないのでしょうか?オープンソース コミュニティの仕組みである PHP 6 を待つ必要はなく、リリース時期の約束はありません。 PHP バージョン 5.3 には多くの新機能が追加されています。できるだけ早く 4 から 5 にアップグレードすることが最も重要です。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
