아키텍처 설계: 로드 밸런싱 계층 설계 계획(8) - 로드 밸런싱 계층 요약 1부

1. 개요

물론 앞의 8개 기사의 소개가 로드 밸런싱 레이어의 모든 기술을 다룰 수는 없지만 독자들에게 학습 방법을 알려주는 소개로 사용할 수 있습니다. 로드 밸런싱 기술을 사용합니다. 나중에 "비즈니스 계층"과 "비즈니스 커뮤니케이션" 계층에 대한 소개를 다루겠지만, 로드 밸런싱 계층의 도입은 멈추지 않을 것입니다. 후속 시간에는 Nginx 기술 재도입, HaProxy, LVS 등의 새로운 사용 시나리오를 포함하여 로드 밸런싱 계층에 대한 새로운 기사를 게재할 예정입니다.

이 글에서는 독자들이 새로운 학습 아이디어를 찾을 수 있도록 이전 지식 포인트를 요약하고 의도적으로 확장합니다.

2. 로드 밸런싱 레이어의 핵심 아이디어

2-1. 일관된 해싱 및 키 선택

" 아키텍처" 설계: 로드 밸런싱 계층 설계 계획(2) - Nginx 설치" 이 기사에서는 일관된 해싱 알고리즘을 자세히 소개합니다. 또한 일관된 해시 알고리즘은 현대 시스템 아키텍처에서 가장 중요한 알고리즘 중 하나이며 분산 컴퓨팅 시스템, 분산 스토리지 시스템, 데이터 분석 등 많은 분야에서 널리 사용된다는 점을 강조했습니다. 내 블로그 게시물의 경우 로드 밸런싱 레이어, 비즈니스 커뮤니케이션 레이어, 데이터 스토리지 레이어에서 찾을 수 있습니다.

합의 알고리즘의 핵심은 다음과 같습니다.

• 객체의 특정 속성을 사용합니다(이 속성은 서버의 IP 주소, 열린 포트, 사용자 이름, 일종의 암호화된 문자열입니다. 해싱 중요성이 있다고 생각할 수 있는 모든 속성), 0에서 2의 32승 범위에 분포되도록 정수를 계산합니다.
• 물론 서버의 하나 이상의 속성도 해싱될 수 있으며, 계산에 따라 링의 특정 지점(사진 속 링의 파란색 지점)에 분산됩니다.
• 처리 요청이 오면 요청의 하나 또는 일부 속성을 기반으로 해시 계산이 수행되고, 계산에 따라 링의 특정 지점에 단점이 분배됩니다. 위 사진의 원에 있는 노란색 점입니다.
• 특정 파란색 점 A의 왼쪽과 파란색 점 B의 오른쪽에 있는 노란색 점으로 표시되는 요청은 파란색 점 A로 표시되는 서버에서 처리된다는 데 동의합니다. 이로써 "누가?"에 대한 솔루션이 완성됩니다. 문제'를 다루게 된다. 파란색 점이 안정적으로 존재한다는 전제 하에 동일한 Hash 규칙의 요청은 모두 동일한 위치에 위치하므로 서비스 처리 매핑의 안정성이 보장됩니다.
• 파란색 포인트가 어떤 이유로 오프라인 상태가 되면 영향을 받는 노란색 포인트의 수도 제한됩니다. 즉, 다음 클라이언트 요청은 다른 파란색 점으로 표시된 서버에서 처리됩니다.

2-2. 폴링 및 가중치

• 비가중 폴링은 마스터 노드(태스크 소스 포인트)를 고려하지 않음 대상 노드의 모든 요소(CPU 성능, 디스크 성능, 네트워크 성능 등)에 따라 대상 노드의 목록 순서에 따라 작업이 순차적으로 할당됩니다. 이는 가장 간단한 폴링이며 마스터 노드에서 구현 복잡성이 가장 적게 필요한 폴링입니다. 내 이전 블로그 게시물 "아키텍처 디자인: 로드 밸런싱 레이어 디자인 계획 (2) - Nginx 설치" 및 "아키텍처 디자인: 로드 밸런싱 레이어 디자인 계획 (4) - LVS 원칙"은 모두 다음과 같은 간단한 폴링을 소개했습니다. 예를 들어 "rr" LVS의 매개변수.

• 가중투표에서 '권리'는 '투표'의 기본이라고 생각하면 된다. "가중치"는 많은 가능성이 있을 수 있으며, 대상 머신의 성능 정량화 값일 수도 있고, 고정된 숫자(고정된 숫자에 따라 가중치가 부여됨)일 수도 있고, 대상 노드의 네트워크 속도일 수도 있습니다. 예를 들어, LVS의 "lc" 매개변수는 대상 컴퓨터의 기존 "연결" 수에 따라 가중치가 부여됩니다. 연결 수가 적을수록 이 작업에 대한 처리 권한을 얻을 가능성이 커집니다.

2-3. 임대 및 상태 점검

임대 계약은 주로 서버에서 클라이언트 "최근 시간"이 실패하면 서버는 반드시 클라이언트의 로그인 정보를 로그아웃하고 클라이언트의 서버 연결 정보도 사라지게 됩니다(더 이상 서비스를 제공하지 않습니다). 확인이 성공할 때마다 이 "최근 시간"이 뒤로 밀려납니다.

임대 계약은 앞서 언급한 해시 알고리즘과 동일하며 시스템 아키텍처 설계에 있어 가장 기본적인 설계 아이디어이며 다양한 유형의 시스템에서 널리 사용됩니다. 그 작동 원리는 모든 건축가에게 중요합니다. 모두 마스터해야 합니다. 예를 들어, Zookeeper는 이 프로토콜을 사용하여 Flow 노드와 Leader 노드 간의 연결이 정상적인지 확인합니다. 분산 저장 시스템은 이 프로토콜을 사용하여 데이터 노드와 namenode 간의 연결이 정상적인지 확인합니다. 3. 로드밸런싱 레이어 기술 요약

이전 블로그 포스팅에서는 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 가상 서버를 의미합니다. 이 프로젝트는 Zhang Wensong 박사가 1998년 5월에 설립했습니다.

LVS 클러스터는 IP 로드 밸런싱 기술과 콘텐츠 기반 요청 분산 기술을 채택하고 있습니다. 스케줄러는 처리 속도가 매우 좋고 요청을 다른 서버로 균등하게 전송하여 실행하며, 스케줄러는 서버 장애를 자동으로 보호하여 서버 그룹을 고성능, 고가용성 가상 서버로 구성합니다. 전체 서버 클러스터의 구조는 클라이언트에 투명하며 클라이언트 및 서버 프로그램을 수정할 필요가 없습니다.

제가 쓴 시리즈 기사 중 "아키텍처 디자인: 로드 밸런싱 레이어 디자인 계획(4) - LVS 원리", "아키텍처 디자인: 로드 밸런싱 레이어 디자인 계획(5) - LVS 단일 노드 설치", "로드 밸런싱 레이어 설계 계획(7) - LVS Keepalived Nginx 설치 및 구성"에는 모두 LVS에 대한 설명이 포함됩니다.

여기서는 LVS의 세 가지 작업 모드를 요약합니다.

3-2-1, NAT 모드

NAT 모드는 LVS 마스터 서비스 노드가 데이터그램을 수신하는 방식입니다. 그런 다음 하위 Real Server 노드로 전달됩니다. Real Server가 처리를 완료하면 LVS 마스터 노드로 다시 전송된 다음 LVS 마스터 노드에 의해 전달됩니다. LVS 관리 프로그램 IPVSADMIN은 전달 규칙을 바인딩하고 IP 데이터 패킷과 TCP 데이터 패킷의 속성 다시 쓰기를 완료하는 역할을 합니다.

LVS-NAT 모드의 장점은 다음과 같습니다.

• 간단한 구성 및 관리. LVS-NAT의 작업 모드는 LVS의 세 가지 작업 모드 중에서 가장 이해하기 쉽고, 구성하기 쉽고, 관리하기 가장 쉽습니다.

