アーキテクチャ設計: ロードバランシングレイヤの設計計画 (8) - ロードバランシングレイヤの概要パート 1-PHPチュートリアル-php.cn

1. 概要

明らかに、これまでの 8 つの記事の紹介で負荷分散層のすべてのテクノロジをカバーすることはできませんが、負荷分散テクノロジを学習および使用するためのアイデアを読者に伝えるための入門として使用できます。「ビジネス層」と「ビジネスコミュニケーション」層の導入については後ほど説明しますが、負荷分散層の導入は止まりません。フォローアップ時間では、Nginx テクノロジーの再紹介、HaProxy、LVS などの新しい使用シナリオを含む、負荷分散レイヤーに関する新しい記事のリリースを散りばめます。

この記事では、読者が新しい学習アイデアを見つけられるように、これまでの知識ポイントを要約し、意図的に拡張しています。

2. 負荷分散層の基本的な考え方

2-1. 一貫性のあるハッシュとキーの選択

アーキテクチャ設計: ロードバランシングレイヤの設計計画 (8) - ロードバランシングレイヤの概要パート 1

記事「アーキテクチャ設計: 負荷分散層の設計計画 (2) - Nginx のインストール」では、一貫性のあるハッシュアルゴリズムが詳細に紹介されています。また、一貫性のあるハッシュアルゴリズムは現代のシステムアーキテクチャにおいて最も重要なアルゴリズムの 1 つであり、分散コンピューティングシステム、分散ストレージシステム、データ分析などの多くの分野で広く使用されていることも強調しました。私のブログ投稿の場合、これは負荷分散層、ビジネス通信層、データストレージ層にあります。

コンセンサスアルゴリズムの中核は次のとおりです:

オブジェクトの特定の属性を使用します (この属性には、サーバーの IP アドレス、オープンポート、ユーザー名、ある種の暗号化された文字列を使用できます。考えられるすべてのもの) of はハッシュを意味する性質を持っています)、0から2の32乗の範囲に分布するように整数を計算します。
もちろん、サーバーの 1 つ以上の属性をハッシュして計算し、計算に従ってリング上の特定の点 (写真のリング上の青い点) に分散することもできます。
処理リクエストが来ると、そのリクエストの1つまたはいくつかの属性に基づいてハッシュ計算が行われ、その計算に基づいてリング上の一定のポイントにデメリットが振り分けられます。上の写真の円の中にある黄色い点がそれです。
特定の青い点 A の左側と青い点 B の右側の黄色の点で表されるリクエストは、青い点 A で表されるサーバーによって処理されることに同意します。これで、「誰が処理するか」に対する解決策が完了します。 " 質問。青いドットが安定して存在するという前提の下では、同じハッシュ規則からのリクエストはすべて同じ位置に分類され、サービス処理マッピングの安定性が保証されます。
特定の青色のポイントが何らかの理由でオフラインになると、影響を受ける黄色のポイントの数も制限されます。つまり、次のクライアント要求は、他の青い点で表されるサーバーによって処理されます。

2-2. ポーリングと重み付け

アーキテクチャ設計: ロードバランシングレイヤの設計計画 (8) - ロードバランシングレイヤの概要パート 1

重み付けされていないポーリングは、メイン制御ノード (タスクソースポイント) がターゲットノード (CPU パフォーマンス、ディスクパフォーマンスなど)、ネットワークの要素を考慮しないことを意味します。パフォーマンス)、タスクはターゲットノードのリストの順序に従って順番に割り当てられます。これは最も単純なポーリングであり、マスターノードでの実装の複雑さが最も少なくて済みます。私の以前のブログ投稿「アーキテクチャ設計: ロードバランシングレイヤの設計計画 (2) - Nginx のインストール」と「アーキテクチャ設計: ロードバランシングレイヤの設計計画 (4) - LVS の原則」ではすべて、この最も単純なポーリングを紹介しました。たとえば、「rr」 LVS のパラメータ。
加重投票における「権利」は、「投票」の基礎とみなすことができます。「重み」にはさまざまな可能性があり、ターゲットマシンのパフォーマンスを定量化した値、固定数 (固定数に従って重み付け)、またはターゲットノードのネットワーク速度にすることができます。たとえば、LVS の「lc」パラメータは、ターゲットマシン上の既存の「接続」の数に応じて重み付けされます。接続の数が少ないほど、このタスクの処理権限を取得できる可能性が高くなります。

2-3. リースとヘルスチェック

アーキテクチャ設計: ロードバランシングレイヤの設計計画 (8) - ロードバランシングレイヤの概要パート 1

リース契約は主に、クライアント上でのサーバーのチェック操作が「最新時間」後に失敗した場合にサーバーが確実にログアウトすることを保証することを目的としています。クライアントのログイン情報、クライアント上のサーバーの接続情報も消えます（下位へのサービスも提供されなくなります）。チェックが成功するたびに、この「最新の時刻」は後ろに押し戻されます。

リース契約は、前述したハッシュアルゴリズムと同じであり、システムアーキテクチャ設計における最も基本的な設計概念であり、その動作原理はすべてのアーキテクトが習得する必要があるものです。たとえば、Zookeeper はこのプロトコルを使用して、フローノードとリーダーノード間のリンクが正常であることを確認します。分散ストレージシステムは、このプロトコルを使用してデータノードとネームノード間の接続が正常であることを確認します。前回のロードバランシングレイヤーテクノロジー

このブログ投稿では、Nginx、LVS、および Keepalived テクノロジーに焦点を当てました。時間が限られているため、ここではブログ投稿で言及されているいくつかのテクノロジーを要約し、その後、DNS テクノロジー、CDN テクノロジー、およびハードウェア負荷テクノロジーについても紹介します。

3-1、Nginxテクノロジー

在负载均衡层这个大的章节中，我有三篇文章都在直接介绍Nginx的原理和使用。但是之后有朋友给我反映还想了解更多的Nginx知识，特别点名要求我再做一篇文章介绍Nginx的动态缓存。是的，我在后面的时间里是有计划介绍Nginx的动态缓存技术，还会介绍Nginx和多款主流的反向代理软件的性能对比。但这需要时间，特别是我不想去网上找一些已有的性能对比图，还是自己一边做这样的性能测试，一边做性能报告比较靠谱。

下面这些技术是我在博文中已经重点介绍过得，我们再做一下总结：

Nginx中的连接数限制问题

重要的配置项包括：worker_processes、worker_connections。但是光是配置这些属性是不够的，最关键的是我们要打开操作系统级别的“最大文件数”限制问题。使用“ulimit -n 65535”设置本次会话的“最大文件数”限制；还要使用“vim /etc/security/limits.conf”命令，修改内核的配置信息。主要是以下两项：

<code><span>* </span>soft nofile 65535 
<span>* </span>hard nofile 65535</code>

ログイン後にコピー

另外，还要注意和nginx配置项中的“worker_rlimit_nofile”属性共同使用：

<code>user root root; 
worker_processes <span>4</span>; 
worker_rlimit_nofile <span>65535</span>;

<span>#error_log logs/error.log; </span><span>#error_log logs/error.log notice; </span><span>#error_log logs/error.log info;</span><span>#pid logs/nginx.pid; </span>
events { 
    use epoll; 
    worker_connections <span>65535</span>; 
}</code>

ログイン後にコピー

Nginx中的Gzip技术

gzip是Nginx进行HTTP Body数据压缩的技术。下面这段Nginx配置信息是启用gzip压缩的实例：

<code><span>#开启gzip压缩服务， </span>
gzip <span><span>on</span></span>;

<span>#gzip压缩是要申请临时内存空间的，假设前提是压缩后大小是小于等于压缩前的。例如，如果原始文件大小为10K，那么它超过了8K，所以分配的内存是8 * 2 = 16K;再例如，原始文件大小为18K，很明显16K也是不够的，那么按照 8 * 2 * 2 = 32K的大小申请内存。如果没有设置，默认值是申请跟原始数据相同大小的内存空间去存储gzip压缩结果。 </span>
gzip_buffers <span>2</span><span>8</span>k;

<span>#进行压缩的原始文件的最小大小值，也就是说如果原始文件小于5K，那么就不会进行压缩了 </span>
gzip_min_length <span>5</span>K;

<span>#gzip压缩基于的http协议版本，默认就是HTTP 1.1 </span>
gzip_http_version <span>1.1</span>;

<span># gzip压缩级别1-9，级别越高压缩率越大，压缩时间也就越长CPU越高 </span>
gzip_comp_level <span>5</span>;

<span>#需要进行gzip压缩的Content-Type的Header的类型。建议js、text、css、xml、json都要进行压缩；图片就没必要了，gif、jpge文件已经压缩得很好了，就算再压，效果也不好，而且还耗费cpu。 </span>
gzip_types <span>text</span>/HTML <span>text</span>/plain <span>application</span>/x-javascript <span>text</span>/css <span>application</span>/xml;</code>

ログイン後にコピー

http返回数据进行压缩的功能在很多场景下都实用：

a、如果浏览器使用的是3G/4G网络，那么流量对于用户来说就是money。

b、压缩可节约服务器机房的对外带宽，为更多用户服务。按照目前的市场价良好的机房带宽资源的一般在200RMB/Mbps，而服务器方案的压力往往也来自于机房带宽。

c、不是Nginx开启了gzip功能，HTTP响应的数据就一定会被压缩，除了满足Nginx设置的“需要压缩的http格式”以外，客户端（浏览器）也需要支持gzip（不然它怎么解压呢），一个好消息是，目前大多数浏览器和API都支持http压缩。

Nginx中的rewrite（重写）技术

Nginx的强大在于其对URL请求的重写（重定位）。Nginx的rewrite功能依赖于PCRE Lib，请一定在Nginx编译安装时，安装Pcre lib。

Nginx的rewrite功能在我《架构设计：负载均衡层设计方案（3）——Nginx进阶》这边博客中进行了讲解。

下面是一段rewrite的示例：

<code><span>#示例1：</span>
location ~* ^<span>/(.+)/</span>(.+)\.(jpg|gif|png|jpeg)<span>$ </span>{
    rewrite ^<span>/orderinfo/</span>(.+)\.(jpg|gif|png|jpeg)<span>$ </span>  /img/<span>$1</span>.<span>$2</span><span>break</span>;
    root   /cephclient;
}

<span>#location在不进行大小写区分的情况下利用正则表达式对$url进行匹配。当匹配成功后进行rewrite重定位。</span><span>#rewrite进行重写url的规则是：regex表达式第一个括号中的内容对应$1，regex表达式第二个括号中的内容对应$2，以此类推。</span><span>#这样重定位的意义就很明确了：将任何目录下的文件名重定位到img目录下的对应文件名，</span><span>#并且马上在这个location中（注意是Nginx，而不是客户端）执行这个重写后的URL定位。</span><span>#示例2：</span>
server {
    。。。。
    。。。。
    location ~* ^<span>/orderinfo/</span>(.+)\.(jpg|gif|png|jpeg)<span>$ </span>{
        rewrite ^<span>/orderinfo/</span>(.+)\.(.+)<span>$ </span> /img/<span>$1</span>.<span>$2</span>   last;
    }

    location / {
        root   /cephclient;
    }
}

<span>#在server中，有两个location位置，当url需要访问orderinfo目录下的某一个图片时，rewrite将重写这个url，</span><span>#并且重新带入这个url到server执行，这样“location /”这个location就会执行了，并找到图片存储的目录。</span></code>

ログイン後にコピー

Nginx的图片处理模块

http_image_filter_module 是nginx的图片处理模块，是使用nginx进行静态资源和动态资源分开管理的关键引用技术。通过这个模块可以对静态资源进行缩放、旋转、验证。

需要注意的是，http_image_filter_module模块所处理的缩率图片是不进行保存的，完全使用节点的CPU性能进行计算，使用节点的内存进行临时存储。所以如果要使用http_image_filter_module进行图片处理，一定要根据客户端的请求规模进行nginx节点的调整。并且当站点的PV达到一定的规模时，一定要使用CDN技术进行访问加速、对图片的访问处理手段进行规划。

由于我们在之前涉及Nginx的文章中，并没有详细讲解Nginx的图片处理模块，只是说了要进行介绍，所以这里我给出一个较为详细的安装和配置示例：

nginx的http_image_filter_module模块由GD library进行支持，所以要使用这个图片处理模块，就必须进行第三方依赖包的安装：

<code>yum <span>install</span> gd-devel</code>

ログイン後にコピー

然后，Nginx要进行重新编译：

<code>configure <span>--</span><span>with</span><span>-http_image_filter_module</span>
make <span>&&</span> make install</code>

ログイン後にコピー

使用图片处理模块的配置示例：

<code>location ~* /(.+)_(\d+)_(\d+)\.(jpg|gif|png|ioc|jpeg)$ {
    <span>set</span><span>$h</span><span>$3</span>;
    <span>set</span><span>$w</span><span>$2</span>;
    rewrite /(.+)_(\d+)_(\d+)\.(jpg|gif|png|ioc|jpeg)$ /<span>$1</span>.<span>$4</span><span>break</span>;

    image_filter resize <span>$w</span><span>$h</span>;
    image_filter_buffer <span>2</span>M;
}</code>

ログイン後にコピー

其中关于正则表达式的语法和已经介绍过的rewrite的语法就不再进行介绍了，主要看http_image_filter_module相关的属性设置：

