PHP の父である Rasmus Lerdorf 氏が PHP 開発について語る

Web サイトをスケーラブルにするには、すべてを同じ大きなバスケットに入れるのではなく、個別のモジュール式の独立したエンドポイントを確立する必要があります。


PHP 言語の創始者であるラスムス・レルドルフは、プログラムは完璧である必要はなく、シンプルで効果的であるべきだと信じています。これが最も重要であり、難しいことです。この記事の出典を明示したい場合は、無料で公開します。QQ9256114
PHP は世界中で使用されています。開発言語としては、台湾の Web サイトの 4 つのうち 1 つは PHP 言語で開発されています。
1995 年に PHP 言語を発明し、Yahoo のグローバル サービス Web サイトを構築したアーキテクトの 1 人でもある Rasmus Lerdorf 氏が初めて台湾を訪れ、Web サイトのスケーラビリティ、セキュリティ、パフォーマンスを構築する方法に関するヒントを共有しました。

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 コントローラはメール読み取りとアドレス検査は別のモジュールであるため、メール読み取りプログラムがアドレス検査プログラムを干渉することはありません。したがって、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 にアップグレードすることが最も重要です。