サーバーサイド開発の簡単な紹介_PHP チュートリアル
- WBOYオリジナル
- 2016-07-20 10:59:03838ブラウズ
数日間サーバーサイド開発に従事してきたので、落ち着いてサーバーサイド開発のアイデアをいくつか考え、記録することができます。
サーバーサイド開発、特に Web 開発は、基本的に HTTP リクエストの処理がすべてです。具体的な用途に応じてWebページ開発とAPIインターフェース開発の2種類に分かれます。 Web ページの開発は API インターフェイスの開発とみなすこともできますが、ページと Ajax リクエストという 2 つの主要な部分があります。1 つは HTML を返すことで、もう 1 つは HTML またはその他の形式を返すことができます。 APIインターフェース開発はクライアント製品向けです。モバイル デバイスの場合もあれば、PC アプリケーションなどの場合もあります。
アプリケーションフレームワーク
アプリケーションフレームワークは通常、LNMPまたはLAMPを使用します。基本的なフレームワークは、フロントエンドN個のWebサーバーマシン+PHPへのCGIアクセス+mysqlへのphpアクセスです。
PHP は、C で書かれた大規模な Web フレームワークとみなすことができます。その利点は、解釈され、リアルタイムで変更および更新できることです。そのため、オンラインでのコード更新やメンテナンスのコストが非常に低く、また一部の機能はほぼWeb開発向けにカスタマイズされているため、Web開発に適しています。 Java で Web サービスを開発する場合に比べれば、時々再コンパイルが必要になる手間は十分にあります。
Web サーバーでは現在、nginx を使用することが増えています。Apache に対する nginx の利点は、その移植性と静的ページの高い同時実行パフォーマンスです。一般に、機器を入手するときは、まず 1 台のマシンが耐えられるおおよその QPS を考慮する必要があります。その方法は、まずメモリのみを考慮し、同時に開くことができる php-cgi の数を計算することです。たとえば、4G メモリを搭載したマシンでは、各 php-fpm は約 20M のメモリを占有するため、ほぼ 200 の php-cgi プロセスを開くことができます (通常、一部は空きのままになります)。各プロセスは同時に 1 つの php プログラムしか実行できません。各 php プログラムが 0.1 秒間実行されると仮定すると、1 秒で 10 個のリクエストを処理できるため、単一マシンの QPS は約 2000 になります。もちろん、通常はそのような極端なレベルまでオンにすることはありません。理由はいくつかあります。
1 他のプロセスのメモリ使用量を考慮する必要がある
2 すべてのメモリが使い果たされたら、スワップを有効にするかどうかを検討する。そうではありません。マシンはすぐにクラッシュしますか
3 CPU と帯域幅の使用状況も考慮する必要があります。暗号化、復号化、ビデオのトランスコーディングなどの CPU 操作には時間がかかります。この時点でキューを使用しないと、各リクエストの時間が長くなります。
ファイルサーバー
通常、分離とは、ファイルサーバーとWebサーバーを分離するために異なるドメイン名を使用することを意味します。もちろん、Webサーバーをファイルサーバーとして使用することもできますが、ファイルサーバーはファイルをアップロードする必要があり、ファイルのアップロードには非常に時間がかかる作業、つまりPHPプログラムが長時間滞留する必要があるため、したがって、それらは分離する必要があります。将来のファイル サーバーの拡張が容易になる一方で、ファイル サービスは通常の Web サービスに影響を与えません。
ファイル サーバーを分割する理由から判断すると、リソースを消費する、または操作中に特に頻繁に呼び出される一部のインターフェイスは、別のマシンに分割することができる、または考慮されるべきです。
Web フロントエンド マシンは常に永続データにアクセスする必要があり、mysql が最も頻繁に使用されます。実際、すべての Web サービスは基本的にデータベースの追加、削除、変更、確認の操作です。パフォーマンスに関しては、データベースの追加、削除、変更、クエリ操作のパフォーマンスがすべてを決定します。したがって、データベースのテーブルとインデックスの使用は、Web サイトにとって特に重要です。私が最も便利だと思う mysql テクニックは次のとおりです:
1 インデックスをカバーします。それは、クエリ操作でテーブルではなくインデックスのみがチェックされるようにインデックスを作成する方法を見つけることです。適切なインデックスと、インデックス内でのみデータを検索できるクエリを作成すると、効率が向上します。
2 挿入操作の効率を向上させるには、InnoDB テーブルで自動インクリメント キーを使用するのが最善です。
3 文字列型変数の保存形式はvarcharとcharのどちらを使用するのが良いのでしょうか？ テーブル設計をcharからvarcharに変更した後のデータベースサイズの差が70Gと20Gだったプロジェクトがありました...
4 テーブルを構築するときに考慮する必要があるシャーディング データベースとテーブルをダウンロードした後、シャーディングを使用する場合、シャーディング キーは何ですか?逆引きテーブルが必要ですか?
5 コンピューター室でのデータベースと Web マシンの分散を考慮しても、この設計はさらに面倒になります...
mysql のテーブル作成プロセスは需要と大きく関係しています。明確な要件がなければ、テーブルの設計は間違っているはずです。
データベースのサポートだけでは十分ではない可能性があるため、最初に思い浮かぶのはキャッシュかもしれません。キャッシュはグローバルキャッシュを使用していますか? Web フロントエンド マシンに置きますか?どのようなハッシュ アルゴリズムを使用する必要がありますか?どのキャッシュを使用するか?メムキャッシュ？レディス？ MySQL には独自のキャッシュもあります。このキャッシュをより適切にヒットするにはどうすればよいでしょうか?データが更新されたとき、キャッシュ内のデータは汚れていませんか?データを更新するにはどうすればよいですか?
Web ページ開発
Web サイトを構築する必要がある場合、最初に考慮することは、その Web ページに何人のユーザーがいるかということです。 SNSサイトを作るのと、運用バックエンドのサイトを作るのは全く別の概念です。
まず、ページプレッシャーに関して言えば、SNS ウェブサイトの qps は数千、数万になる場合がありますが、操作のバックグラウンドプレッシャーはほぼ計算なしで計算できます。これは、バックエンド データベースのサポートが異なることを意味します。 SNS Web サイトでは、友人関係や個人情報のインターフェイスを呼び出すことがよくありますが、そのようなインターフェイスは個別に処理する必要がありますか?このようなリクエストの多くは繰り返されるでしょう。データベースへの直接的な負荷を軽減するために、ミドルウェアまたはキャッシュの使用を検討する必要がありますか?運用データは通常、単一のテーブルを使用して解決できます。個人的には、運用における統計要件の達成が最も難しいと感じています。まず第一に、統計は統計要件を満たすことができません。このニーズは製品ディスカッションの要件に関連しています。第 2 に、統計には一般にアクセス ログなどの使用が必要であり、これには多くのシェル スクリプトが関与する場合があります。
API開発
実際、Web開発に比べてAPI開発は受動的です。これは、クライアントが携帯電話製品または PC 製品である可能性があることを意味します。多くの場合、リリースとバージョンがあります。これは、API インターフェイスが Web のようにいつでもコードを更新できないことを意味します。さまざまなバージョン間の互換性の問題についてさらに考慮する必要があります。互換性の問題は主に足し算になり、決して引き算されることはありません。個人的には、必要に応じて無制限に対応すると、バージョンが増えるにつれてコード内に if else が増え、最終的にはまったく保守できなくなると感じています。そうなると、他の誰かがあなたの仕事を引き継ぎ、罠に足を踏み入れ、叱りながらリファクタリングすることになります...API 開発はテストに最も依存します。多くの場合、テスターだけが各バージョンに小さな変更を加えますが、小さな機能は無数にあります。
次に、非機能パッケージについて検討します。
インターフェースのパフォーマンスを理解できるように、API 呼び出し時間の統計を保持する必要がある場合があります。
コードは、別のサービスのカーリングなど、他のマシン上のサービスを使用することもあります。この場合、エラー処理とログを考慮することが最善です。
金銭取引を伴うインターフェースサービスの場合、ログ処理はさらに重要です。
一部の内部エラーについては、ユーザーに直接スローしないことが最善であるため、ホワイトリスト エラー メカニズムを使用することが最善です。
インターフェースの暗号化方式には、一般的に少なくとも署名機構が必要です。暗号化方式には、大きく分けて対称暗号化と非対称暗号化があります。暗号化するときは、モバイル クライアントの電力消費など、いくつかの状況を考慮する必要があります。
携帯電話用のインターフェイスを開発している場合は、トラフィックの問題と画像の仕様を考慮する必要があります。
需要の変化はもちろん、ユーザー数の変化だけでも、20万ユーザーと100万ユーザーでは枠組みが違うはずです。当初、100 万人のユーザーをベースにして 20 万人が使用できるフレームワークを設計することはできませんでした。したがって、優れたサーバー側フレームワークは、ユーザー数の変化に応じていくつかの大きな変更を加える必要があります。
…
追記
思いつきでこの記事を書き始めたのですが、書き続けることができないことに気づきました… つまり、Webサービス開発にはまだまだスキルやガジェットがたくさんあります。痛みを知る前に、いくつかの穴を踏む必要があります。かわいいのは、私がまだ落とし穴にはまっていることです...
さらに、インターフェイスのリファクタリングは、ほぼすべてのサーバー開発者が経験する必要があるものです。新しいシステムを開発するのに比べて、インターフェースの再構築の難易度は非常に難しいと言えます。もちろん、ここでの難しさは違和感の度合いとしても理解できます...非常に訓練される作業でもあります。リファクタリングの場合、テストが特に重要です。リファクタリングの正確性を確認するために適切なテスト セットを用意する方法は困難です。