Linux中级之负载均衡（lvs,nginx,haproxy）、中间件

1、负载均衡的概念

1、系统的扩展方式：

       scale up：向上扩展

       scale out：向外扩展

2、集群类型：  LB（Load Balancing）、HA（high availability）

3、LB集群的实现

              硬件：F5、Redware

              软件：lvs、haproxy、nginx

4、基于工做的协议层划分：

       传输层：

       Lvs：工做在内核模块中

       HAProxy：

1.mode tcp，若是工做在应用层只能调度http协议，若是基于tcp协议它可以调度https，mysql等经常使用的tcp协议

2.haproxy只是模拟tcp协议，由于tcp协议工做在内核当中，而haproxy属于应用程序工做在第七层，是工做在某个套接字上的应用程序

应用层：haproxy，nginx

从负载均衡设备的角度来看，分为硬件负载均衡和软件负载均衡：

硬件负载均衡：好比最多见的F5，还有Array等，这些负载均衡是商业的负载均衡器，性能比较好，毕竟他们的就是为了负载均衡而生的，背后也有很是成熟的团队，能够提供各类解决方案，可是价格比较昂贵，因此没有充足的理由，充足的软妹币是不会考虑的。

软件负载均衡：包括咱们耳熟能详的Nginx，LVS，Tengine（阿里对Nginx进行的改造）等。优势就是成本比较低，可是也须要有比较专业的团队去维护，要本身去踩坑，去DIY。

从负载均衡的技术来看，分为服务端负载均衡和客户端负载均衡：

服务端负载均衡：当咱们访问一个服务，请求会先到另一台服务器，而后这台服务器会把请求分发到提供这个服务的服务器，固然若是只有一台服务器，那好说，直接把请求给那一台服务器就能够了，可是若是有多台服务器呢？这时候，就会根据必定的算法选择一台服务器。

客户端负载均衡：客户端服务均衡的概念貌似是有了服务治理才产生的，简单的来讲，就是在一台服务器上维护着全部服务的ip，名称等信息，当咱们在代码中访问一个服务，是经过一个组件访问的，这个组件会从那台服务器上取到全部提供这个服务的服务器的信息，而后经过必定的算法，选择一台服务器进行请求。

2、三大主流软件负载均衡器对比(LVS、Nginx、HAproxy)

1、LVS：

1. 抗负载能力强，性能高，能达到F5的60%，对内存和CPU资源消耗比较低

2. 工做在网络4层，经过VRRP协议(仅做代理分发之用)，具体的流量是由linux内核来处理，所以没有流量的产生。

3. 稳定，可靠性高，自身有完美的热备方案(Keepalived+lvs)

4. 不支持正则处理，不能作动静分离；但应用范围比较广，能够对全部应用作负载均衡

5. 支持多种负载均衡算法：rr(轮询)，wrr(带权轮询)、lc(最小链接)、wlc(带权最小链接)

6. 配置相对复杂，对网络依赖比较大，稳定性很高。

7. LVS工做模式有4种：

(1) nat 地址转换

(2) dr 直接路由

(3) tun 隧道

(4) full-nat

2、Nginx：

1. 工做在网络7层，能够针对http应用作一些分流的策略，好比针对域名，目录结构

2. Nginx对网络的依赖较小，理论上能ping通就能进行负载功能

3. Nginx安装配置比较简单，测试起来很方便

4. 也能够承担较高的负载压力且稳定，nginx是为解决c10k问题而诞生的，通常能支撑超过1万次的并发

5. 对后端服务器的健康检查，只支持经过端口来检测，不支持经过url来检测

6. Nginx对请求的异步处理能够帮助节点服务器减轻负载压力

7. Nginx仅能支持http、https和Email协议，这样就在适用范围较小。

8. 不支持Session的直接保持，但能经过ip_hash来解决。对Big request header的支持不是很好。

9. Nginx还能作Web服务器即Cache功能。

10. 支持负载均衡算法：Round-robin（轮循）、Weight-round-robin（带权轮循）、Ip-hash（IP哈希）

第6点补充：

squid同步处理：浏览器发起请求，然后请求会马上被转到后端，因而在浏览器和后台之间就创建了一个通道。从请求发起直到请求完成，这条通道都是一直存在的。

nginx异步处理：浏览器发起请求，请求不会马上转到后端，而是请求数据(header)先收到nignx上，而后nginx再把这个请求发到后端，后端处理完成后把数据返回到nginx上，nginx将数据流发到浏览器。

使用异步处理的好处：

1. 假设用户执行一个上传文件操做，由于用户网速又比较慢，所以须要花半个小时才能把文件传到服务器。squid的同步代理在用户开始上传后就和后台创建了链接，半小时后文件上传结束，因而可知，后台服务器链接保持了半个小时；而nginx异步代理就是先将此文件收到nginx上，所以仅仅是nginx和用户保持了半小时链接，后台服务器在这半小时内没有为这个请求开启链接，半小时后用户上传结束，nginx才将上传内容发到后台，nginx和后台之间的带宽是很充裕的，因此只花了一秒钟就将请求发送到了后台，因而可知，后台服务器链接保持了一秒。同步传输花了后台服务器半个小时，异步传输只花一秒，可见优化程度很大。

2. 在上面这个例子中，假如后台服务器由于种种缘由重启了，上传文件就天然中断了，这对用户来讲是很是恼火的一件事情，想必各位也有上传文件传到一半被中断的经历。用nginx代理以后，后台服务器的重启对用户上传的影响减小到了极点，而nginx是很是稳定的并不须要常去重启它，即便须要重启，利用kill -HUP就能够作到不间断重启nginx。

3. 异步传输能够令负载均衡器更有保障，为何这么说呢？在其它的均衡器（lvs/haproxy/apache等）里，每一个请求都是只有一次机会的，假如用户发起一个请求，结果该请求分到的后台服务器恰好挂掉了，那么这个请求就失败了；而nginx由于是异步的，因此这个请求能够从新发往下一个后台，下一个 后台返回了正常的数据，因而这个请求就能成功了。仍是用用户上传文件这个例子，假如不但用了nginx代理，并且用了负载均衡，nginx把上传文件发往 其中一台后台，但这台服务器忽然重启了，nginx收到错误后，会将这个上传文件发到另外一台后台，因而用户就不用再花半小时上传一遍。

4. 假如用户上传一个10GB大小的文件，然后台服务器没有考虑到这个状况，那么后台服务器岂不要崩溃了。用nginx就能够把这些东西都拦在nginx上，经过nginx的上传文件大小限制功能来限制，另外nginx性能很是有保障，就放心的让互联网上那些另类的用户和nginx对抗去吧。

用异步传输会形成问题：

后台服务器有提供上传进度的功能的话，用了nginx代理就没法取得进度，这个须要使用nginx的一个第三方模块来实现。

第8点补充：

Nginx upstream支持的分配策略及原理：

1. 轮询(默认)：每一个请求按照顺序逐一分配到不一样的后端服务器。如后端服务器down掉，就切换到另外一台并剔除down的后端主机

2. weight：指定轮询概率，weight和访问比率成正比，用于后端服务器性能不均的状况。

3. ip_hash：每一个请求按照访问ip的hash结果分配，不一样ip的请求被分配到后端不一样的服务器上，能够解决session的问题。

3、HAProxy:

1. 支持两种代理模式：TCP（四层）和HTTP（七层），支持虚拟主机；

2. 可以补充Nginx的一些缺点好比Session的保持，Cookie的引导等工做

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

4. 更多的负载均衡策略好比：动态加权轮循(Dynamic Round Robin)，加权源地址哈希(Weighted Source Hash)，加权URL哈希和加权参数哈希(Weighted Parameter Hash)已经实现

5. 单纯从效率上来说HAProxy更会比Nginx有更出色的负载均衡速度。

6. HAProxy能够对Mysql进行负载均衡，对后端的DB节点进行检测和负载均衡。

7. 支持负载均衡算法：Round-robin（轮循）、Weight-round-robin（带权轮循）、source（原地址保持）、RI（请求URL）、rdp-cookie（根据cookie）

8. 不能作Web服务器即Cache。

三大主流软件负载均衡器适用业务场景：

