网站架构拓展和haproxy

一、网站架构整体剖析和扩展

CDN加速只针对静态资源，主要是图片和视频。

用户通过微信、浏览器等接入网络，可能会直接访问CDN，也可能通过防火墙或SSL（VPN认证，jumpserver认证等）连接到接入层，

接入层有API网关、VPN、jumpserver、负载均衡LVS、haproxy等。（habor是打镜像仓库的），

web服务层主要是静态资源服务器（jetty即可做静态也可做动态服务器）；业务服务层只要是动态资源服务器（Dubbo是做微服务的）；

中间件层不是必须的，可做可不做，目的是优化网站访问速度，比如redis是给mysql做缓存的，不用必须访问mysql,可直接访问redis，减轻后端mysql的I/O压力。（memcached也是给数据库做缓存，kafka、RabbitMQ是做消息队列的，消息队列的是异步、削峰、解耦）

Zookeeper是做API间注册的，mycat做数据库解耦的；数据库层（Mysql和PostgreSQL是做关系型数据库的，mogodb是做文档数据库，redis是做数据库缓存的）；存储层基于nfs、cifs、ftp三大协议来实现，最流行的是OSS对象存储，它的特点是基于restful（将文件的传输网页化，走http协议），所以DAS NAS

SAN走的是三大主流协议（nfs、cifs、ftp），而对象存储OSS走的是http协议。

基础架构：真实物理机、KVM虚拟机（类似vmware worksation）、openstack做的是Iaas基础设施及服务，是主流的公有云厂商的一种虚拟化解决方案 ，以IaaS为主提供一些虚拟服务。vSphere是对VMware的虚拟机做编排，而openstack是对KVM的虚拟机做编排。公有云（例如阿里云），docker容器没有自己的操作系统，是用的宿主的，在一个宿主机上有多个容器就可以跑多个服务。docker-cpmpose是单机容器编排，多机容器编排是K8S。网络层：路由、交换、VLAN、TCP/IP等。

公有云：IaaS提供基础资源、PaaS提供一下基本服务的资源、SaaS费用高，一步到位

非数据部分：接入层、web服务层、业务服务层、中间件层、数据库层

消息中间件削峰、异步、解耦

OpenStack：基于KVM实现的产品；vSphere:基于VMware实现的产品

 

1.网站架构扩展思路

web_app_server--->cache_server--->SQL(包括nosql)

web_static_server_---> 动静分离、共享存储 --->分布式存储 --->缓存（CDN技术）

搜索引擎服务器（基于爬虫和算法、通常会结合大数据技术做分析）

负载均衡器（必要时要降低冗余，以双主模式存在、提升效率）

防火墙

DNS解析调度，在另一层次提升网站架构的负载能力。

非数据部分：接入层、web服务层、业务服务层、中间件层、数据库层

消息中间件削峰、异步、解耦 

OpenStack：基于KVM实现的产品；vSphere:基于VMware实现的产品

2.优化

网站优化：

服务器参数性能优化（包括网络、带宽优化）

web优化

①：访问响应优化

②：页面性能优化（带宽、网页静态资源管理、首屏加载优化方案、压缩）

③：安全优化（传输加密解密机制）

非结构化数据机制优化

    ①共享存储  NFS  SAMBA  NAS  DAS  SAN  ISCIS

补充：非结构化数据（键值存储）、半结构化数据（xml、elk）、

数据库优化

    ①：索引优化

    ②：参数优化

    ③：处理机制优化和数据库存储性能优化（数据库缓存机制、读写分离、主从复制、数据库高可用方案）

3.LB、HA相关机制优化

为什么使用负载均衡？

①增加业务并发访问及处理能力-->解决单服务器瓶颈问题（单点故障、性能故障）

②节约公网IP地址-->降低IT支出成本

③隐藏内部服务器IP-->提高内部服务器安全性

④Web服务器的动态水平扩展-->对用户无感知

⑤负载均衡配置简单-->固定格式的配置文件

⑥负载均衡功能丰富-->支持四层和七层，支持动态下线主机

