37

http服务端架构演进

 4 years ago
source link: https://www.tuicool.com/articles/3UjMB3A
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

摘要

详解http报文 相关文章中我们介绍了http协议是如何工作的,那么构建一个真实的网站还需要引入组件呢?一些常见的名词到底是什么含义呢?

  1. 什么叫正向代理,什么叫反向代理

  2. 服务代理与负载均衡的差别

  3. 有了nginx,为啥还需要LVS

  4. 都有哪些负载均衡的方式

服务端演进

在前面文章中我们介绍过最简单的一种客户端-服务端响应模式,如下 Jfa6zir.png!web

这是http服务最简单的一种形式,服务端就一层web服务器。

现在我们服务端变复杂了,用户数增加了,并发量增加了。对我们服务端要求增加了

  • 服务能力:一台服务器满足不了这么多的http的请求了。我们需要增加机器了,进行服务扩容了

  • 安全防护:开始有人对我们的服务进行网络攻击了,需要保护服务端服务器,限制ip地址

  • 网站升级: 网站上线后,需要提供7*24小时无间断服务了,发布新的版本,需要保证网站的可用。

代理服务

为了解决这些问题,我们需要引入 中间层 也就是代理,在客户端和服务端中间插入一个中间环节,代理服务。代理,狭义上讲就是不生产内容,只是转发上下游的请求和响应。

代理服务按照是否匿名可以分为

  • 匿名代理:外部不知道真实机器,只知道代理服务器

  • 透明代理:外界知道代理,也知道真实服务器

按照靠近客户端还是服务端,分为

  • 正向代理:代理客户端,代表着客户端向服务器端发送请求

  • 反向代理:代理服务端,代表着服务器向客户端发送请求。

http协议对代理的支持

因为http协议最开始并没有考虑代理服务,设计的协议只是针对客户端-服务器模式。根据我们通常的架构标准,http协议层是不用关心使用者是如何使用的,代理服务这种中间产物自然不用考虑。服务端有获取客户端ip的需求,所以Squid这个缓存代理软件最先引入 X-Forwarded-For 头字段,用来表示 客户端的真实 IP。

格式如下,从客户端到各个代理服务,记录下每一层的转发

这个需求是如此的普世,所以慢慢变成了标准,被各个代理服务广泛使用,所以后来被写入到RFC 7239标准之中了

代理协议

HTTP 协议本身对代理服务并没有什么说明,所以就衍生出了代理协议,代理协议是haproxy的作者Willy Tarreau于2010年开发和设计的一个Internet协议,通过为tcp添加一个很小的头信息,来方便的传递客户端信息(协议栈、源IP、目的IP、源端口、目的端口等),在网络情况复杂又需要获取客户IP时非常有用。

  • 多层NAT网络

  • TCP代理(四层)或多层tcp代理

  • https反向代理http(某些情况下由于Keep-alive导致不是每次请求都传递x-forword-for)

  • https通信加密,不允许修改原始报文

另外由于每一层代理服务都需要解析http header 头 X-Forwarded-For ,然后追加自己的地址,所以这个成本也比较高。所以代理协议也变成了 刚需 ,虽然是haproxy提出来的,但是也被各大代理服务器支持了,如nginx、apache、squid。代理协议格式

这样请求方解析第一行就可以拿到客户端ip,不用再去处理http报文了。

负载均衡

负载均衡,其实就是分发请求。根据OSI七层协议

v6V7J37.png!web

负载均衡分成两种

  • 4层负载均衡,即工作在第四层传输层,利用ip地址端口进行请求转发,因为没有其他操作,所以效率比较高

  • 七层负载均衡,即工作在第七层应用层,根据HTTP请求头,URL信息转发特定的主机。效率相对低一点。

nginx是七层负载均衡,LVS是七层负载均衡。

所以小型网站,nginx就足够,当流量足够大时,负载均衡成为瓶颈了,就可以在前面引入了LVS一层。

关于具体的负载均衡算法,参考这边文章,这里不再赘述

安全防护

前面我们提到过安全防护也是代理服务的一大重要功能。为了应对外部攻击,需要引入网络防火墙,WAF(Web Application Firewall)。工作在OSI 第七层,主要是对http报文进行更细致的审核,也就是各种filter。比如

  • IP 黑白名单

  • DDOS攻击

  • 各种注入

当服务的安全性要求没那么高时,或者对公司业务发展的ROI没那么高时,我们通常就在nginx层面配置一些规则即可。需求升级时,我们就要引入专门的模型,比如 ModSecurity1 。需求再升级时,引入外部云厂商提供的WAF服务。

最终架构形式

http服务端架构演进和我们单应用架构演进有异曲同工之处。在业务不复杂的时候,可以使用单体模块搞定(比如Nginx),当请求量增加,需求升级时,需要引入中间层来解决。当某个模块要求增加时,需要解耦出单独的模块来处理。

所以整体上看,一个中型的服务端架构如下图。

Jfii2mV.png!web

参考

https://juejin.im/post/5ccaaf0af265da035e213490

https://www.cnblogs.com/xybaby/p/7867735.html

关注公众号【方丈的寺院】,第一时间收到文章的更新,与方丈一起开始技术修行之路

a6jAVfI.jpg!web


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK