http服务端架构演进
摘要
在 详解http报文相关文章中我们介绍了http协议是如何工作的，那么构建一个真实的网站还需要引入组件呢?一些常见的名词到底是什么含义呢？
- 什么叫正向代理，什么叫反向代理
- 服务代理与负载均衡的差别
- 有了nginx，为啥还需要LVS
- 都有哪些负载均衡的方式
服务端演进
在前面文章中我们介绍过最简单的一种客户端-服务端响应模式，如下
这是http服务最简单的一种形式，服务端就一层web服务器。
现在我们服务端变复杂了，用户数增加了，并发量增加了。对我们服务端要求增加了
- 服务能力：一台服务器满足不了这么多的http的请求了。我们需要增加机器了，进行服务扩容了
- 安全防护：开始有人对我们的服务进行网络攻击了，需要保护服务端服务器，限制ip地址
- 网站升级: 网站上线后，需要提供7*24小时无间断服务了，发布新的版本，需要保证网站的可用。
代理服务
为了解决这些问题，我们需要引入 中间层也就是代理，在客户端和服务端中间插入一个中间环节，代理服务。代理，狭义上讲就是不生产内容，只是转发上下游的请求和响应。
代理服务按照是否匿名可以分为
- 匿名代理：外部不知道真实机器，只知道代理服务器
- 透明代理：外界知道代理，也知道真实服务器
按照靠近客户端还是服务端，分为
- 正向代理：代理客户端，代表着客户端向服务器端发送请求
- 反向代理：代理服务端，代表着服务器向客户端发送请求。
http协议对代理的支持
因为http协议最开始并没有考虑代理服务，设计的协议只是针对客户端-服务器模式。根据我们通常的架构标准，http协议层是不用关心使用者是如何使用的，代理服务这种中间产物自然不用考虑。服务端有获取客户端ip的需求，所以Squid这个缓存代理软件最先引入 X-Forwarded-For头字段，用来表示 客户端的真实 IP。
格式如下，从客户端到各个代理服务，记录下每一层的转发
X-Forwarded-For: client, proxy1, proxy2这个需求是如此的普世，所以慢慢变成了标准，被各个代理服务广泛使用，所以后来被写入到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。代理协议格式
PROXY TCP4/TCP6 客户端ip 应答方ip 请求方端口号 应答方端口号 \r\n这样请求方解析第一行就可以拿到客户端ip,不用再去处理http报文了。
负载均衡
负载均衡，其实就是分发请求。根据OSI七层协议
负载均衡分成两种
- 4层负载均衡，即工作在第四层传输层，利用ip地址端口进行请求转发，因为没有其他操作，所以效率比较高
- 七层负载均衡，即工作在第七层应用层，根据HTTP请求头，URL信息转发特定的主机。效率相对低一点。
nginx是七层负载均衡，LVS是七层负载均衡。
所以小型网站，nginx就足够，当流量足够大时，负载均衡成为瓶颈了，就可以在前面引入了LVS一层。
关于具体的负载均衡算法，参考这边文章,这里不再赘述
安全防护
前面我们提到过安全防护也是代理服务的一大重要功能。为了应对外部攻击，需要引入网络防火墙，WAF(Web Application Firewall)。工作在OSI 第七层，主要是对http报文进行更细致的审核，也就是各种filter。比如
- IP 黑白名单
- DDOS攻击
- 各种注入
当服务的安全性要求没那么高时，或者对公司业务发展的ROI没那么高时，我们通常就在nginx层面配置一些规则即可。需求升级时，我们就要引入专门的模型，比如 ModSecurity1。需求再升级时，引入外部云厂商提供的WAF服务。
最终架构形式
http服务端架构演进和我们单应用架构演进有异曲同工之处。在业务不复杂的时候，可以使用单体模块搞定（比如Nginx），当请求量增加，需求升级时，需要引入中间层来解决。当某个模块要求增加时，需要解耦出单独的模块来处理。
所以整体上看，一个中型的服务端架构如下图。
参考
https://juejin.im/post/5ccaaf0af265da035e213490
https://www.cnblogs.com/xybaby/p/7867735.html