⑦负载均衡性能较强-->并发数万甚至百万

 负载均衡架构图原理：

 动态资源也会作缓存，调用数据库中的缓存放入缓存池里

 静态资源的缓存叫做代理缓存，无论有几级缓存，最后都会延伸到源站

4.设计网站架构的误区

①不要盲目追求大公司的技术解决方案（可有远见）

②技术要服务于业务需要

③技术不能解决所有问题

二、haproxy

1.概述

haproxy是属于基于七层代理的负载均衡代理方案，同样支持对四层模拟TCP的负载，功能强大。j极限并发65535

七层应用层：基于Http协议进行代理调度

四层：基于tcp四层协议层进行调度，支持（TLS的https和Mysql调度）

四层：Redis、Mysql、RabbitMQ、Memcached等

七层：Nginx、Tomcat、Apache、PHP、图片、动静分离、API等

2.四层负载

在LVS 传统的四层负载设备中，把client发送的报文目标地址(原来是负载均衡设备的IP地址)，根据均衡设备设置的选择web服务器的规则选择对应的web服务器IP地址，这样client就可以直接跟此服务器建立TCP连接并发送数据，而四层负载自身不参与建立连接

而和LVS不同，haproxy是伪四层负载均衡，因为haproxy 需要分别和前端客户端及后端服务器建立套接字连接

3.七层代理

七层负载均衡服务器起了一个反向代理服务器的作用，服务器建立一次TCP连接要三次握手，而client要访问Web Server要先与七层负载设备进行三次握手后建立TCP连接，把要访问的报文信息发送给七层负载均衡；然后七层负载均衡再根据设置的均衡规则选择特定的 Web Server，然后通过三次握手与此台Web Server建立TCP连接，然后Web Server把需要的数据发送给七层负载均衡设备，负载均衡设备再把数据发送给client；所以，七层负载均衡设备起到了代理服务器的作用，七层代理需要和Client和后端服务器分别建立连接

代理实现的功能和作用：web缓存加速、反向代理、内容路由机制（根据内容类型将请求进行转发至特定后端服务器）

via首部：指明告诉代理服务器是谁。

代理缓存作用：   

                  减少冗余内容传输

                  节省带宽、缓解网络传输瓶颈

                  降低对后端原始服务器的请求压力

                  降低传输延时

4.haproxy简介

①：提供高 可用性、负载均衡以及基于TCP和HTTP应用的代理、免费、开源、可靠的解决方案。适用于负载大的web站点

②：实现了基于事件驱动、单一进程模型（新版是多线程模型），此模型支持数千级别的并发连接

③：haproxy不能实现ha高可用（keepalived），但是可以基于健康检查，来进行监控后端节点的状态。

④：haproxy只是http协议的反向代理，但是不提供缓存加速功能。但是反向代理功能强大，额外支持四层负载

缺点：没有缓存

5.haproxy版本的特性

①：TCP加速

②：响应池

③：支持RDP协议（代理后端Windows的图形界面，所用算法rdp-cookie）

④：基于源的粘性（session绑定）

⑤：更好的统计数据接口

⑥：基于流量的健康状态评估机制

⑦：支持HTTP认证

⑧：支持服务管理命令行接口

⑨：支持日志分析器

⑩：支持多个操作系统平台

支持ACL访问控制机制

6.负载均衡器的性能评估标准

①会话率（内容路由的能力：HAproxy、nginx、LVS）

②会话并发能力（LVS、HAproxy、nginx）

③数据率（nginx可以做缓存、HAproxy、LVS）

7.HAProxy 相对其他负载均衡器主要优点

①：HAProxy 是支持虚拟主机，通过 frontend前端 指令来实现

②：能够补充 Nginx 的一些缺点比如 Session 的保持，Cookie 的引导等工作

③：支持 url 检测后端的服务器出问题的检测会有很好的帮助

④：它跟 LVS 一样，本身仅仅就只是一款负载均衡软件；单纯从效率上来讲 HAProxy 更会比Nginx 有更出色的负载均衡速度，在并发处理上也是优于 Nginx。

⑤：HAProxy 可以对 Mysql进行负载均衡，对后端的 MySQL 节点进行检测和负载均衡，不过在后端的 MySQL slaves 数量超过 10 台时性能不如 LVS，所以更推荐 LVS+Keepalived。