image_filter test：测试图片文件合法性
image_filter rotate：进行图片旋转，只能按照90 | 180 | 270进行旋转
image_filter size：返回图片的JSON数据
image_filter resize width height：按比例进行图片的等比例缩小，注意，是只能缩小，第二缩小是等比例的。
image_filter_buffer：限制图片最大读取大小，没有设置就是1M；根据不同的系统最好设置为2M—3M
image_filter_jpeg_quality：设置jpeg图片的压缩比例（1-99，越高越好）
image_filter_transparency：禁用gif和png图片的透明度。

和Nginx类似的其他技术/软件

目前行业内也有很多与Nginx解决同类问题的软件，他们分别是Apache基金会的 Apache HTTP Server、淘宝开源的Tengine、Haproxy、包括Windows 下运行的IIS，也支持反向代理。

这里笔者再次重点提到Tengine，建议各位读者有时间的时候可以使用一下，这个对Nginx进行了深度再开发的软件。

3-2、LVS技术

LVSとはLinux Virtual Serverの略で、Linux仮想サーバーのことです。仮想サーバークラスタシステムです。このプロジェクトは、1998 年 5 月に張文松博士によって設立されました。

LVS クラスターは、IP 負荷分散テクノロジーとコンテンツベースのリクエスト分散テクノロジーを採用しています。スケジューラは非常に優れたスループットレートを備え、実行のためにリクエストをさまざまなサーバーに均等に転送します。スケジューラはサーバーの障害を自動的に保護し、サーバーのグループを高性能で可用性の高い仮想サーバーに形成します。サーバークラスター全体の構造はクライアントに対して透過的であり、クライアントとサーバーのプログラムを変更する必要はありません。

一連の記事では、「アーキテクチャ設計: ロードバランシングレイヤの設計計画 (4) - LVS の原則」、「アーキテクチャ設計: ロードバランシングレイヤの設計計画 (5) - LVS シングルノードのインストール」、「ロードバランシングレイヤの設計計画」 (7) - LVS + Keepalived + Nginx のインストールと設定」には、LVS の説明が含まれています。

ここでは、LVS の 3 つの動作モードを要約します:

3-2-1、NAT モード

NAT モードは、LVS マスターサービスノードによって受信され、下位のリアルサーバーノードに転送されるデータグラムです。処理が完了すると、それを LVS マスターノードに送り返し、LVS マスターノードによって転送します。 LVS 管理プログラム IPVSADMIN は、転送ルールをバインドし、IP データパケットと TCP データパケットの属性の書き換えを完了する役割を果たします。

アーキテクチャ設計: ロードバランシングレイヤの設計計画 (8) - ロードバランシングレイヤの概要パート 1

LVS-NAT モードの利点は次のとおりです:

シンプルな構成と管理。 LVS-NAT の動作モードは、LVS の 3 つの動作モードの中で最も理解しやすく、設定し、管理しやすいものです。
外部ネットワーク IP リソースを節約します。一般に、特に購入するラックの数が多くない場合、コンピュータールームのユーザーに割り当てられる IP の数は制限されます。 LVS-NAT は、LAN 内にシステムアーキテクチャをカプセル化することで機能します。LVS は、アクセスを実現するために外部ネットワークアドレスまたは外部ネットワークアドレスマッピングのみを必要とします。
システムアーキテクチャは比較的閉鎖的です。イントラネット環境では、ファイアウォール設定に対する高度な要件はなく、物理サーバーの運用と保守が比較的容易です。外部ネットワークからのリクエストがファイアウォールによってフィルタリングされるように設定し、内部ネットワークからのリクエストにはアクセスできるようにすることができます。
さらに、リアルサーバーは、TCP検証とIP検証に合格できる限り、リアルサーバーに転送される書き換えられたデータメッセージの信頼性を気にしません。したがって、LVS-NAT 動作モードの実サーバーは、TCP/IP プロトコルをサポートしている限り、どのオペレーティングシステムでも使用できます。

3-2-2、DR モード

LVS の DR 動作モードは、実稼働環境で最もよく使用される動作モードです。また、インターネット上には、DR 動作モードについて説明されている記事もあります。より詳しく:

アーキテクチャ設計: ロードバランシングレイヤの設計計画 (8) - ロードバランシングレイヤの概要パート 1

LVS-DR モードの利点は次のとおりです:

LVS-NAT 動作モードでの転送ボトルネック問題を解決し、より大規模な負荷分散シナリオをサポートできます。
コンピュータ室の外部 IP リソースが制限されている場合、LVS-NAT と LVS-DR を併用することで問題を軽減できます。

もちろん、LVS-DR には欠点もあります:

