怎样具备大规模高并发访问的Web应用架构设计和开发经验
理论上经验这个东西是学不来的
说一下我的例子
刚入行的时候,基本就是写了一些增删改查甚至session都不太理解
随着入行后,你会遇到各种各样的问题在解决问题的过程中,经验来了
简单说一下所谓大规模高并发访问的web架构吧
其实,对于大规模高并发不外乎两点,第一点是及时相应(尽可能优化io)第二点是数据安全
这两点控制的好,就没问题的所以,我们的架构也就围绕在这两点应运而生
第一点,为了尽可能提高应用的io吞吐量则需要我们把所有耗时的io操作尽可能的优化,比如全局使用很少更改的一些配置,则可以采用nosql来全局共享(注意,这里的全局是指服务器集群如果涉及到了大规模,肯定是多服务器的)在其次可以增加服务器缓存比如2秒钟从上一条的服务器读取配置,存到服务器级别以提高效率还有线程缓存如果业务复杂可能对一个请求需要查询多次数据,不变的,老规矩,放到线程缓存基本也就差不多了
第二点,因为应用不同,要考虑容错率这个部分优化,可以考虑分离业务,把必须要数据安全的业务逻辑提取出来,队列执行或者特殊处理
剩下的就是服务器部署与如何分配,比如多少台web服务器,数据库配置,内存服务器配置等
这只能是在实际项目和工作过程中来区别对待了
架构是为了解决糸统中具有共性的问题而进行定义了减少重复工作量,且易于维护和扩展的技术准则和规范,它产出物和体现为文档和基础代码框架等。
因此选择那些框架只是架构的一部分,通常是选择自己善长的,以及对新技术的更新比较及时的;所以现在的Java框架最多为SpringMVC。
所以你提出的大并发是一个问题,但先确定它是不是所有模块都需要解决这个问题。
而大数据又是另一个问题,同样每个模块查询或者计算都是大数据吗。
综上所述将问题定位并分解,并发问题,要考虑带宽还是局域网,一个应用服务器最大能支持多少请求连接,你需要多少个,每个应用服务器是独立的模块呢还是齐群。齐群还要注意的登录一次还是多次,也就是SSO了,是否注意内存共享,如sessionId,是否考虑内存相互同步还是通过分布式的解决等糸列问题。还有一个数据库有多少连接可以用等跟应用服务器同理。
那么大数据呢,要考虑的关键为两个,是计算还是查询,是实时的业务要求还是可以延时的,查询可以是缓存,分表分库,分区,索引等方式。缓存的时候要注意你考虑的带宽是一个lDC还是多个IDC,数据间怎么同歩是个分布式问题,如果大数据计算问题是否考虑一下云计算解决方案等
因此你所说的怎么架构,如何选框架,这是两个问题,不是解决你问的大数据大并发,反而是架构工作中的一个尘灰而已。你也知道架构最大的是那里了吧一一分析到分割。
架构是很难的工作,作不好,别相信用硬件能解决问题。就像使用微软的 盗版一样,出了问题可能是用N的成本来解决,N可能是几万,也可能是几万的N次方。
1、程序和数据库部署在同一台服务器上2多学习一些相关的书籍比如:构建高性能Web站点,大规模Web服务开发技术构建可扩展的Web站点,Web容量规划的技术,分布式数据库系统及其应用。掌握其原理和结构。
11 负载均衡介绍
111 负载均衡的妙用
112 为什么要用lvs
那为什么要用lvs呢?
ü 简单一句话,当并发超过了Nginx上限,就可以使用LVS了。
ü 日1000-2000W PV或并发请求1万以下都可以考虑用Nginx。
ü 大型门户网站,电商网站需要用到LVS。
12 LVS介绍
LVS是Linux Virtual Server的简写,意即Linux虚拟服务器,是一个虚拟的服务器集群系统,可以在UNIX/LINUX平台下实现负载均衡集群功能。该项目在1998年5月由章文嵩博士组织成立,是 中国国内最早出现的自由软件项目之一 。
121 相关参考资料
LVS官网: http://wwwlinuxvirtualserverorg/indexhtml
相关中文资料
122 LVS内核模块ip_vs介绍
ü LVS无需安装
ü 安装的是管理工具,第一种叫ipvsadm,第二种叫keepalive
ü ipvsadm是通过命令行管理,而keepalive读取配置文件管理
ü 后面我们会用Shell脚本实现keepalive的功能
13 LVS集群搭建
131 集群环境说明
主机说明
web环境说明
web服务器的搭建参照:
Tomcat:
http://wwwcnblogscom/clsn/p/7904611html
Nginx:
http://wwwcnblogscom/clsn/p/7750615html
132 安装ipvsadm管理工具
安装管理工具
查看当前LVS状态,顺便激活LVS内核模块。
查看系统的LVS模块。
133 LVS集群搭建
命令集 :
检查结果 :
ipvsadm参数说明: (更多参照 man ipvsadm)
134 在web浏览器配置操作
命令集 :
至此LVS集群配置完毕 !
135 进行访问测试
浏览器访问:
命令行测试:
抓包查看结果:
arp解析查看:
14 负载均衡(LVS)相关名词
术语说明:
141 LVS集群的工作模式--DR直接路由模式
DR模式是通过改写请求报文的目标MAC地址,将请求发给真实服务器的,而真实服务器将响应后的处理结果直接返回给客户端用户。
DR技术可极大地提高集群系统的伸缩性。但要求调度器LB与真实服务器RS都有一块物理网卡连在同一物理网段上,即必须在同一局域网环境。
DR直接路由模式说明:
a)通过在调度器LB上修改数据包的目的MAC地址实现转发。注意,源IP地址仍然是CIP,目的IP地址仍然是VIP。
b)请求的报文经过调度器,而RS响应处理后的报文无需经过调度器LB,因此,并发访问量大时使用效率很高,比Nginx代理模式强于此处。
c)因DR模式是通过MAC地址的改写机制实现转发的,因此,所有RS节点和调度器LB只能在同一个局域网中。需要注意RS节点的VIP的绑定(lo:vip/32)和ARP抑制问题。
d)强调一下:RS节点的默认网关不需要是调度器LB的DIP,而应该直接是IDC机房分配的上级路由器的IP(这是RS带有外网IP地址的情况),理论上讲,只要RS可以出网即可,不需要必须配置外网IP,但走自己的网关,那网关就成为瓶颈了。
e)由于DR模式的调度器仅进行了目的MAC地址的改写,因此,调度器LB无法改变请求报文的目的端口。LVS DR模式的办公室在二层数据链路层(MAC),NAT模式则工作在三层网络层(IP)和四层传输层(端口)。
f)当前,调度器LB支持几乎所有UNIX、Linux系统,但不支持windows系统。真实服务器RS节点可以是windows系统。
g)总之,DR模式效率很高,但是配置也较麻烦。因此,访问量不是特别大的公司可以用haproxy/Nginx取代之。这符合运维的原则:简单、易用、高效。日1000-2000W PV或并发请求1万以下都可以考虑用haproxy/Nginx(LVS的NAT模式)
h)直接对外的访问业务,例如web服务做RS节点,RS最好用公网IP地址。如果不直接对外的业务,例如:MySQL,存储系统RS节点,最好只用内部IP地址。
DR的实现原理和数据包的改变
(a) 当用户请求到达Director Server,此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP,目标IP为VIP
(b) PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链
(c) IPVS比对数据包请求的服务是否为集群服务,若是,将请求报文中的源MAC地址修改为DIP的MAC地址,将目标MAC地址修改RIP的MAC地址,然后将数据包发至POSTROUTING链。 此时的源IP和目的IP均未修改,仅修改了源MAC地址为DIP的MAC地址,目标MAC地址为RIP的MAC地址
(d) 由于DS和RS在同一个网络中,所以是通过二层来传输。POSTROUTING链检查目标MAC地址为RIP的MAC地址,那么此时数据包将会发至Real Server。
(e) RS发现请求报文的MAC地址是自己的MAC地址,就接收此报文。处理完成之后,将响应报文通过lo接口传送给eth0网卡然后向外发出。 此时的源IP地址为VIP,目标IP为CIP
(f) 响应报文最终送达至客户端
15 在web端的操作有什么含义?
151 RealServer为什么要在lo接口上配置VIP?
既然要让RS能够处理目标地址为vip的IP包,首先必须要让RS能接收到这个包。
在lo上配置vip能够完成接收包并将结果返回client。
152 在eth0网卡上配置VIP可以吗?
不可以,将VIP设置在eth0网卡上,会影响RS的arp请求,造成整体LVS集群arp缓存表紊乱,以至于整个负载均衡集群都不能正常工作。
153 为什么要抑制ARP响应?
① arp协议说明
为了提高IP转换MAC的效率,系统会将解析结果保存下来,这个结果叫做ARP缓存。
ARP缓存表是把双刃剑
ARP广播进行新的地址解析
测试命令
windows查看arp -a
③arp_announce和arp_ignore详解
lvs在DR模式下需要关闭arp功能
arp_announce
对网络接口上,本地IP地址的发出的,ARP回应,作出相应级别的限制:
确定不同程度的限制,宣布对来自本地源IP地址发出Arp请求的接口
arp_ignore 定义
对目标地定义对目标地址为本地IP的ARP询问不同的应答模式0
抑制RS端arp前的广播情况
抑制RS端arp后广播情况
16 LVS集群的工作模式
DR(Direct Routing)直接路由模式
NAT(Network Address Translation)
TUN(Tunneling)隧道模式
FULLNAT(Full Network Address Translation)
161 LVS集群的工作模式--NAT
通过网络地址转换,调度器LB重写请求报文的目标地址,根据预设的调度算法,将请求分派给后端的真实服务器,真实服务器的响应报文处理之后,返回时必须要通过调度器,经过调度器时报文的源地址被重写,再返回给客户,完成整个负载调度过程。
收费站模式---来去都要经过LB负载均衡器。
NAT方式的实现原理和数据包的改变
(a) 当用户请求到达Director Server,此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP,目标IP为VIP
(b) PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链
(c) IPVS比对数据包请求的服务是否为集群服务,若是,修改数据包的目标IP地址为后端服务器IP,然后将数据包发至POSTROUTING链。 此时报文的源IP为CIP,目标IP为RIP
(d) POSTROUTING链通过选路,将数据包发送给Real Server
(e) Real Server比对发现目标为自己的IP,开始构建响应报文发回给Director Server。 此时报文的源IP为RIP,目标IP为CIP
(f) Director Server在响应客户端前,此时会将源IP地址修改为自己的VIP地址,然后响应给客户端。 此时报文的源IP为VIP,目标IP为CIP
LVS-NAT模型的特性
l RS应该使用私有地址,RS的网关必须指向DIP
l DIP和RIP必须在同一个网段内
l 请求和响应报文都需要经过Director Server,高负载场景中,Director Server易成为性能瓶颈
l 支持端口映射
l RS可以使用任意操作系统
l 缺陷:对Director Server压力会比较大,请求和响应都需经过director server
162 LVS集群的工作模式--隧道模式TUN
采用NAT技术时,由于请求和响应的报文都必须经过调度器地址重写,当客户请求越来越多时,调度器的处理能力将成为瓶颈。
为了解决这个问题,调度器把请求的报文通过IP隧道(相当于ipip或ipsec )转发至真实服务器,而真实服务器将响应处理后直接返回给客户端用户,这样调度器就只处理请求的入站报文。
由于一般网络服务应答数据比请求报文大很多,采用 VS/TUN技术后,集群系统的最大吞吐量可以提高10倍。
VS/TUN工作流程,它的连接调度和管理与VS/NAT中的一样,只是它的报文转发方法不同。
调度器根据各个服务器的负载情况,连接数多少,动态地选择一台服务器,将原请求的报文封装在另一个IP报文中,再将封装后的IP报文转发给选出的真实服务器。
真实服务器收到报文后,先将收到的报文解封获得原来目标地址为VIP地址的报文, 服务器发现VIP地址被配置在本地的IP隧道设备上(此处要人为配置),所以就处理这个请求,然后根据路由表将响应报文直接返回给客户。
TUN原理和数据包的改变
(a) 当用户请求到达Director Server,此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP,目标IP为VIP 。
(b) PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链
(c) IPVS比对数据包请求的服务是否为集群服务,若是,在请求报文的首部再次封装一层IP报文,封装源IP为为DIP,目标IP为RIP。然后发至POSTROUTING链。 此时源IP为DIP,目标IP为RIP
(d) POSTROUTING链根据最新封装的IP报文,将数据包发至RS(因为在外层封装多了一层IP首部,所以可以理解为此时通过隧道传输)。 此时源IP为DIP,目标IP为RIP
(e) RS接收到报文后发现是自己的IP地址,就将报文接收下来,拆除掉最外层的IP后,会发现里面还有一层IP首部,而且目标是自己的lo接口VIP,那么此时RS开始处理此请求,处理完成之后,通过lo接口送给eth0网卡,然后向外传递。 此时的源IP地址为VIP,目标IP为CIP
(f) 响应报文最终送达至客户端
LVS-Tun模型特性
163 LVS集群的工作模式--FULLNAT
LVS的DR和NAT模式要求RS和LVS在同一个vlan中,导致部署成本过高;TUNNEL模式虽然可以跨vlan,但RealServer上需要部署ipip隧道模块等,网络拓扑上需要连通外网,较复杂,不易运维。
为了解决上述问题,开发出FULLNAT
该模式和NAT模式的区别是:数据包进入时,除了做DNAT,还做SNAT(用户ip->内网ip)
从而实现LVS-RealServer间可以跨vlan通讯,RealServer只需要连接到内网。类比地铁站多个闸机。
17 IPVS调度器实现了如下八种负载调度算法:
a) 轮询(Round Robin)RR
调度器通过"轮叫"调度算法将外部请求按顺序轮流分配到集群中的真实服务器上,它均等地对待每一台服务器,而不管服务器上实际的连接数和系统负载。
b) 加权轮叫(Weighted Round Robin)WRR
调度器通过"加权轮叫"调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。
调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。
c) 最少链接(Least Connections) LC
调度器通过"最少连接"调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。
如果集群系统的真实服务器具有相近的系统性能,采用"最小连接"调度算法可以较好地均衡负载。
d) 加权最少链接(Weighted Least Connections) Wlc
在集群系统中的服务器性能差异较大的情况下,调度器采用"加权最少链接"调度算法优化负载均衡性能,具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。
e) 基于局部性的最少链接(Locality-Based Least Connections) Lblc
"基于局部性的最少链接" 调度算法是针对目标IP地址的负载均衡,目前主要用于Cache集群系统。
该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器,若该服务器 是可用的且没有超载,将请求发送到该服务器。
若服务器不存在,或者该服务器超载且有服务器处于一半的工作负载,则用"最少链接"的原则选出一个可用的服务 器,将请求发送到该服务器。
f) 带复制的基于局部性最少链接(Locality-Based Least Connections with Replication)
"带复制的基于局部性最少链接"调度算法也是针对目标IP地址的负载均衡,目前主要用于Cache集群系统。
它与LBLC算法的不同之处是它要维护从一个 目标IP地址到一组服务器的映射,而LBLC算法维护从一个目标IP地址到一台服务器的映射。
该算法根据请求的目标IP地址找出该目标IP地址对应的服务 器组,按"最小连接"原则从服务器组中选出一台服务器,若服务器没有超载,将请求发送到该服务器。
若服务器超载,则按"最小连接"原则从这个集群中选出一 台服务器,将该服务器加入到服务器组中,将请求发送到该服务器。
同时,当该服务器组有一段时间没有被修改,将最忙的服务器从服务器组中删除,以降低复制的 程度。
g) 目标地址散列(Destination Hashing) Dh
"目标地址散列"调度算法根据请求的目标IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。
h) 源地址散列(Source Hashing)SH
"源地址散列"调度算法根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器。
若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。
18 LVS+Keepalived方案实现
181 keepalived功能
1 添加VIP
2 添加LVS配置
3 高可用(VIP漂移)
4 web服务器 健康 检查
182 在负载器安装Keepalived软件
# 检查软件是否安装
183 修改配置文件
lb03上keepalied配置文件
lb04的Keepalied配置文件
keepalived persistence_timeout参数意义 LVS Persistence 参数的作用
http://blogcsdnnet/nimasike/article/details/53911363
184 启动keepalived服务
185 在web服务器上进行配置
注意:web服务器上的配置为临时生效,可以将其写入rclocal文件,注意文件的执行权限。
使用curl命令进行测试
至此keepalived+lvs配置完毕
19 常见LVS负载均衡高可用解决方案
Ø 开发类似keepalived的脚本,早期的办法,现在不推荐使用。
Ø heartbeat+lvs+ldirectord脚本配置方案,复杂不易控制,不推荐使用
Ø RedHat工具piranha,一个web界面配置LVS。
Ø LVS-DR+keepalived方案,推荐最优方案,简单、易用、高效。
191 lvs排错思路
0条评论