• 외부 네트워크 IP 자원을 절약하세요. 일반적으로 전산실에서 사용자에게 할당되는 IP 수는 제한되어 있으며, 특히 구매하는 랙 수가 많지 않은 경우 더욱 그렇습니다. LVS-NAT는 LAN에서 시스템 아키텍처를 캡슐화하여 작동합니다. LVS는 액세스를 위해 외부 네트워크 주소 또는 외부 네트워크 주소 매핑만 필요합니다.

• 시스템 아키텍처가 상대적으로 폐쇄적입니다. 인트라넷 환경에서는 방화벽 설정에 대한 요구 사항이 높지 않으며 물리적 서버를 운영하고 유지 관리하는 것이 상대적으로 쉽습니다. 외부 네트워크의 요청은 방화벽에 의해 필터링되고 내부 네트워크의 요청은 액세스 가능하도록 설정할 수 있습니다.

• 또한 Real Server는 TCP 검증과 IP 검증을 통과할 수 있는 한, Real Server로 다시 작성되어 전송되는 데이터 패킷의 신뢰성에 대해 신경 쓰지 않습니다. 실제 서버를 처리할 수 있습니다. 따라서 LVS-NAT 작업 모드의 실제 서버는 TCP/IP 프로토콜을 지원하는 한 모든 운영 체제가 될 수 있습니다.

3-2-2. DR 모드

LVS의 DR 작업 모드는 현재 프로덕션 환경에서 가장 일반적으로 사용되는 작업 모드이며, 예, 일부 기사에서는 DR 작업 모드에 대해 매우 자세히 설명합니다.

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 터널링을 기반으로 합니다. 후자는 데이터 패킷의 재캡슐화입니다.

IPIP 터널입니다. 완전한 IP 메시지를 또 다른 새로운 IP 메시지의 데이터 부분에 캡슐화하여 라우터를 통해 지정된 위치로 전송합니다. 이 프로세스에서 라우터는 캡슐화되는 원래 프로토콜의 내용에 신경 쓰지 않습니다. 목적지에 도착한 후 목적지는 자체 컴퓨팅 성능과 IPIP 터널 프로토콜 지원에 의존하여 캡슐화 프로토콜을 열고 원본 프로토콜을 얻습니다.

LVS-TUN 방식은 기본적으로 LVS-DR의 장점을 갖고 있다고 합니다. 이를 기반으로 서브넷 간 침투도 지원합니다.

3-3. CDN 기술

CDN 기술 콘텐츠 전송 네트워크(Content Delivery Network): 콘텐츠 유통 네트워크. 인터넷의 비디오 리소스 및 사진 리소스에 대한 액세스가 때때로 느리거나 심지어 실패하는 이유는 무엇입니까? 한 가지 중요한 이유는 리소스의 물리적 위치가 클라이언트에서 너무 멀고 계층 4 NAT 장치(통신 서버의 리소스에 액세스하기 위해 Netcom 회선을 사용하는 것과 동일)가 있을 수 있다는 것입니다.

우리가 액세스하려는 리소스가 클라이언트와 가장 가까운 서비스에 배치되어 있다고 가정해 보겠습니다. 예를 들어 광저우에서 클라이언트가 액세스하는 리소스는 광저우의 컴퓨터실에 있습니다. 그러면 문제가 해결됩니다(이 지점을 "에지 노드"라고 함). 이것이 바로 CDN 네트워크가 해결하는 문제입니다. 아래 그림과 같습니다.

현재 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 기술에 관해서는 "비즈니스 시스템 설계"와 "비즈니스 커뮤니케이션 시스템 설계"에 대한 이야기를 마친 후 새로운 주제를 만들어 소개하겠습니다. 그리고 유튜브의 P2P 네트워크는 자체적으로 구축되어 있다는 점을 말씀드리고 싶습니다.

4.나중에 소개

요약할 내용이 너무 많아 "아키텍처 설계: 로드 밸런싱 레이어 설계 계획(9) - 로드 밸런싱 레이어 다음 기사 요약"이라는 글을 하나 더 열기로 했습니다. ", 로드 밸런싱 계층 기술을 계속해서 요약합니다. Keepalived, DNS 기술, 하드웨어 로드를 요약하고 더 폭넓은 로드 밸런싱 기술을 소개하겠습니다.