設定作業は LVS-NAT 方式よりも少し面倒です。より適切に行うには、少なくとも LVS-DR モードの基本的な動作方法を理解する必要があります。 LVS-DR モードでの設定および操作中に発生する問題のトラブルシューティングをガイドします。
LVS-DR モードのメッセージ書き換えルールにより、レイヤー 2 スイッチングはサブネットを越えることができないため、LVS ノードとリアルサーバーノードは同じネットワークセグメント内に存在する必要があります。しかし、実際には、この問題には、ほとんどのシステムアーキテクチャソリューションにとって本質的な制限はありません。

3-2-3、TUNモード

LVS-DRモードとLVS-TUNモードの動作原理は完全に異なり、動作シナリオも完全に異なります。 DR はデータパケットの書き換えに基づいており、TUN モードは IP トンネリングに基づいています。後者はデータパケットの再カプセル化です:

アーキテクチャ設計: ロードバランシングレイヤの設計計画 (8) - ロードバランシングレイヤの概要パート 1

IPIP トンネル。完全な IP メッセージを別の新しい IP メッセージのデータ部分にカプセル化し、ルーターを介して指定された場所に送信します。このプロセスでは、ルーターはカプセル化されている元のプロトコルの内容を気にしません。宛先に到着した後、宛先は自身の計算能力と IPIP トンネルプロトコルのサポートに依存して、カプセル化プロトコルを開いて元のプロトコルを取得します。

アーキテクチャ設計: ロードバランシングレイヤの設計計画 (8) - ロードバランシングレイヤの概要パート 1

LVS-TUN 方式は基本的に、 LVS-DRの利点。これに基づいて、サブネット間の侵入もサポートします。

3-3、CDN テクノロジー

CDN テクノロジー Content Delivery Network: コンテンツ配信ネットワーク。インターネット上のビデオリソースや画像リソースへのアクセスが時々遅くなったり、失敗したりするのはなぜでしょうか。重要な理由の 1 つは、リソースの物理的な場所がクライアントから遠すぎるため、レイヤー 4 NAT デバイス (通信サーバー上のリソースにアクセスするために Netcom 回線を使用するのと同等) が存在する可能性があることです。

アクセスしたいリソースがクライアントに最も近いサービスに配置されている場合を想像してみましょう (たとえば、広州のクライアントがアクセスするリソースは広州のコンピューター室にあります)。これで問題は解決します (この点は「エッジノード」と呼ばれます)。以下の図に示すように、これが CDN ネットワークによって解決される問題です。

アーキテクチャ設計: ロードバランシングレイヤの設計計画 (8) - ロードバランシングレイヤの概要パート 1

現在、CDN サービスを開発する必要はありません。市場には無料/有料の CDN サービスを提供する企業が多数あります (入力してください)。 Google または Baidu : CDN に直接アクセスすると、多くの「プロモーション」情報が表示されますが、私のブログには広告はありません ^_^)。もちろん、自分で CDN ネットワークを構築したい場合は、次の技術ソリューションを参照できます:

Squid: Squid は、ユーザーからのダウンロード要求を受信し、ダウンロードされたデータを自動的に処理するソフトウェアです。現在、国内の多くの CDN サービスプロバイダーのネットワークは Squid に基づいて構築されています

Nginx の proxy_cache を使用して構築されており、Nginx の書き換え技術は実際に URL リクエストの書き換えとリクエストの転送を実現できます。 Nginxのproxy_cacheコンポーネントは、リモートエンドから要求されたソースデータをローカルに保存することでCDNネットワークの構築を実現します。

自分で作成する: CDN ネットワークには特に複雑な技術的しきい値はありません。特別なニーズがある場合は、自分で作成できます。もちろん、上の図で紹介されている CDN ネットワークは、第 1 世代の CDN ネットワークに属します。CDN 原理に第 2/第 3 世代の P2P テクノロジーを追加すると、次の図に示すように第 2 世代の CDN ネットワークを形成できます。

ハイブリッド P2P テクノロジーとしても知られる第 3 世代の P2P テクノロジーは、主にメタデータサーバーの処理圧力を解決し、リソースのローカリゼーションを加速するように設計されています。 P2P技術については、「ビジネスシステム設計」と「ビジネスコミュニケーションシステム設計」の話を終えた後、新たにトピックを立てて紹介したいと思います。さらに、YouTube の P2P ネットワークは独自に構築されていることにも言及したいと思います。

アーキテクチャ設計: ロードバランシングレイヤの設計計画 (8) - ロードバランシングレイヤの概要パート 1 4. 後ほど紹介