記事を始める前に、nginx を学習する必要がある学生に、nginx の中国語の公式ドキュメントを提供します。皆さんのお役に立てれば幸いです。以下のカードから直接入手できます。
ファン特典、自習教材を期間限定でご用意！magedu2018.mikecrm.com/I9zX5EO
テキストを始めましょう！
Jianshu の記事を共有します。Nginx の説明は非常に優れています。記事リンク: Nginx in simple tongue。著者のホームページ: Zhang Fengzhe - Jianshu。
Nginx は軽量の Web サーバーおよびリバース プロキシ サーバーであり、メモリ フットプリントが小さく、起動が非常に速く、同時実行機能が高いため、インターネット プロジェクトで広く使用されています。
アーキテクチャ図
上の図は基本的に現在一般的な技術アーキテクチャを示しており、Nginx はエントリー ゲートウェイに似ています。
リバースプロキシサーバー?
リバース プロキシなどの用語についてよく聞くのですが、リバース プロキシとは何ですか、フォワード プロキシとは何ですか?
フォワードプロキシ:
フォワードプロキシの図
リバースプロキシ:
リバースプロキシの図
ファイアウォールのため、Google に直接アクセスできないため、VPN を使用してこれを実現できます。これは単純なフォワード プロキシの例です。ここでは、フォワード プロキシがクライアントを「プロキシ」しており、クライアントはターゲットを認識していますが、ターゲットはクライアントが VPN 経由でアクセスされていることを認識していないことがわかります。
外部ネットワークからBaiduにアクセスすると、実際には内部ネットワークへの転送とプロキシが行われますが、これがいわゆるリバースプロキシ、つまりリバースプロキシがサーバー側で「動作」するのですが、このプロセスは非常に複雑です。クライアントにとっては困難なため、透明性を確保してください。
Nginx マスターワーカー モード
nginxプロセス
Nginx を起動すると、実際にはポート 80 で Socket サービスが起動され、監視が行われます (図に示すように、Nginx には Master プロセスと Worker プロセスが関与します)。
マスターワーカーモード
nginx.conf
マスタープロセスの役割は何ですか?
構成ファイル nginx.conf を読んで確認し、ワーカー プロセスを管理します。
ワーカープロセスの役割は何ですか?
各ワーカー プロセスは (スレッドの切り替えを回避するために) スレッドを維持し、接続とリクエストを処理します。ワーカー プロセスの数は構成ファイルによって決定され、一般に CPU の数に関連していることに注意してください (プロセスの切り替えに有利です)。ワーカー プロセスは、設定した数だけ指定できます。
考察: Nginx はどのようにしてホット デプロイメントを実現するのでしょうか?
いわゆるホット デプロイメントとは、構成ファイル nginx.conf を変更した後、Nginx を停止したり、構成ファイルを有効にするための要求を中断したりする必要がないことを意味します。(nginx -s reload リロード/nginx -t 構成の確認/nginx -s stop)
上記のことから、ワーカー プロセスが特定のリクエストの処理を担当していることがすでにわかっているため、ホット デプロイメントの効果を実現したい場合は、次のように想像できます。
オプション 1:
構成ファイル nginx.conf を変更した後、メイン プロセス マスターは更新構成情報を waker プロセスにプッシュする役割を果たし、waker プロセスは情報を受信した後、プロセス内のスレッド情報を更新します。(少し不安定です)
オプション II:
設定ファイル nginx.conf を変更した後、新しいワーカー プロセスを再生成します。当然、リクエストは新しい設定で処理され、新しいリクエストは新しいワーカー プロセスに引き継がれる必要があります。古いワーカー プロセスと同様に、以前のリクエストは処理されます。処理後は、強制終了するだけです。
Nginx はホットデプロイメントを実現するために 2 番目のソリューションを採用しています。
考察: Nginx は、高い同時実行性の下でどのようにして効率的な処理を実現するのでしょうか?
前述したように、Nginx ワーカー プロセスの数は CPU にバインドされており、ワーカー プロセスにはリクエストを処理するために効率的にループバックするスレッドが含まれています。これは効率には役立ちますが、十分ではありません。
プロのプログラマーとして、私たちは想像力を働かせることができます。BIO/NIO/AIO、非同期/同期、ブロッキング/ノンブロッキング...
非常に多くのリクエストを同時に処理するには、一部のリクエストには長い時間がかかる IO が必要であることを理解しておく必要があり、それを待っているとワーカーの処理速度が低下します。
Nginx は Linux epoll モデルを採用しています。epoll モデルはイベント駆動型のメカニズムに基づいています。複数のイベントの準備ができているかどうかを監視できます。OK の場合は、イベントを epoll キューに入れます。このプロセスは非同期です。ワーカーは epoll キューから循環するだけで済みます。
考え中: Nginx がクラッシュしたらどうすればよいでしょうか?
Nginx は入口ゲートウェイとして機能するため、非常に重要であり、単一点で問題が発生した場合は明らかに許容できません。
答えは、「Keepalived+Nginx は高可用性を実現する」です。
Keepalived は高可用性ソリューションであり、主に単一ポイントのサーバー障害を防ぐために使用され、Nginx と併用して Web サービスの高可用性を実現できます。(実はKeepalivedはNginxだけでなく他の多くのサービスとも連携可能です)
高可用性を実現する Keepalived+Nginx の考え方:
1 つ目: リクエストは Nginx に直接送信されるべきではなく、最初に Keepalived 経由で送信される必要があります (これはいわゆる仮想 IP、VIP)
2 番目: Keepalived は、Nginx の生存ステータスを監視できる必要があります (Nginx プロセスのステータスを定期的にチェックし、重みを変更するためのユーザー定義スクリプトを提供することで、Nginx フェイルオーバーを実現します)。
キープアライブ+Nginx
私たちの主戦場: nginx.conf
多くの場合、開発環境やテスト環境では、Nginx を自分で構成する、つまり nginx.conf を構成する必要があります。
nginx.conf は典型的なセグメント化された設定ファイルなので、以下で分析してみましょう。
仮想ホスト
httpサーバーセグメント
結果にアクセスする
実際、これは静的リソースを処理する Web サーバーとして Nginx を使用しています。
第一に、ロケーションは通常のマッチングを実行できます。通常のマッチングのいくつかの形式と優先順位に注意する必要があります。(ここでは展開しません)
2 番目: 速度を向上できる Nginx の機能の 1 つは、動的と静的な分離です。これは、静的リソースを Nginx に配置し、Nginx によって管理し、動的リクエストをバックエンドに転送することを意味します。
3 番目: Nginx では、静的リソースとログ ファイルを異なるドメイン名 (つまり、ディレクトリ) に割り当てることができるため、管理とメンテナンスが容易になります。
4 番目: Nginx は IP アクセス制御を実行できます。一部の電子商取引プラットフォームは、Nginx レイヤーで何らかの処理を実行し、ブラックリスト モジュールを構築できます。そうすると、リクエストが Nginx を介してバックエンドに到達してインターセプトするのを待つ必要はありませんが、直接受信できます。 Nginx層で処理されます。
リバースプロキシ [proxy_pass]
いわゆるリバース プロキシは非常にシンプルで、実際には、場所の設定の root をproxy_passに置き換えるだけです。ルートの説明は Nginx によって返される静的リソースですが、proxy_pass の説明は Tomcat へのプロキシなど、転送する必要がある動的リクエストです。
リバースプロキシは、上で述べたようにプロセスが透過的で、たとえばリクエスト -> Nginx -> Tomcat の場合、Tomcat の場合、リクエストされた IP アドレスは実際のリクエスト アドレスではなく、Nginx アドレスであることに注意する必要があります。幸いなことに、Nginx はリバース プロキシ リクエストだけでなく、ユーザーによるHTTP ヘッダーのカスタマイズもできます。
負荷分散【上流】
上記のリバース プロキシでは、proxy_pass を使用して Tomcat アドレスを指定していますが、明らかに Tomcat アドレスは 1 つしか指定できませんが、負荷分散を実現するために複数の Tomcat アドレスを指定したい場合はどうすればよいでしょうか?
まず、アップストリームを通じて Tomcat のグループを定義し、負荷戦略 (IPHASH、重み付き引数、最小接続数)、ヘルス チェック戦略 (Nginx はこの Tomcat グループのステータスを監視できます) などを指定します。
次に、proxy_pass を上流で指定された値に置き換えます。
負荷分散によってどのような問題が発生する可能性がありますか?
負荷分散によって引き起こされる明らかな問題は、リクエストがサーバー A またはサーバー B に送信される可能性があることであり、これは完全に制御不能です。もちろん、これは問題ではありませんが、注意しなければならないのは、ユーザーのステータスです。セッション情報などの保存に関する問題はサーバーに保存できません。
キャッシュ
キャッシュとはNginxが提供するアクセスを高速化する仕組みで、端的に言うとこれを有効にしてディレクトリを指定してディスク上にキャッシュを保存する設定になります。特定の構成については、Nginx の公式ドキュメントを参照してください。ここでは詳しく説明しません。
最近、非常に詳細な関連記事をいくつか見ました。もっと詳しく知りたい場合は、見てみることができます。