⑥：能对请求的 url 和 header 中的信息做匹配，有比 Lvs 有更好的 7 层实现

【注】：haproxy基于七层负载，实现反向代理，必须监听在与之对应的应用程序端口上。

     和Nginx代理一样，基于多前端 交叉的方式 调度后端的调度方式

8.Nginx、LVS、haproxy的区别

描述：

LVS：基于四层做调度、基于内核层面、并发能力特别强 、理论上支持上百万并发；非常适用于大型企业中的接入层入口来实现数据/并发分流；缺点：算法少、不能实现反向代理、无法实现内容路由，数据率非常低。

HAproxy：既可以实现四层模拟调度和七层代理，功能强大；最主要是它的内容路由非常强大，ACl访问控制机制能力强，还有其算法能力强、会话率强等；缺点：没有缓存，数据率不如Nginx

Nginx：最大的特点是比较灵活，支持内容路由，数据率比较高、支持缓存；但是其代理能力没有HAproxy强，各有利弊，各有千秋

9.haproxy主配置文件以及原理相关剖析

global：全局配置段

代理配置段：

frontend：前端配置段

backend：后端服务配置段

listen：前后端不分离，直接使用。

default：默认配置段

【注】：作为负载均衡器，haproxy可以进行记录客户端的访问日志，但haproxy进行记录日志，需要进行单独定义。      后端日志透传LogFormat "%{X-Forwarded-For}i

三、HAproxy的配置参数

1.HAproxy主配置文件

全局配置：

语法检测： haproxy -c -f /etc/haproxy/haproxy.cfg

支持haproxy前端监听不存在的ip地址

echo ‘net.ipv4.ip_nonlocal_bind =1’ >> /etc/sysctl.conf

sysctl -p //生效

其他常用全局配置：

nbproc <number>：指定启动的haproxy守护进程的个数，不加此选项默认一个

ulimit -n：设定每个进程能打开的最大文件句柄数（相当于ulimit -n）

spread-check <0..50>：在haproxy后端有很多服务器场景，在精确的时间间隔后统一对众多服务器进行状态检查，会集中消耗大量带宽；这个选项可以在检查的时间间隔长度上增加或减少一定的随机时长。

debug：开启调试功能

2.代理配置

balance：调度算法（分为动态和静态算法，定义在listen或backend配置段）

        ①：roundrobin  动态轮询（可加权，属于动态调整的方式，后端服务器不能超过4128台）

        ②：static-rr：静态轮询（可加权，属于静态算法，后台服务器无上限）

        ③：leastconn：最少连接数（新的连接请求派发至最少连接数目的后端服务器。属于动态算法，仅仅适用于长连接会话）

        ④：source：源地址hash（默认为静态算法，若接入hash-type，则可以根据选项进行定义）

            hash-type：①map-based：取模法--->静态

                                ②consistent：一致性hash--->动态

        ⑤：uri：对URI的左半部分（“问题”标记之前）做hash运算，基于URI进行绑定调度。也支持hash-type    (目的地址hash，相当于LVS的DH算法)

         ⑥：url_param：根据url中指定的参数值进行调度，把值做hash计算。也支持hash-type

     ⑦：hdr（<name>）：根据请求报文中的header进行调度，包括（user_agent，referer,hostname），也支持hash-type。

3.相关参数定义和解释

bind：绑定监听的地址（可以绑定多个监听端口，只能用于frontend和listen） 

mode：指定实例的运行模式或协议。当实现内容交换时，前端和后端必须工作于同一种模式（默认为http模式）否则无法启动。

格式：mode {http|tcp|health}

log：为每个实例启用日志和流量日志，可以用于所有区段，最多定义两个，如果在全局global配置段中定义了两个，多余的log参数被忽略。

格式：log global

      log <address> <facility> [<level> [<minlevel>]]

maxconn：前端最大并发连接数（尽量调高此参数值，但不能超过global）

default_backend：为frontend指明使用的默认后端

use_backend：条件式后端调用