1. 网站建设初期，能够选用Nginx、HAProxy做为反向代理负载均衡(流量不大时，能够不选用负载均衡)，由于其配置简单，性能也能知足通常业务场景。若是考虑到负载均衡器是有单点问题，能够采用Nginx+Keepalived/HAproxy+Keepalived避免负载均衡器自身的单点问题。

2. 网站并发到达必定程度后，为了提升稳定性和转发效率，可使用lvs，毕竟lvs比Nginx/HAProxy要更稳定，转发效率也更高。

注：nginx与HAProxy比较：nginx只支持七层，用户量最大，稳定性比较可靠。Haproxy支持四层和七层，支持更多的负载均衡算法，支持session等。

衡量负载均衡器好坏的几个重要的因素：

1. 会话率 ：单位时间内的处理的请求数

2. 会话并发能力：并发处理能力

3. 数据率：处理数据能力

3、中间件

中间件是在操做系统功能范围外为应用提供服务的多用途软件。任何位于内核和用户应用之间的软件均可以是中间件。中间件不提供传统应用的功能，而是将软件与其余软件衔接。因为中间件可以让数据从一个应用流动到另外一个中，所以把它比做输水管最为贴切。

中间件就是程序中可织入的，可重用的，与业务逻辑无关的各类组件。

中间件(middleware)是基础软件的一大类，属于可复用软件的范畴。

顾名思义，中间件处于操做系统软件与用户的应用软件的中间。

中间件在操做系统、网络和数据库之上， 应用软件的下层，总的做用是为处于本身上层的应用软件提供运行与开发的环境，帮助用户灵活、高效地开发和集成复杂的应用软件。

在众多关于中间件的定义中，比较广泛被接受的是 IDC 表述的：中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不一样的技术之间共享资源，中间件位于客户机服务器的操做系统之上，管理计算资源和网络通讯。

分类：数据访问中间件，远程调用中间件，消息中间件，交易中间件，对象中间件。

举例：

1. RMI (Remote Method Invocations, 远程调用)

2. Load Balancing(负载均衡，将访问负荷分散到各个服务器中)

3. Transparent Fail-over(透明的故障切换)

4. Clustering(集群 , 用多个小的服务器代替大型机)

5. Back-end-Integration(后端集成，用现有的、新开发的系统如何去集成遗留的系统)

6. T ransaction 事务(全局 / 局部)全局事务(分布式事务)局部事务(在同一数据库联 接内的事务)

7. Dynamic Redeployment (动态从新部署 , 在不中止原系统的状况下，部署新的系统)

8. System Management(系统管理)

9. Threading(多线程处理)

10. Message-oriented Middleware 面向消息的中间件(异步的调用编程)

11. Component Life Cycle(组件的生命周期管理)

12. Resource pooling (资源池)

13. Security (安全)

14. Caching (缓存)

4、cookie和session

        一、Cookie是服务器存储在本地计算机上的小块文本，并随每一个请求发送到同一服务器。 IETF RFC 2965 HTTP状态管理机制是一种通用的cookie规范。 Web服务器使用HTTP标头将cookie发送到客户端。在客户端终端，浏览器解析cookie并将其保存为本地文件，该文件自动未来自同一服务器的任何请求绑定到这些cookie。

        具体来讲，cookie机制使用一种在客户端维护状态的方案。它是客户端会话状态的存储机制，他须要用户打开客户端的cookie支持。 Cookie的做用是解决HTTP协议中缺乏无状态缺陷的问题。

        二、session会话机制是一种服务器端机制，它使用相似于哈希表（可能还有哈希表）的结构来保存信息。

        当程序须要为客户端的请求建立会话时，服务器首先检查客户端的请求是否包含会话标识符（称为会话ID）。若是包含它，它先前已为此客户端建立了一个会话。服务器根据会话ID检索会话（没法检索，将建立新会话），若是客户端请求不包含会话ID，则为客户端建立会话并生成与会话关联的会话ID。 session id应该是一个既不重复也不容易被复制的字符串。会话ID将返回给客户端以保存此响应。

        三、Session是保存在服务器上的数据结构，用于跟踪用户的状态。此数据能够保存在群集、数据库、文件中。

        Cookie是客户端存储用户信息的机制。它用于记录有关用户的一些信息，是实现会话的一种方式。