例如：use_backend  dynamic  if  url_dyn

              use_backend  static    if  url_css url_img  extension_img

              default_backend  dynamic

server：为后端声明一个server，因此不能用于default和frontend配置段

  格式： server <name> <address>[:port] [param*]

       <name>：为此服务器指定内部名称，只是出现在日志或警告信息中，没有太大实际用途。但如果设定了”http-send-server-name”中，会添加到发往服务器的请求首部中。

常用的param选项：

backup：设定当前server为sorry server

check：对此server做健康状态监测（间隔时间默认为2秒）

       子选项：inter<delay>：设定间隔时间，单位为ms（毫秒）

               fall：从up当down状态的确认检查次数

               rise：从down到up状态的确认检查次数

               server first1 192.168.10.200:80  cookie first  check inter 1000

               server first2 192.168.10.200:80  cookie first  check inter 1000

cookie：为指定server设定cookie值，此处指定的值在进行入站时被检查，目的实现会话绑定、持久连接的功能。

格式：cookie <name> [insert | rewrite |nocache | indirect]

要点：①每个server有自己唯一的cookie标识

           ②在backend中定义为用户请求调度完成后操纵其cookie

maxconn：此server接受的并发连接的最大数量

maxqueue：请求队列的最大长度

observer：根据流量判断后端server的健康状态

weight：权重，默认为1，最大值256,0表示不参与负载均衡

redir <prefix>：启用重定向功能，将发往此服务器的GET和HEAD请求以302状态码响应

需要注意prefix后不能使用/和相对地址，以免造成语法错误和循环。

例如：server srv1 192.168.10.200 redir http://web1.xxhf123.com check

haproxy同时支持TCP和HTTP的check方式，可以自行指定以及精细的方法

例如：option httpchk

server first 192.168.10.100:8080 cookie first check inter 1000

4.监控页

启用haproxy的状态监控页、使用stats enable进行启用

启用基于程序编译时默认设置的统计报告，不能用于frontend配置段，只要没有另外的其他设定，他们就会使用如下的配置。

如下选项：

stats uri      /haproxy?stats              status页面默认出现的位置  

访问方式http://xxx.xxx.xxx.xxx/haproxy?stats

#stats realm   “HAPorxy status”             status页面的提示信息

stats auth    no authentication

stats scope   no restriction                作用域（关闭即可全局生效）

默认的状态监控页，为了确保其安全性，尽量修改其监听的端口号，隐藏其版本号，修改其默认uri，最好进行管理员的账号密码登录访问控制。

定义状态监控页属性，最好定义在listen配置段，比较简洁、安全。

补充选项：

    stats uri /haproxyadmin?stats    定义新的status页面uri

    stats realm "haproxy\ deng"     定义新的登录账号密码的提示页面

    stats auth admin:666666        定义登录账号和密码（普通管理员）

stats admin if TRUE            认证成功才开启管理员功能（前提需要进行全局生效，则要注释关闭stats scope选项）

5.ACl访问控制

格式：acl <aclname> <criterion> [flag] [operator] <value> ...

aclname：acl名称，区分大小写，只能包括大小写字母、数字，连接线、下划线、点号、冒号

criterion：测试标准

flag：acl标志位

value：测试的数据值

常用的criterion：

①：be_sess_rate：用于测试指定的backend会话创建的速率

例如：

backend dynamic

      mode http

      acl being_scanned be_sess_rate gt 100

      redirect location /error_page/denied.html if being_scanned

②：fe_sess_rate：用于测试指定的frontend会话创建的速率

例如

frontend mail

    bind :25

    mode tcp

    maxconn 5000

    acl too_fast fe_sess_rate gt 100

    tcp-request inspect-delay 500ms    延迟500毫秒

    tcp-request content accept if ! too_fast

    tcp-request content accept if WAIT_END

③：hdr

④：method：根据请求的方法进行匹配

⑤：path_beg：根据请求URL路径的开头来匹配  例如：acl   url_static  path_beg  -i  /static /images /javascript /stylesheets      location

⑥：path_end：根据URL路径请求的结尾        例如：acl   url_static  path_beg  -i  .jpg   .gif   .png   .css   .js