首页  思维导图  详情

Tomcat、Nginx等Web容器

2022-05-12 15:28:23   3  举报





AI智能生成

为你推荐

查看更多



Nginx

web

servlet tomcat spring容器关系

Tomcat、Nginx等Web容器

Tomcat

nginx

Web容器

Java

Java Web

作者其他创作

大纲/内容

Java EE WEB 服务器也称为 Java WEB 容器.

Nginx - Nginx

Nginx

Apache Webserver - Apache基金会

Apache

Apache Tomcat (Java EE)

Jetty (Java EE)

Lighthttpd

开源

IIS - 微软

Microsoft IIS

IBM Webspare (Java EE)

Oracle Weblogic (Java EE)

GWS - Google

商业

常见HTTP服务器、Web Server

一个开源的servlet容器

它为基于Java的web容器，例如JSP和servlet提供运行环境

Jetty是使用Java语言编写的，它的API以一组JAR包的形式发布。

独立运行（stand-alone）

开发人员可以将Jetty容器实例化成一个对象，可以迅速为一些独立运行的Java应用提供网络和web连接。

Jetty是什么？

1．此说明文档只对Java web开发中使用Maven管理项目时才生效；

<plugin> <groupId>org.mortbay.jetty</groupId> <artifactId>jetty-maven-plugin</artifactId> <version>8.1.8.v20121106</version> <configuration>  <webAppConfig> <contextPath>/${project.build.finalName}</contextPath> </webAppConfig> </configuration> </plugin>

2．在maven配置文件中使用jetty插件的配置语句如下：

3．在eclipse工具中运行jetty插件的语句为：package jetty:run -Dmaven.test.skip=true

子主题

4．具体运行操作选择运行项目-run as-run configurations如图1-图2所示：

Jetty和Tomcat插件使用

Jetty

<plugin> <groupId>org.apache.tomcat.maven</groupId> <artifactId>tomcat7-maven-plugin</artifactId> <version>2.2</version> <configuration> <path>/${project.build.finalName}</path>  </configuration> </plugin>

在maven配置文件中使用Tomcat插件的配置语句如下：

package tomcat7:run -Dmaven.test.skip=true

运行tomcat插件语句

别在项目构建中加入jsp-api.jar；因为tomcat已经自带这个jar包；

使用tomcat插件需要注意的问题：

Tomcat插件的配置

Server标签设置的端口号为8005，shutdown=”SHUTDOWN” ，表示在8005端口监听“SHUTDOWN”命令，如果接收到了就会关闭Tomcat。

Tomcat中只有一个Server，一个Server可以有多个Service，一个Service可以有多个Connector和一个Container；

Server掌管着整个Tomcat的生死大权；

Service 是对外提供服务的；

Connector用于接受请求并将请求封装成Request和Response来具体处理；

Container用于封装和管理Servlet，以及具体处理request请求；

Connector最底层使用的是Socket来进行连接的，Request和Response是按照HTTP协议来封装的，所以Connector同时需要实现TCP/IP协议和HTTP协议

Tomcat概述

各种操作脚本

tomcat启动参数调整

catalina

校验tomcat配置文件server.xml的格式、内容等是否合法、正确。

configtest

digest

安装tomcat服务，可用net start tomcat 启动

service

\t设置类加载路径的脚本

setclasspath

shutdown.bat

关闭tomcat实例

shutdown

startup.bat

启动tomcat实例

startup

Tomcat服务器的命令行工具包装器脚本

tool-wrapper

查看当前tomcat的版本号

version

配置文件分析

bin（执行目录）

tomcat需要的jar包

tomcat-xxx.jar

servlet.jar

lib

lib（加载的jar包目录）

server.xml

配置端口：<Connector port...

配置虚拟主机：<Engine>下添加一个<Host >

线程池名称

name

线程名称前缀

namePrefix

最大线程数

maxThreads

最小空闲线程数

minSpareThreads

Executor（线程池）

tomcat连接器端口

port

连接器协议

protocol

连接等待队列的大小

acceptCount

连接超时时间

connectionTimeout

重定向端口

redirectPort

Connector（连接器）

Connector指客户端请求服务器，tomcat需要建立、维护、管理这些连接，当Connector建立连接后，服务器会分配一个线程（可能是从线程池）去服务这个连接，即执行doPost等方法，执行完，回收线程，这是一个同步的过程，是交给tomcat的Executor去处理的

Executor与Connector的关系

Service（服务）

Server（服务器）

server.xml（核心配置文件）

web.xml

DefaultServlet（默认Servlet，加载静态文件）

JspServlet（专门处理Jsp）

mime-mapping（tomcat处理的文件类型）

web文件中的MIME.PNG

web.xml（应用程序配置文件）

context.xml

catalina.policy

权限相关 Permission ，Tomcat是跑在jvm上的，所以有些默认的权限。

catalina.policy（权限配置文件）

tomcat-users.xml

tomcat-user.xml

logging.properties

conf（配置文件目录）

这个目录中都是日志文件，记录了Tomcat启动和关闭的信息

如果启动Tomcat时有错误，那么异常也会记录在日志文件中

说明

catalina-xxx.log

控制台日志

主要记录tomcat启动时候的信息

catalina日志

主要存放利用服务方式启动tomcat作为守护进程的日志记录

commons-daemon日志

localhost-xxx.log

Web应用的内部程序日志

主要存放应用初始化未处理的异常输出的日志，同时也包含部分tomcat的启动和暂停时的运行日志

建议保留

localhost日志

localhost_access_log_xxx.log

用户请求Tomcat的访问日志（这个文件在conf/server.xml里配置）

主要存放访问tomcat的日志，记录请求时间、资源和状态码等信息

建议关闭

localhost-access日志

host-manager.xxx.log

Tomcat管理页面中的host-manager的操作日志，

主要存放tomcat的自带的manager项目的日志信息

host-manager日志

主要存放tomcat manager项目专有的日志文件

manager日志

主要存放log4j的错误日志，因此在程序中要合理的捕捉异常

tomcat7-stderr日志

主要存放程序中的System语句打印的日志（包括系统抛出的异常）

tomcat7-stdout日志

logs（日志目录）

docs

examples

hello1

hello2

host-manager

manager

ROOT：名为ROOT的应用在浏览器中访问是可以不给出应用名称，给了反而是错的

webapps

webapps（应用程序目录）

temp

存放Tomcat的临时文件

这个目录下的东西可以在停止Tomcat后删除！

temp（临时目录）

运行时生成的文件，最终运行的文件都在这里。

通过webapps中的项目生成的！可以把这个目录下的内容删除，再次运行时会生再次生成work目录。

当客户端用户访问一个JSP文件时，Tomcat会通过JSP生成Java文件，然后再编译Java文件生成class文件，生成的java和class文件都会存放到这个目录下。

Tomcat把有jsp生成Servlet放在目录下

work（运行时生成的文件）

> 许可证。

LICENSE

> 说明文件。

NOTICE

Tomcat的目录结构、文件结构

添加context元素

server.xml中的Host加入一个Context（指定路径和文件地址）

例如：<Host appBase=\"webapps\" autoDeploy=\"true\" name=\"localhost\" unpackWARs=\"true\"><Context path=\"/Demo1\" docBase=\"d:/Demo1\" reloadable=\"true\"></Context></Host>

1. 在server.xml中添加content元素方式

创建xml文件

2. 创建xml的方式

显式部署

隐式部署

将一个war文件或者整个应用程序复制到tomcat到webapps目录下

Tomcat部署模式

把web应用拷贝到webapps目录。Tomcat在启动时会加载目录下的应用，并将编译后的结果放入work目录下。

利用tomcat自动部署

在tomcat主页点击“Manager App” 进入应用管理控制台，可以指定一个web应用的路径或war文件。

使用Manager App控制台自动部署

修改conf/server.xml文件，增加Context节点可以部署应用。

修改config/server.xml文件部署

在conf/Catalina/localhost/ 路径下增加 xyz.xml文件，内容是Context节点，可以部署应用。

增加自定义的web文件部署

Tomcat部署方式

Tomcat的部署

HTTP请求的过程

Jasper

Acceptor

监听请求

从线程池中拿到线程后等待连接到来

建立连接后，将请求任务丢到线程池中等待SocketProcessor处理

Acceptor内部类

Executor

检查异步request的超时

AsyncTimeout内部类

Handler接口

如果不特殊配置，该线程池使用与Acceptor不同的池

SocketProcessor

限制最大连接数

LimitLatch

请求量较小时可考虑使用

同步阻塞 io

tomcat8.5已经去掉该io

bio

由jvm管理，不容易出现内存泄露

使用jvm堆

io多路复用

处理流程图

nio

windows内核提供了较成熟方案

如果在linux上使用该模式，是jvm在应用层模拟的

Linux暂未有商业可用的异步io

异步io

nio2

c语言实现，与内核交互效率更高

系统调用

延迟建立tcp连接直到真正的数据到来

有些操作系统不支持该配置

tcp_defer_accept

更加开放的优化配置

apr使用本地内存，nio使用jvm堆

本地内存比jvm堆少拷贝一次

缺点：本地内存比jvm堆更难管理，出现内存泄露不容易定位

Jvm堆 vs 本地内存

静态资源可考虑使用sendfile提升效率

不使用sendfile

使用sendfile

扩展：sendfile（零拷贝）

比nio快在哪里

apr

AbstractEndpoint

Endpoint（处理底层的socket网络连接）

将Endpoint接收到的Socket封装成Request

解析应用层

由Processor组件解析

解析为Request对象时只解析了请求头

真正解析请求体是在Servlet调用获取请求体内容的时候，如果一直不调用则一直不解析

http

与Apache服务器交互的协议

ajp

Processor

CoyoteAdapter

将Request交给Container进行具体的处理。

processor解析后生成Request对象，而Servlet容器需要ServletRequest对象

所以需要Adapter对Request、ServletRequest和Response、ServletResponse之间进行互转

Adapter

Mapper

ProtocolHandler

linux环境tomcat7默认使用方式

并发量高时，线程数较多，浪费资源

配制项：protocol=”HTTP/1.1”

一个线程处理一个请求

同步阻塞（BIO）

利用Java的异步IO处理，可以通过少量的线程处理大量的请求，可以复用同一个线程处理多个connection(多路复用)。

linux环境tomcat8默认使用方式

配制项：protocol=”org.apache.coyote.http11.Http11NioProtocol”

LimitLatcher

Poller

SocketPorcessor

HttpProcessor

Http11NioProtocol

Http11Nio2Protocol

同步非阻塞（NIO）

及AIO又叫NIO2

从操作系统层面解决io阻塞问题;与NIO的区别主要是操作系统的底层区别.可以做个比喻:比作快递，NIO就是网购后要自己到官网查下快递是否已经到了(可能是多次)，然后自己去取快递；AIO就是快递员送货上门了(不用关注快递进度)。

配制项：protocol=”org.apache.coyote.http11.Http11AprProtocol”

Http11AprProtocol

安装困难

配置apr模式之后还需要安装 apr 、 apr-utils 、tomcat-native包

缺点

运行高并发应用的首选模式

异步非阻塞（APR）(Apache Portable Runtime/Apache可移植运行时)

Connector运行模式

Connector连接器

不同的ProtocolHandler代表不同的连接类型

new ServerSocket(8080)

Web容器

List<Servlet>

Servlet容器

容器

每个Wrapper封装一个servlet请求

Wrapperservlet

Context(WEB-INF)

Host(webapp)

Catalina（Engine）

Pipeline

AccessLog

Realm

Container容器

server

按功能可拆分为解析http请求、管理Servlet

主要可分为两个组件：连接器和Servlet容器

功能模块

Tomcat总体架构图

四张图带你了解Tomcat系统架构

架构结构

图解Tomcat的总体架构、架构结构、架构图

该架构为硬件资源稀缺的环境下产生的，即一个应用服务器部署多个应用，现在多为微服务架构，tomcat发展方向可以简化架构

发展方向

Tomcat架构模块设计、架构解析、整体构成

有多层容器，由外到内为Engine、Host、Context、Wrapper

pipeline为valve链

在pipeline末端都有响应的BasicValve

在BasicValve中会调用子容器Pipeline的FirstValve

各容器父类ContainerBase内有pipeline

主要功能为管理子容器

各容器抽象出接口Container

使用Pipeline-Valve管道来处理（职责链模）

每个Pipeline都有特定的Valve，而且是在管道的最后一个执行，这个Valve叫做BaseValve，BaseValve是不可删除的；

在上层容器的管道的BaseValve中会调用下层容器的管道。

与普通职责链的区别

StanderEngineValve

StanderHostValve

StanderContextValve

StanderWrapperValve

四个子容器

connector调用EnginePipeline

依次会执行EngineValve1、EngineValve2等等，最后会执行StandardEngineValve，在StandardEngineValve中会调用Host管道

依次执行Host的HostValve1、HostValve2等，最后在执行StandardHostValve

再依次调用Context的管道和Wrapper的管道，最后执行到StandardWrapperValve。

当执行到StandardWrapperValve的时候，会在StandardWrapperValve中创建FilterChain，并调用其doFilter方法来处理请求，这个FilterChain包含着我们配置的与请求相匹配的Filter和Servlet，其doFilter方法会依次调用所有的Filter的doFilter方法和Servlet的service方法，这样请求就得到了处理！

当所有的Pipeline-Valve都执行完之后，并且处理完了具体的请求，这个时候就可以将返回的结果交给Connector了，Connector再通过Socket的方式将结果返回给客户端。

处理流程

Container处理请求

源码导入与调试

Server类接口关系图

Server接口由StandardServer类实现，并继承Lifecycle生命周期接口，实现对Server生命周期状态的管理

Server接口

Service类接口关系图

Service接口有StandService类实现，同样继承Lifecycle生命周期接口，实现对Service生命周期状态的管理

Service接口

Tomcat源码解析、源码解读

Tomcat启动时序图

rt.jar

BootstrapClassLoader

ext目录

ExtClassLoader

classpath目录

ApplicationClassLoader

双亲委派机制

BootstrapClassLoader 引导类加载器

ExtClassLoader 扩展类加载器

AppClassLoader 应用类加载器

CustomClassLoader 用户自定义类加载器

Bootstrap中定义类加载器

Jvm类加载器

自定义类加载器

打破双亲委派模型（没有完全打破）

判断是否在当前classloader缓存中已加载过

判断是否在parent缓存中已加载过

防止覆盖Jvm原生类

尝试使用ExtClassLoader加载

尝试自己加载，即调用findclass方法

交给parent加载

若加载失败，抛出异常

重写loadclass方法

Servlet规范建议优先加载web应用目录下的类

打破双亲委派

各web应用之间的隔离与共享

为什么要这样做

1 .tomcat可能要部署多个web项目，多个项目可以依赖同一个类库不同版本jar包，但是不同版本的jar包要进行隔离

2. 多个项目不能共享一份jar包的class，不同的项目不能直接共用同一个类加载器

3. 避免类加载器的内存泄漏

4. 服务器本身也有自己依赖的jar包

5. 多个项目如果依赖同一个类库的相同版本，tomcat提供了一个共享类加载器sharedLoader，解决这个问题

6. 实现项目热部署需要

tomcat自定义类加载器原因

WebAppClassLoader

多个web应用会有多个自己的WebAppClassLoader

web应用共享的类可以使用SharedClassLoader加载

tomcat自己目录下的类使用CatalinaClassLoader加载，与web应用隔离

web应用与tomcat共享的类可以使用CommonClassLoader加载

隔离性

Tomcat类加载器

Tomcat启动流程与类加载机制

定义：非传统的部署方式，将tomcat嵌入到主程序中进行运行

优点：灵活部署、任意指定位置、通过复杂的条件判断

调用tomcat提供的API实现，就是Tomcat.class这个类

分析它的启动

Tomcat7RunnerCli主要依靠Tomcat7Runner

进一步分析

原来嵌入式启动就是调用了Tomcat的API来实现的

分析结论

Maven集成Tomcat启动分析

Tomcat本身提供了外部可以调用的API

实现嵌入式Tomcat的基础

1. 位于：org.apache.catalina.startup.Tomcat

2. 该类由public修饰，外部可调用

3. 该类有Server、Service、Engine、Connector、Host等属性

4. 该类有init()、start()、stop()、destroy()等方法

5. 了解这个类的时候结合server.xml来理解效果更佳

Tomcat类（在Tomcat6或之前的版本，这个类叫做Embedded）

Tomcat类是外部调用Tomcat的接口（看源码的时候有注释的地方要特别注意）

分析得出的结论

tomcat API接口

1. 新建一个Tomcat对象

2. 设置Tomcat的端口号

3. 设置Context的目录

4. 添加Servlet容器

5. 调用Tomcat对象的start()方法

6. 强制Tomcat等待

手写嵌入式tomcat思路

嵌入式Tomcat

降低响应时间

提高系统吞吐量（QPS）

提高服务的可用性

性能优化的三个指标

具体情况具体分析

积少成多

性能优化的原则

内置的Java性能分析器

JConsole

基于Java的压力测试工具

JMeter

性能优化工具

原因：NIO模式最大化压榨了CPU，把时间片更好利用起来；NIO适合大量长连接

方法：连接器模式改为NIO模式

Connector优化

方法：去掉不必要的资源，例如：JspServlet；Session也可以移除

Servlet优化

原因：Valve实现都需要消耗Java应用的计算时间，一般可以使用Nginx计算日志

方法：移除掉AccessLogValve

Valve优化

原因：自动加载增加运行开销，并且很容易内存溢出

方法：关闭自动加载

Context优化

方法：配置线程池

Executor优化

方法：可以使用ant先编译Jsp

方法：Jspservlet开发模式（development）设置为false

JSP预编译优化

Tomcat中server.xml的优化

server.tomcat.max-threads

1. 设置线程池

server.tomcat.accesslog

2. 关闭Accesslog日志

SpringBoot中Tomcat的优化

Connector

Context

conf/server.xml核心组件

Listener

Global Resources

Valve

conf/server.xml非核心组件

全局的web.xml文件有些标签用不到的，可以删除掉。

conf/web.xml

JVM层面

优化思路

减少web.xml/server.xml中标签

Connector标签

Host标签

Context标签

调整优化server.xml中标签

删除没用的web应用

关闭websocket

随机数优化

多个线程启动web应用

启动速度优化

其他方面优化

优化指标

server.xml优化

web.xml优化

配置优化

CPU使用率过高

拒绝连接

常见问题排查

tomcat自带管理界面

psi-probe

线程参数

ssl

native内存

sendfile

deferAccept

Apr库

Tomcat性能优化

Lifecycle

模板模式

模版设计模式定义：模板方法模式抽象出某个业务操作公共的流程，将流程分为几个步骤，其中有一些步骤是固定不变的，有一些步骤是变化的，固定不变的步骤通过一个基类来实现，而变化的部分通过钩子方法让子类去实现，这样就实现了对系统中流程的统一化规范化管理

tomcat中的模版设计模式：tomcat中关于生命周期管理的地方很好应用了模板方法模式，在一个组件的生命周期中都会涉及到init（初始化），start（启动），stop（停止），destory（销毁），而对于每一个生命周期阶段其实都有固定一些事情要做，比如判断前置状态，设置后置状态，以及通知状态变更事件的监听者等，而这些工作其实是可以固化的，所以Tomcat中就将每个生命周期阶段公共的部分固化，然后通过initInternal，startInternal，stopInternal，destoryInternal这几个钩子方法开放给子类去实现具体的逻辑

1. 基类LifecycleBase实现了Lifecycle接口并实现init、start、stop、destroy等方法

2. init()方法内部模板化初始化流程，抽象具体的实现initInternal()方法

3. start()方法内部模板化启动流程，抽象具体的实现startInternal()方法

4. stop()方法内部模板化停止流程，抽象具体的实现stopInternal()方法

5. destroy()方法内部模板化释放流程，抽象具体的实现destroyInternal()方法

模版设计模式

模板方法

责任链

分别处理request

责任链设计模式定义：当系统在处理某个请求的时候，请求需要经过很多个节点进行处理，每个节点只关注自己的应该做的工作，做完自己的工作以后，将工作转给下一个节点进行处理，直到所有节点都处理完毕

tomcat中的责任链设计模式：tomcat中每一个容器都会有一个Pipeline，而一个Pipeline又会具有多个Valve阀门，其中StandardEngine对应的阀门是StandardEngineValve，StandardHost对应的阀门是StandardHostValve，StandardContext对应的阀门是StandardContextValve，StandardWrapper对应的阀门是StandardWrapperValve。这里每一Pipeline就好比一个管道，而每一Valve就相当于一个阀门，一个管道可以有多个阀门，而对于阀门来说有两种，一种阀门在处理完自己的事情以后，只需要将工作委托给下一个和自己在同一管道的阀门即可，第二种阀门是负责衔接各个管道的，它负责将请求传递给下个管道的第一个阀门处理，而这种阀门叫Basic阀门，它是每个管道中最后一个阀门，上面的Standard*Valve都属于第二种阀门

tomcat责任链处理过程：当用户请求服务器的时候，Connector会接受请求，从Socket连接中根据http协议解析出对应的数据，构造Request和Response对象，然后传递给后面的容器处理，顶层容器是StandardEngine，StandardEngine处理请求其实是通过容器的Pipeline进行的，而Pipeline其实最终是通过管道上的各个阀门进行的，当请求到达StandardEngineValve的时候，此阀门会将请求转发给对应StandardHost的Pipeline的第一个阀门处理，然后以此最终到达StandardHostValve阀门，它又会将请求转发给StandardContext的Pipeline的第一个阀门，这样以此类推，最后到达StandardWrapperValve，此阀门会根据Request来构建对应的Servelt，并将请求转发给对应的HttpServlet处理。从这里可以看出其实Tomcat核心处理流程就是通过责任链一步步的组装起来的

1. 请求被Connector组件接收，创建Request和Response对象

2. Connector将Request和Response交给Container，先通过Engine的Pipeline组件流经内部的每个Valve

3. 请求流转到Host的Pipeline组件中，并且经过内部Valve过滤

4. 请求流转到Context的Pipeline组件中，并且经过内部Valve过滤

5. 请求流转到Wrapper的Pipeline组件中，并且经过内部Valve过滤

6. Wrapper内部的WrapperValve创建FilterChain实例，调用指定的Servlet实例处理请求

7. 返回

过程梳理

责任链设计模式

责任链模式

观察者

Tomcat的设计模式

servlet容器是web服务器的一部分

独立的servlet容器

servlet容器是作为web服务器的插件和java容器的实现，web服务器插件在内部地址空间打开一个jvm使得java容器在内部得以运行。反应速度快但伸缩性不足；

进程内的servlet容器

servlet容器运行于web服务器之外的地址空间，并作为web服务器的插件和java容器实现的结合。反应时间不如进程内但伸缩性和稳定性比进程内优；

进程外的servlet容器

按照作为servlet容器分类

作为应用程序服务器

请求来自于web浏览器

作为独立服务器

请求模式分类

Tomcat的工作模式

IO过程

同步阻塞

同步非阻塞

多路IO复用

异步IO

阻塞式(BIO)

非阻塞式(NIO)

Tomcat中的IO模型、线程模型

浏览器通过在cookie中带着JSESSIONID或者重写URL实现会话

主从方案依赖于负载均衡，并且需要节点较多

复制方案在小集群可行，大集群会导致网络拥堵

tomcat提供了主从方案和复制session方案

tomcat提供了可配置的redis共享session

Spring大都使用Spring Redis Session方案

分布式session

由StandardContext调用StandardManager的backgroundProcess方法实现

默认每六次process清理一次session，即60s

Session清理

Context中Manager对象

Session管理

Tomcat的Sesssion会话

超链接

http://www.localhost:8080

http://127.0.0.1:8080

http://真实ip地址:8080

如果不写具体路径，默认访问ROOT下的index文件。其他资源，不写具体路径，也访问该资源下的index文件

本地访问

安装、启动

配置端口

index.html

静态网站

classes：放class文件

lib：放jar包

静态或动态页面，但此时无法被客户断访问

WEB-INF

index.jsp

静态或动态页面

动态网站

手动

Myeclipse自动生成

创建JavaWeb应用

server文件截图.png

访问路径：http://localhost:8080/hello33/index.html

添加<Context>元素

<Host>

conf/server.xml

方式1

在文件中编写<Context docBase=\"e:/hello3\"/>

创建hello33.xml

conf/Catalina/localhost

方式2

配置外部应用（了解）

1，conf/server文件中Connector元素修改端口

2，C:\\WINDOWS\\system32\\drivers\\etc\\hosts中绑定www.huangsunting.com到127.0.0.1

配置host.png

3，server文件中另外添加一个<Host>

配置虚拟主机（激情五月天）.mp4

配置虚拟主机

server文件元素介绍.PNG

Tomcat的使用

主要功能为生命周期方法，start、init、stop、destroy

各组件都有生命周期，所以抽象出接口LifeCycle

父组件负责启动子组件，只需启动Server组件，即可启动整个tomcat

类图

一键启动

StandardEngine会在init的时候使用schedule启动一个定时任务

该定时任务会调用当前容器以及子容器的backgroundprocess方法，所以各个容器可以依托该定时任务做一些操作

在执行定时任务的时候，会产生周期性的事件，说明容器还活着，可以干点什么事情

默认关闭，需要手动开启，配置loadable=true

StandardContext容器重写了backgroundProcess方法

停止和销毁context容器及其子容器（即Servlet）

停止和销毁context下的filter和listener

停止和销毁context下的pipeline和valve

停止和销毁context的classloader及其加载的类

重新启动和初始化context，以及创建前四步销毁的组件

该reload并没有调用manager相关方法，即session没有被销毁

扫描webapp目录下各个类文件是否有变更，如果有变更，调用context的reload方法

热加载

StandardHost容器注册定时任务事件监听器实现

粗粒度扫描，只扫描文件夹或者war包是否新增删除

如果扫描到文件夹被移除，则会把context销毁掉

如果扫描到有新增的文件夹，则创建context

热部署

定时任务

各个Container都有Pipeline，可以添加Valve扩展

各个Container状态改变时都有事件产生

listener

扩展方式

扩展线程池

捕获RejectedException异常后执行队列的force方法，再尝试入队一次，入队失败再抛出RejectedException

记录当前线程池任务数

重写jvm线程池的execute方法

判断线程数是否达到最大线程，是则直接尝试塞入

判断任务数是否小于当前线程数，是则直接尝试塞入

与jvm不同：当线程数没有达到最大线程数并且没有空闲线程的时候，优先创建线程

判断任务数是否大于当前线程数，是则返回false

重写offer方法

扩展LinkedBlockingQueue

线程池

Tomcat的集群

其他

Tomcat

1、适应范围较小，仅能支持http、https、Email协议。

比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，

Nginx会把上传切到另一台服务器重新处理，而LVS就直接断掉了，

如果是上传一个很大的文件或者很重要的文件的话，用户可能会因此而不满。

2、对后端服务器的健康检查，只支持通过端口检测，不支持url来检测。

Nginx缺点

1、工作在网络7层之上，可针对http应用做一些分流的策略，如针对域名、目录结构，它的正规规则比HAProxy更为强大和灵活，所以，目前为止广泛流行。2、Nginx对网络稳定性的依赖非常小，理论上能ping通就能进行负载功能。3、Nginx安装与配置比较简单，测试也比较方便，基本能把错误日志打印出来。4、可以承担高负载压力且稳定，硬件不差的情况下一般能支撑几万次的并发量，负载度比LVS小。5、Nginx可以通过端口检测到服务器内部的故障，如根据服务器处理网页返回的状态码、超时等，并会把返回错误的请求重新提交到另一个节点。6、不仅仅是优秀的负载均衡器/反向代理软件，同时也是强大的Web应用服务器。LNMP也是近些年非常流行的Web架构，在高流量环境中稳定性也很好。7、可作为中层反向代理使用。8、可作为静态网页和图片服务器。9、Nginx社区活跃，第三方模块非常多，相关的资料在网上比比皆是。

IO多路复用epoll

功能模块少

代码模块化

轻量级

CPU亲和(affinity)

Nginx优点

rpm依赖包下载地址：http://www.rpmfind.net/

对于依赖库的安装，如果环境允许，推荐是使用yum安装方式。

依赖包下载地址

openssl库 http://www.rpmfind.net/zlib库 http://www.zlib.net/pcre库 https://sourceforge.net/projects/pcre/files/pcre/

环境依赖

rpm -ivh openssl-1.0.1e-57.el6.x86_64.rpm

安装openssl库

tar -zxvf zlib-1.2.11.tar.gzcd zlib-1.2.11./configuremake && make install

安装zlib库

tar -zxvf pcre-8.41.tar.gzcd pcre-8.41./configure --prefix=/usr/local/pcre makemake install

安装pcre库

依赖包的下载

Red Hat 6.6

注意：发行版本为7.x以上的，系统服务、防火墙端口指令与旧版本不同。

系统版本

http://nginx.org/en/download.html

下载地址

Nginx （组件）

useradd -s /sbin/nologin nginx

1. 创建运行用户

注意：pcre是源码目录，不是安装后的目录，也就是解压完所得到的目录。

tar -zxvf nginx-1.12.2.tar.gzcd nginx-1.12.2./configure --prefix=/home/nginx/ --with-pcre=~/pcre-8.41 --with-http_ssl_module makemake install

2. 源码包解压安装

端口和地址，视自己情况而定

cd /home/nginx/conf/vi nginx.conf修改：listen 88 #自己分配server_name 10.219.14.115

3. 修改端口号和服务地址

cd /home/chown -R nginx:nginx nginx/

vi /home/nginx/conf/nginx.conf在文件头部，去掉注释，修改user 为nginx

在文件头部，去掉注释，修改user 为nginx

4. 修改运行用户，和添加安装目录所属用户

开放端口命令： /sbin/iptables -I INPUT -p tcp --dport 88-j ACCEPT保存：/etc/rc.d/init.d/iptables save重启服务：/etc/init.d/iptables restart

5. 开放端口

源码安装方式不提供系统服务脚本，所以我们只能新建脚本文件。

cd /etc/init.d/touch nginxvi nginxchmod +x nginxchkconfig --add nginxchkconfig --level 35 nginx on

注意修改标红的两处地方，也就是执行程序和配置文件。都是自己的安装目录下。

代码：地址——https://www.nginx.com/resources/wiki/start/topics/examples/redhatnginxinit/

6. 添加系统服务脚本

启动：service nginx start停止：service nginx stop重启：service nginx restart

7. 服务脚本命令

地址：http://10.219.14.115:88/

8. 访问

源码编译方式

wget http://nginx.org/download/nginx-1.12.2.tar.gz

useradd nginx

mkdir /usr/local/nginx

yum -y install pcre-devel openssl openssl-devel

tar -zxf nginx-1.12.2.tar.gz\tcd nginx-1.12.2\t./configure --prefix=/usr/local/nginx --user=nginx --with-http_ssl_module\tmake\tmake install

nginx -c /usr/local/nginx/conf/nginx.conf

ps -A|grep nginx

firewall-cmd --permanent --add-port=80/tcp\tfirewall-cmd --reload

http:/ip

编译安装

yum -y install nginx

安装

systemctl start nginx.service

systemctl stop nginx.service

systemctl restart nginx.service

systemctl enable nginx.service

http://ip地址

yum方式

Docker方式

安装Nginx

Nginx安装

如LVS

其实现的功能只是对请求数据包的转发、传递，

从负载均衡下的节点服务器来看，接收到的请求，还是来自访问负载均衡器的客户端的真实用户

普通的负载均衡软件

而反向代理就不一样了

反向代理服务器在接收访问用户请求后，会代理用户重新发起请求代理下的节点服务器，最后把数据返回给客户端用户。

从负载均衡下的节点服务器来看，访问的节点服务器的客户端用户就是反向代理服务器，而非真实的网站访问用户。

Nginx反向代理负载均衡

Nginx与普通负载均衡软件的区别

Nginx负载均衡功能依赖于ngx_http_upstream_module模块

ngx_http_upstream_module是负载均衡模块

可以实现网站的负载均衡功能即节点的健康检查

允许Nginx定义一组或多组节点服务器组

使用时，可通过 proxy_pass 代理方式把网站的请求发送到事先定义好的对应 Upstream组的名字上。

upstream模块

负载均衡后端RealServer的IP或者域名，端口不写的话默认为80。

高并发场景用域名，再通过DNS进行负载均衡

server ip:port

服务器权重

weight=n

权重，默认为1，权重越大接收的请求越多

weight

max_fails=n

max_fails

max_fails 和 fail_timeout 一般会关联使用，如果某台server在 fail_timeout 时间内出现了 max_fails 次连接失败，那么Nginx会认为其已经挂掉，从而在 fail_timeout 时间内不再去请求它，fail_timeout默认是 10s，max_fails默认是1，即默认情况只要是发生错误就认为服务器挂了，如果将max_fails设置为0，则表示取消这项检查

fail_timeout=10s

失败超时时间，默认是10秒，通常3s左右比较合适

fail_timeout

表示当前server是备用服务器，只有其它非backup后端服务器都挂掉了或很忙才会分配请求给它

标志服务器不可用，这个参数通常配合IP_HASH使用，保存ip哈希值

backup

热备配置，前段RealServer出现问题后会自动上线backup服务器

标志服务器永远不可用，可配合ip_hash使用

down

upstream模块内参数与参数说明

upstream lvsServer{server 191.168.1.11 weight=5 ;server 191.168.1.22:82;server example.com:8080 max_fails=2 fail_timeout=10s backup;#域名的话需要解析的哦，内网记得hosts}

完整使用案例

https://www.nginx.com/resources/admin-guide/load-balancer/

详细介绍请访问官方

upstream_module和健康检测

proxy_pass指令属于ngx_http_proxy_module模块

此模块可以将请求转发到另一台服务器，

在实际的反向代理工作中，会通过location功能匹配指定的URI，然后把接收到服务匹配URI的请求通过proyx_pass抛给定义好的upstream节点池。

location /download/ {proxy_pass http://download/vedio/;}#这是前端代理节点的设置 #交给后端upstream为download的节点

什么情况下将请求传递到下一个upstream

proxy_next_upstream

限制从后端服务器读取响应的速率

proxy_limite_rate

设置http请求header传给后端服务器节点，

如：可实现让代理后端的服务器节点获取访问客户端的这是ip

proxy_set_header

客户端请求主体缓冲区大小

client_body_buffer_size

代理与后端节点服务器连接的超时时间

proxy_connect_timeout

后端节点数据回传的超时时间

proxy_send_timeout

设置Nginx从代理的后端服务器获取信息的时间，表示连接成功建立后，Nginx等待后端服务器的响应时间

proxy_read_timeout

设置缓冲区大小

proxy_buffer_size

设置缓冲区的数量和大小

proxy_buffers

用于设置系统很忙时可以使用的proxy_buffers大小

推荐为proxy_buffers*2

proxy_busy_buffers_size

指定proxy缓存临时文件的大小

proxy_temp_file_write_size

proxy模块内参数与参数说明

proxy_pass请求转发

fastcgi_pass

memcached_pass。

支持的代理方式有

Nginx负载均衡配置（LB）

图解需要实现的效果

图解实际Nginx的配置

http { upstream my_upstream { server server1.example.com; #真实的提供服务的地址 server server2.example.com;} server { listen 80; location / { proxy_set_header Host $host; proxy_pass http://my_upstream; } }}

只需要在upstream上填写需要被访问的服务地址，和修改location

HTTP负载均衡配置

nginx支持许多应用程序负载平衡方法，用于HTTP，TCP和UDP负载平衡

请求按服务器列表顺序分发。

每一个请求按时间顺序均匀的分布到服务器中，宕机后，能自动从轮询列表中剔除

upstream backend { server backend1.example.com; server backend2.example.com;}

 Round-Robin（默认轮询）

考虑到分配给服务器的权重，将每个请求发送到活动连接数最少的服务器。

请求被发送到具有服务器权重的活动连接数最少的服务器

upstream backend { least_conn; server backend1.example.com; server backend2.example.com;}

 least_conn（最少连接）

请求根据用户定义的密钥（如客户端IP地址或URL）进行分发。

如果上游服务器组发生变化，nginx可以选择应用一致的哈希值来最小化负载的重新分配。

upstream backend { hash $request_uri consistent; server backend1.example.com; server backend2.example.com;}

 hash（哈希）

根据客户端IP地址的前三个八位字节分发请求。

根据客户端的IP地址来确定发送请求的服务器，

在这种情况下，使用IPv4地址的前三个八位字节或整个IPv6地址来计算哈希值。

该方法保证来自同一地址的请求到达同一台服务器，除非它不可用。

涉及到Session会话，可以使用该方案解决，这样同一客户端的请求都会被分发到同一台服务器上处理。

upstream backend { ip_hash; server backend1.example.com; server backend2.example.com;}

如果其中一个服务器需要临时删除，则可以使用该down参数标记，以便保留当前客户端IP地址的哈希值。

要由该服务器处理的请求将自动发送到组中的下一个服务器。

upstream backend { server backend1.example.com; server backend2.example.com; server backend3.example.com down;}

 ip_hash（ip哈希，仅限HTTP）

负载均衡方式

Nginx的负载均衡

默认情况下，nginx使用循环方法根据其权重在组内的服务器之间分配请求。

upstream backend { server backend1.example.com weight=5; server backend2.example.com; server 192.0.0.1 backup;}

指令的weight参数server设置服务器的权重，默认情况下为1：

在示例中，backend1.example.com的权重为5; 其他两台服务器的默认权重（1），

但IP地址为192.0.0.1的服务器被标记为备份服务器，除非其他服务器都不可用，否则不接收请求。

随着权重的这种配置，每六个请求，5个被送到backend1.example.com和一个backend2.example.com。

Nginx修改服务器权重

这里使用的是轮询（默认）的方法配置负载。

首先我们准备2台提供服务的地址，最好被访问的时候可以看出区别。

服务器软件不受限制，Apache，Nginx，tomcat等。 10.219.14.113：这台机提供服务的是Apache 10.219.14.112：这台机也是Nginx

准备服务主机

vi /home/nginx/conf/nginx.conf

修改Nginx负载配置，轮询的方式（默认）

开放端口命令： /sbin/iptables -I INPUT -p tcp --dport 9090-j ACCEPT保存：/etc/rc.d/init.d/iptables save重启服务：/etc/init.d/iptables restart

开放端口

输入地址后我们刷新页面可以来回切换服务器。就可以看到效果了。

测试，输入10.219.14.115，访问顺序为upstream的地址列表顺序。

Nginx负载配置演示

Nginx的功能是通过配置文件实现的，使用Nginx就是会使用Nginx的配置文件

/usr/local/nginx/conf/nginx.conf

编译安装版本

/etc/nginx/nginx.conf

yum安装版本

nginx配置文件位置

http{ http 协议通用参数 server{ 虚拟机配置参数 } server{ 虚拟机配置参数 }}

通用(全局)配置参数

ngx_core_conf_t

ngx_core_module

ngx_set_worker_processes

NGX_MAIN_CONF|NGX_DIRECT_CONF|NGX_CONF_TAKE1

worker_processes 1;

1. worker_processes

events下面

events { worker_connections 1024; }

ngx_event_conf_t

ngx_event_core_module

ngx_event_connections

NGX_EVENT_CONF|NGX_CONF_TAKE1

worker_connections 1024;

2.worker_connections

pid文件用于存储 Nginx 主进程号

3. pid

4.access_log

全局通用参数

include mime.types; default_type application/octet-stream;

ngx_conf_module

ngx_conf_include

NGX_ANY_CONF|NGX_CONF_TAKE1

NGX_HTTP_LOC_CONF_OFFSET

types

ngx_http_core_loc_conf_t

ngx_http_core_module

ngx_http_core_types

NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_BLOCK|NGX_CONF_NOARGS

include mime.types;

default_type

ngx_conf_set_str_slot

NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_TAKE1

default_type application/octet-stream;

1. ContentType

指定HTTP/1.1 协议时候的服务器端的长连接等待超时时间

keepalive_timeout

ngx_http_core_keepalive

NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_TAKE12

keepalive_timeout 65;

2. keepalive

一个是老旧浏览器(IE6)不支持

第二个会占用服务器的处理器.

但是问题有两个

3.gzip on

ngx_conf_set_flag_slot

NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_HTTP_LIF_CONF|NGX_CONF_FLAG

4.sendfile on;

ngx_http_core_server

NGX_HTTP_MAIN_CONF|NGX_CONF_BLOCK|NGX_CONF_NOARGS

NGX_HTTP_SRV_CONF_OFFSET

根据listen 子项，配置该结构

ngx_http_listen_opt_t

将ngx_http_listen_opt_t赋值为该结构体，并初始化该结构体

ngx_http_conf_addr_t

将ngx_http_core_srv_conf_t赋值给该结构体的servers

ngx_http_add_address

ngx_http_core_listen

NGX_HTTP_SRV_CONF|NGX_CONF_1MORE

listen 80;

server = cscf

name = \"localhost\"

ngx_http_core_srv_conf_t->server_names

ngx_http_core_server_name

server_name localhost;

ngx_http_core_location

NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_BLOCK|NGX_CONF_TAKE12

ngx_http_core_root

NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_HTTP_LIF_CONF|NGX_CONF_TAKE1

root html;

ngx_http_index_module

ngx_http_index_set_index

NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_1MORE

index index.html index.htm;

location /

ngx_http_core_error_page

NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_HTTP_LIF_CONF|NGX_CONF_2MORE

error_page 500 502 503 504 /50x.html;

location = /50x.html

http通用参数

Nginx配置文件nginx.conf的结构

worker_processes

worker_cpu_affinity

worker_rlimit_nofile

epoll

event module

worker_connections

涉及性能的参数

Nginx的配置

Nginx 配置文件中每个 server{} 块对应一个虚拟主机

需要为服务器指定多个域名

基于域名的虚拟主机(最常用的虚拟主机)

需要为服务器指定多个IP地址

需要租用IP

很少使用这种方式

基于IP虚拟主机

绑定到服务器的多个端口

默认80端口只有一个

基于端口的虚拟主机

三种虚拟主机

请求 t1.canglaoshi.org 访问 t1文件夹 index.html文件 server{ listen 80; server_name t1.canglaoshi.org; location / { root t1; index index.html; } }

编写nginx文件

在Nginx文件夹/usr/local/nginx中

<html> <body> <h1>Hello t1.canglaosho.org</h1> </body> </html>

添加新文件夹t1和文件index.html

Nginx的使用

测试:\thttp://t1.canglaoshi.org

测试Nginx的效果

测试使用虚拟主机

Nginx的虚拟主机

1. 下载证书文件到 /usr/local/nginx/conf/cert

3. 重新启动Nginx

4. 在客户端配置域名解析

5. 利用客户端访问 https://tts.canglaoshi.org

niginx.conf

Nginx的HTTPS加密通讯

提高网站整体的并发处理能力

优势

1. 进行合理的规划: 规定每个服务器所扮演的角色.

4. 重新启动Nginx

5. 客户端配置域名解析

nginx.conf

配置

1.配置Nginx

2. 测试重新启动nginx

4. 测试: 用浏览器访问这两个域名.

阿里云配置Nginx转发到Tomcat

1. 轮询（默认）

2.指定权重

3. ip_hash

4. fair（第三方）

5. url_hash（第三方）

Nginx 集群转发策略

Nginx的反向代理集群

反向代理(proxy_pass)

代理服务

round robin

ip hash

url hash

fair(第三方)

七层(upstream)

四层(Nginx PLUS)

负载均衡

proxy_cache

缓存

HTTPS

跨域访问

防盗链

静态资源(动态资源)

动静分离

令牌桶

漏桶

算法

limit_conn_zone

limit_req_zone

ngx_http_upstream_module

实现

限流

Openresty

Kong

Tengine

WAF

Nginx与LUA开发

Nginx的应用场景与衍生应用

按顺序将系统错误码及错误信息初始化至本地

ngx_strerror_init

处理程序启动参数

ngx_get_options

初始化nginx内部时间

ngx_time_init

根据编译时生成的参数，初始化日志

ngx_log_init

使用内存对齐的方式生成内存池

ngx_memalign

ngx_create_pool

保存启动参数到本地

ngx_save_argv

根据启动参数、编译参数，确认配置文件路径

ngx_process_options

配置系统相关选项

保存环境变量到本地，为后续修改进程名做准备

ngx_init_setproctitle

ngx_os_init

没看明白

ngx_crc32_table_init

从环境变量继承socket，没看明白怎么用

ngx_add_inherited_sockets

对module的index、name赋值

ngx_preinit_modules

初始化配置文件

ngx_init_cycle

如果为控制命令，则直接将对应信号发送至运行中的对应pid的nginx

判断是否为控制命令

初始化信号、控制命令及信号处理函数

ngx_init_signals

以守护进程方式运行

将stdin、stdout映射到/dev/null

ngx_daemon

将pid写入pid文件

ngx_create_pidfile

将stderr重定向到ngx_log_t

ngx_log_redirect_stderr

ngx_master_process_cycle

ngx_single_process_cycle

开始循环执行程序

Nginx的main

http_stub_status_module

http_random_index_module

http_sub_module

limit_conn_module

limit_req_module

http_access_module

http_auth_basic_module

proxy_pass

upstream

官方模块

memc-nginx-module

echo-nginx-module

lua-nginx-module

srcache-nginx-module

drizzle-nginx-module

rds-json-nginx-module

http_geoip_module

ngx_cache_purge

第三方模块

常见模块

Keepalive高可用的原理？

起初：为LVS设计的，专门用来监控lvs各个服务节点的状态

后来：加入了VRRP的功能，因此除了lvs，也可以作为其他服务（nginx，haproxy）的高可用软件。

keepalive的发展

virtual router redundancy protocal（虚拟路由器冗余协议）的缩写

目的：为了解决静态路由出现的单点故障，它能够保证网络可以不间断的稳定的运行

VRRP是什么？

具有LVS cluster node healthcheck

具有LVS director failover

Keepalive的功能

涉及到依赖包（系统发行版6.6以下版本1.0.0.1）

rpm依赖包下载地址：http://www.rpmfind.net/ ，搜索对应包名，查找el6系统版本。

libnfnetlink-1.0.0-1.el6.x86_64.rpmlibnfnetlink-devel-1.0.0-1.el6.x86_64.rpmlibnl-3.2.25.tar.gzlibnl-devel-1.1.4-2.el6.x86_64.rpm

环境准备

yum install libnfnetlinkyum install libnfnetlink-develyum install libnl*

有网络情况，且配置了yum源：

rpm -ivh libnfnetlink-1.0.0-1.el6.x86_64.rpm

tar -zxvf libnl-3.2.25.tar.gzcd libnl-3.2.25./configuremake && make install

无网络情况下，对应包类型的安装方法都一样：

依赖包安装

tar -zxvf keepalived-1.3.5.tar.gzcd keepalived-1.3.5./configure –prefix=/usr/local/keepalivedmakemake install

安装Keepalived

mkdir /etc/keepalived

拷贝Keepalived解压目录下的一些文件

cp /root/keepalived-1.3.5/keepalived/etc/keepalived/keepalived.conf/etc/keepalived/keepalived.conf cp /root/keepalived-1.3.5/keepalived/etc/init.d/keepalived /etc/rc.d/init.d/keepalivedcp /root/keepalived-1.3.5/keepalived/etc/sysconfig/keepalived /etc/sysconfig/ cp /usr/local/keepalived/sbin/keepalived /usr/sbin/

配置Keepalived

chkconfig --add keepalivedchkconfig --level 35 keepalived on

添加系统服务

ifconfig

查看网卡名

修改vrrp_instance VI_1中的interface 网卡名。不正确无法启动。

vi /etc/keepalived/keepalived.conf

vrrp_instance VI_1 { state MASTER interface eth1 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.200.16 192.168.200.17 192.168.200.18 }}

修改/etc/keepalived/keepalived.conf

service keepalived startps -ef | grep keepalivedroot 21769 1 0 04:07 ? 00:00:00 keepalived -Droot 21770 21769 0 04:07 ? 00:00:00 keepalived -Droot 21772 21769 0 04:07 ? 00:00:00 keepalived -Droot 21809 12328 0 04:13 pts/2 00:00:00 grep keepalived

启动Keepalived，验证

Keepalived安装

当Nginx宕机时，keepalived是无法切换到备机的，所以在检测到Nginx时，把对应的keepalived服务杀死，让它切换到备机上。

需要nmap支持，如果没有请安装。

#!/bin/bash# check nginx server statusNGINX=/home/nginx/sbin/nginxPORT=9090nmap localhost -p $PORT | grep \"$PORT/tcp open\"#echo $?if [ $? -ne 0 ];then $NGINX -s stop $NGINX sleep 3 nmap localhost -p $PORT | grep \"$PORT/tcp open\" [ $? -ne 0 ] && /etc/init.d/keepalived stopfi

脚本：

Nginx心跳健康检查脚本

采用Keepalived，通过VRRP协议将外网虚拟IP绑定到Nginx主/备机上，通过权重控制，当主机宕机后，Keepalived释放当前对主机的控制，转移到备机上。

Keepalived+Nginx高可用配置

外网VIP地址：10.219.14.200：9090Nginx服务器地址： 主机（MASTER）：10.219.14.115：9090 备机（BACKUP）：10.219.14.111：9090Server地址： 10.219.14.112：80 10.219.14.113：80

1. 规划

参考Nginx负载均衡配置。

2. 准备主/备机的Nginx配置

主/备机，只需修改state，real_server，priority这几项。

修改配置文件keepalived.conf，添加Nginx心跳检测脚本。

! Configuration File for keepalivedglobal_defs { notification_email { xxx@desay-svautomotive.com } notification_email_from xxx@desay-svauotomotive.com smtp_server 1.1.1.1 smtp_connect_timeout 30 router_id LVS_DEVEL vrrp_skip_check_adv_addr vrrp_strict vrrp_garp_interval 0 vrrp_gna_interval 0}

#Nginx服务检测脚本vrrp_script check_nginx_alive { script \"/etc/keepalived/check_nginx_alive.sh\" interval 3 weight -10}vrrp_instance VI_1 { state MASTER #备机为BACKUP interface eth1 #主/备机的网卡名需一样，若不一样请参考更改网卡名 virtual_router_id 55 priority 100 #备机比主机低即可 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 10.219.14.220 #VIP地址，一行一个 } track_script { check_nginx_alive #Nginx脚本，对应vrrp_script名字 }}virtual_server 10.219.14.220 9090 { delay_loop 3 lb_algo rr lb_kind DR persistence_timeout 50 protocol TCP real_server 10.219.14.115 9090 { #主机真实地址，对应本机IP服务 weight 1 TCP_CHECK{ connect_timeout 3 nb_get_retry 3 delay_before_retry 3 connect_port 9090 } }}

修改：其它多余的代码可以删掉。

主机（Master）10.219.14.115:9090：

3. 配置Keepalived绑定2台机器

原则上如果Keepalived的故障转移，是需要Keepalived自身宕掉，

所以我们上文中已经通过Nginx心跳监控，当Nginx宕机的时候，把Keepalived关掉，从而达到故障转移的效果。

service nginx startservice keepalived start

开启Keepalived和Nginx

ip addr show

查看当前VIP指向的Nginx

Master（主机）：10.219.14.115，可以看到VIP地址已经指向这台机器

salve（备机）：10.219.14.111

1. 当前我们指向的是10.219.14.115这台master机器，可以输入VIP地址10.219.14.220:9090测试。

查看slave备机的ip addr，也可以看到vip已经转移了，或者查看Keepalived日志。

cat /var/log/keepalived.

刷新页面：服务访问正常

2. 现在我们把10.219.14.115，Master主机的Nginx服务关闭。

宕机10.219.14.115

4. 测试高可用

! Configuration File for keepalivedglobal_defs { notification_email { xxx@xxxx.com #接受报警的邮箱地址，每行一个 } notification_email_from xxx@xxxxxx.com #发送报警的邮箱 smtp_server mail@xxxxxx.com #smtp服务器地址，可以是IP smtp_connect_timeout 30 #连接超时时间 router_id LVS_DEVEL #表示运行keepalived服务器的一个标识。发邮件时显示在邮件主题的信息 vrrp_skip_check_adv_addr vrrp_strict vrrp_garp_interval 0 vrrp_gna_interval 0}vrrp_instance VI_1 { state MASTER #指定keepalived的角色，MASTER表示此主机是主服务器，BACKUP表示此主机是备用服务器 interface eth1 #指定HA监测网络的接口名，主备需要一样 virtual_router_id 55 #虚拟路由标识，这个标识是一个数字，同一个vrrp实例使用唯一的标识。即同一vrrp_instance下，MASTER和BACKUP必须是一致的 priority 100 #定义优先级，数字越大，优先级越高，在同一个vrrp_instance下，MASTER的优先级必须大于BACKUP的优先级 advert_int 1 #设定MASTER与BACKUP负载均衡器之间同步检查的时间间隔，单位是秒 authentication { auth_type PASS #设置验证类型，主要有PASS和AH两种 auth_pass 1111 #设置验证密码，在同一个vrrp_instance下，MASTER与BACKUP必须使用相同的密码才能正常通信 } virtual_ipaddress { 10.219.14.220 #设置虚拟IP地址（VIP），可以设置多个虚拟IP地址，每行一个 }virtual_server 10.219.14.220 9090 { #设置虚拟服务器，需要指定虚拟IP地址和服务端口，IP与端口之间用空格隔开 delay_loop 6 #设置运行情况检查时间，单位是秒 lb_algo rr #设置负载调度算法，这里设置为rr，即轮询算法 lb_kind DR #设置LVS实现负载均衡的机制，有NAT、TUN、DR三个模式可选 persistence_timeout 50 #会话保持时间，单位是秒。这个选项对动态网页是非常有用的，为集群系统中的session共享提供了一个很好的解决方案。有了这个会话保持功能，用户的请求会被一直分发到某个服务节点，直到超过这个会话的保持时间。需要注意，这个会话保持时间是最大无响应超时时间，也就是说，用户在操作动态页面时，如果50秒内没有执行任何操作，那么接下来的操作会被分发到另外的节点，但是如果用户一直在操作动态页面，则不受50秒的时间限制 protocol TCP #指定转发协议类型，有TCP和UDP两种 real_server 10.219.14.115 9090 { #配置服务节点，需要指定real server的真实IP地址和端口，IP与端口之间用空格隔开 weight 1 #配置服务节点的权值，设置权值大小可以为不同性能的服务器分配不同的负载，可以为性能高的服务器设置较高的权值，而为性能较低的服务器设置相对较低的权值，这样才能合理地利用和分配系统资源 TCP_CHECK{ connect_timeout 3 #表示3秒无响应超时 nb_get_retry 3 #表示重试次数 delay_before_retry 3 #表示重试间隔 connect_port 9090 #连接端口， } }}

Keepalived.conf配置文件详解

发行版本7以上的规则不太一样。

cat /etc/redhat-releaseRed Hat Enterprise Linux Server release 6.6 (Santiago)

系统信息

查看当前网卡信息

cd /etc/udev/rules.dvi 70-persistent-net.rules

修改对应ATTR{address}物理地址的网卡名，NAME

修改70-persistent-net.rules文件

cd /etc/sysconfig/network-scriptsmv ifcfg-eth0 ifcfg-eth1vi ifcfg-eth1修改：DEVICE=eth1NAME=”System eth1”

修改网卡文件名

shutdown -r now

重启机器

主机物理网卡名更改

rpm -ivh popt-static-1.13-7.el6.x86_64.rpm

安装popt-static-1.13-7.el6.x86_64.rpm

tar -zxvf ipvsadm-1.26.tar.gzcd ipvsadm-1.26makemake install

安装ipvsadm

可以看到我们的虚拟地址和指向的真实地址

ipvsadm -L -n查看地址端口信息

使用：

ipvsadm工具安装

编译安装时，nginx自己要去编译pcre的源码

原因：

需要提供的是源码目录，而不是已经安装好的pcre目录

解决：

pcre下载地址：

5.1. Nginx编译出错，PCRE问题

请检查iptables防火墙问题，如果没有开启防火墙，在启动时，可能会被加上了DROP的规则，导致VIP拒绝所有的访问。

1. iptables问题，ping不通VIP地址，

现象：

[root@hzht113x ~]# iptables -nL --line-numberChain INPUT (policy ACCEPT)num target prot opt source destination 1 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:9092 2 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 3 DROP all -- 0.0.0.0/0 10.219.14.200 按行号删除：iptables -D INPUT 3

5.2. Keepalived无法连接问题

缺少依赖包：

5.3. 缺少依赖包：

安装问题

Nginx+Keepalived负载高可用（HA）

1.1 基本特性

1.2 基本功能

1.3 相关功能

1.4 .1 组织模型

1.4 .2 进程间通信

1.4 组织结构

1.5.1 核心模块

1.5.2 标准HTTP模块

1.5.3 可选HTTP模块

1.5.4 邮件服务模块

1.5.5 第三方模块

1.5 模块功能

1.6.1 yum部署

1.6.2 二进制部署

1.6 部署模式

1.基本概念

prefork模型

work模型

event模型

2.1.1 Apache

高性能模型

2.1.2 Nginx

2.1 Nginx与Apache

2.2.1 异步/同步

2.2.2 阻塞/非阻塞

2.2.3 模型组合

2.2 系统I/O模型

2.3.1 同步阻塞IO(blocking IO)

2.3.2 同步非阻塞IO(nonblocking IO)

2.3.3 IO多路复用(IO multipexing)

2.3.4 信号驱动式IO(signal-driven IO)

2.3.5 异步非阻塞(asynchronous IO)

2.3.6 横向IO对比

2.3.7 常用模型

2.3.8 MMAP

2.3 网路I/O模型

2.基本模型

3.1.1 全局配置

3.1.2 http配置

基于IP

基于端口

基于域名

站点模式

别名（alias）

精确匹配

区分大小

不区分大小

URI定向

文件名定向

优先级

生产案例

正则匹配（location）

站点功能（include）

四层访问控制

账号认证

自定义错误提示

日志参数

日志目录

日志配置

日志模板

并发优化

日志切割

自定义访问日志

判断文件

超时时间设置

作为下载服务器

作为上传服务器

其他配置

3.1.3 核心配置

3.1 核心配置

3.2.1 状态页面

3.2.2 三方模块

3.2.3 使用变量

3.2.4 日志目录

3.2.5 压缩功能

3.2.6 HTTP功能

3.2.7 图标显示

版本隐藏

OpenSSL升级

3.2.8 安全选项

3.2 高级配置

if指令

set指令

break指令

return指令

rewrite_log指令

3.3.1 模块语法

rewrite flag介绍

临时重定向

永久重定向

域名重定向

break案例

last案例

break与last

自动跳转HTTPS

3.3.2 指令案例

web防盗链

3.3.3 防盗链

3.3 Rewrite 重定向

配置参数

单台服务

指定location

压力测试

缓存配置

文件校验

缓存服务

多台web

IP透传

高级应用

3.4.1 HTTP反向代理

redis

mysql

负载案例

3.4.2 负载均衡（proxy）

配置指令

同环境

异环境

Nginx&&php-fpm

配置示例

配置文件

concat模块

DSO模块

tengine

3.4.3 FsatCGI

3.4.4 健康检查（check）

3.4 反向代理

3.5 参数优化

3.主机配置

4.1 LNMP-WordPress站点

集群介绍

高性能（Performance）

价格有效性（Cost-effectiveness）

可伸缩性（Scalability）

高可用性（Availability）

透明性（Transparency）

可管理性（Manageability）

可编程性（Programmability）

集群优势

负载均衡集群（Load Balancing Clusters，LBC或者LB）

高可用性集群（High-Availability Clusters，HAC）

高性能计算集群（High-Performance Clusters，HPC

网格计算（Grid Computing）

常见分类

负载均衡集群

高可用性集群

高性能计算集群

网格计算集群

不同种类

集群分类

F5、Netscaler、Radware、A10等，工作模式相当于Haproxy

成本高，不能二次开发

性能强、更稳定

优点

硬件

Nginx、LVS、Haproxy、Keepalived、Heartbeat

需要强有力的运维以及开发

可以进行二次开发，互联网行业更倾向于开源软件

软件

业务重要、技术薄弱、舍得开钱银行、证券、金融、宝马、奔驰

利润较低的中小型企业

门户网站淘宝、腾讯、新浪

混合

选型

配置简单、使用方便、安全稳定、社区活跃、市场主流

支持L4/L7，社区活跃较低

Haproxy

部署快速、配置简单、使用方便、安全稳定

Keeplived

使用较为复杂，经验到位的工程师可以进行选型

Heartbeat

高可用

中小互联网企业

LVS+Keepalived 四层转发(主备或主主) 可拓展DNS或OSPF

前端

Nginx 或 Haproxy 七层转发(支持百台级别)

后端

应用服务器

LVS+HeartbeatLVS支持TCP转发，DR模式高效，Heartbeat可以配合DRBD可以进行VIP切换，可以支持块设备级别的数据同步，可以支持资源服务管理

数据库/存储

大型互联网企业

集群选型

软硬选型

反向代理与负载均衡差异

负载均衡组件

并发调优参数

集群均衡

4.2.1 集群概念

集群规划

集群部署

集群调优

4.2.2 部署测试

4.2 集群测试

4.实际案例

Nginx做高可用的集群解决方案？

如何下线Nginx上的服务？

Nginx如何动态的增加应用服务器的节点

Nginx服务器是如何知道客户端的地址的呢？

Nginx有哪几种负载均衡策略/算法？+1

Nginx如何实现负载均衡的呢？+1

Nginx的常见问题

B/S

C/S

常见软件系统体系结构

Web资源介绍

静态资源和动态资源区别

访问Web资源

Web资源

Web服务器介绍

软件系统体系结构

负载均衡建立在现有网络结构之上

扩展网络设备和服务器的带宽

增加吞吐量

加强网络数据处理能力

提高网络的灵活性和可用性

它提供了一种廉价有效透明的方法

是什么？

没有负载平衡的简单Web应用程序环境

在此示例中，用户直接连接到您的Web服务器，在yourdomain.com上，并且没有负载平衡。

没有负载平衡的简单Web应用程序环境可能如下所示

如果您的单个Web服务器出现故障，用户将无法再访问您的Web服务器。

此外，如果许多用户试图同时访问您的服务器并且无法处理负载，他们可能会遇到缓慢的体验，或者可能根本无法连接。

无负载平衡

将网络流量负载平衡到多个服务器的最简单方法是使用第4层（传输层）负载平衡。

主要通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。

四层负载均衡（目标地址和端口交换）

负载均衡设备在接收到第一个来自客户端的SYN 请求时，

即通过上述方式选择一个最佳的服务器，并对报文中目标IP地址进行修改(改为后端服务器IP），直接转发给该服务器。

TCP的连接建立，即三次握手是客户端和服务器直接建立的，负载均衡设备只是起到一个类似路由器的转发动作。

在某些部署情况下，为保证服务器回包可以正确返回给负载均衡设备，在转发报文的同时可能还会对报文原来的源地址进行修改

以常见的TCP为例，

F5：硬件负载均衡器，功能很好，但是成本很高。lvs：重量级的四层负载软件。nginx：轻量级的四层负载软件，带缓存功能，正则表达式较灵活。haproxy：模拟四层转发，较灵活。

实现四层负载均衡的软件有：

图解四层负载均衡

4层负载平衡

（即，如果请求进入http://yourdomain.com/anything，则流量将转发到处理yourdomain.com的所有请求的后端。端口80）。

以这种方式进行负载均衡将根据IP范围和端口转发用户流量

用户访问负载均衡器，负载均衡器将用户的请求转发给后端服务器的Web后端组。

无论选择哪个后端服务器，都将直接响应用户的请求。

通常，Web后端中的所有服务器应该提供相同的内容 - 否则用户可能会收到不一致的内容。

四层负载均衡

所谓七层负载均衡，也称为“内容交换”

主要通过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。

七层负载均衡（内容交换）

是使得整个网络更智能化。

例如访问一个网站的用户流量，可以通过七层的方式，

将对图片类的请求转发到特定的图片服务器并可以使用缓存技术；

将对文字类的请求可以转发到特定的文字服务器并可以使用压缩技术。

七层应用负载的好处

HAProxy：天生负载均衡技能，全面支持七层代理，会话保持，标记，路径转移；Nginx：只在http协议和mail协议上功能比较好，性能与haproxy差不多；Apache：功能较差Mysql proxy：功能尚可。

实现七层负载均衡的软件

图解七层负载均衡

7层负载平衡是更复杂的负载均衡网络流量的方法是使用第7层（应用层）负载均衡。

使用第7层允许负载均衡器，根据用户请求的内容，将请求转发到不同的后端服务器。

示例中，如果用户请求yourdomain.com/blog，则会将其转发到博客后端，后端是一组运行博客应用程序的服务器。

其他请求被转发到web-backend，后端可能正在运行另一个应用程序。

这种负载平衡模式，允许您在同一域和端口下，运行多个Web应用程序服务器。

七层负载均衡

负载平衡的类型

负载服务器对外提供公共的访问地址，将所有访问转发到一组服务器上。从而减轻服务器的压力和确保服务的稳定提供。

负载均衡的作用

每一次来自网络的请求轮流分配给内部中的服务器，从1至N然后重新开始。

此种均衡算法适合于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况。

轮循均衡（Round Robin）

根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求。

例如：服务器A的权值被设计成1，B的权值是 3，C的权值是6，则服务器A、B、C将分别接受到10%、30％、60％的服务请求。

此种均衡算法能确保高性能的服务器得到更多的使用率，避免低性能的服务器负载过重。

负载均衡调度算法默认是 round robin，也就是轮询调度算法。

算法本身很简单，轮着一个一个来，非常简单高效公平的调度算法。

round robin 来源于法语ruban rond（round ribbon），意思是环形丝带。

在17、18世纪时法国农民希望以请愿的方式抗议国王时，通常君主的反应是将请愿书中最前面的两至三人逮捕并处决，所以很自然地没有人希望自己的名字被列在前面。为了对付这种专制的报复，人们在请愿书底部把名字签成一个圈（如同一条环状的带子），这样就找不出带头大哥，于是只能对所有参与者进行同样的惩罚。

1731年，英国皇家海军最初使用了这个名词，以循环顺序签署请愿书，这样就没法找到带头大哥了。

非常贴切有木有，后端服务器轮着来处理请求，一个个都不要抢，都要出来接受处决。

为什么轮询调度算法称为 Round Robin ？

权重轮循均衡（Weighted Round Robin）

把来自网络的请求随机分配给内部中的多个服务器。

随机均衡（Random）

此种均衡算法类似于权重轮循算法，不过在处理请求分担时是个随机选择的过程。

权重随机均衡（Weighted Random）

负载均衡设备对内部各服务器发出一个探测请求（例如Ping）

然后根据内部中各服务器对探测请求的最快响应时间，来决定哪一台服务器来响应客户端的服务请求。

优点；较好反映服务器当前运行状态

缺点：最快响应时间仅仅指的是负载均衡设备与服务器间的最快响应时间，而不是客户端与服务器间的最快响应时间。

响应速度均衡（Response Time探测时间）

最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录，记录当前该服务器正在处理的连接数量

当有新的服务连接请求时，将把当前请求分配给连接数最少的服务器，使均衡更加符合实际情况，负载更加均衡。

此种均衡算法适合长时处理的请求服务，如FTP。

最少连接数均衡（Least Connection）

此种均衡算法将把服务请求分配给内部中处理负荷（根据服务器CPU型号、CPU数量、内存大小及当前连接数等换算而成）最轻的服务器，

由于考虑到了内部服务器的处理能力及当前网络运行状况，

所以此种均衡算法相对来说更加精确，尤其适合运用到第七层（应用层）负载均衡的情况下。

处理能力均衡（CPU、内存）

在此均衡算法下，分处在不同地理位置的负载均衡设备收到同一个客户端的域名解析请求，并在同一时间内把此域名解析成各自相对应服务器的IP地址并返回给客户端，则客户端将以最先收到的域名解析IP地址来继续请求服务，而忽略其它的IP地址响应。在种均衡策略适合应用在全局负载均衡的情况下，对本地负载均衡是没有意义的。

DNS响应均衡（Flash DNS）

一致性哈希一致性Hash，相同参数的请求总是发到同一提供者。

当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

哈希算法

（保证客户端服务器对应关系稳定）

通过管理发送方IP和目的地IP地址的散列，将来自同一发送方的分组(或发送至同一目的地的分组)统一转发到相同服务器的算法。

当客户端有一系列业务需要处理而必须和一个服务器反复通信时，

该算法能够以流(会话)为单位，保证来自相同客户端的通信能够一直在同一服务器中进行处理。

IP地址散列

通过管理客户端请求URL信息的散列，将发送至相同URL的请求转发至同一服务器的算法。

URL散列

负载均衡算法/策略

LVS 的 IP 负载均衡技术是通过 IPVS 模块来实现的

IPVS 是 LVS集群系统的核心软件，

IPVS是什么？

安装在 Director Server 上，同时在 Director Server上虚拟出一个IP 地址，用户必须通过这个虚拟的 IP 地址访问服务器。

这个虚拟 IP 一般称为 LVS 的VIP，即 Virtual IP

访问的请求首先经过 VIP 到达负载调度器，然后由负载调度器从Real Server 列表中选取一个服务节点响应用户的请求。

在用户的请求到达负载调度器后，调度器如何将请求发送到提供服务的 Real Server 节点，

而 Real Server节点如何返回数据给用户，是 IPVS 实现的重点技术。

主要作用

工作于内核空间，主要用于使用户定义的策略生效

ipvs

工作于用户空间，主要用于用户定义和管理集群服务的工具

ipvsadm

IPVS

图解LVS原理

ipvs工作于内核空间的INPUT链上，当收到用户请求某集群服务时，经过PREROUTING链，经检查本机路由表，送往INPUT链；

在进入netfilter的INPUT链时，ipvs强行将请求报文通过ipvsadm定义的集群服务策略的路径改为FORWORD链，将报文转发至后端真实提供服务的主机。

LVS NAT 模式

1、NAT 技术将请求的报文和响应的报文都需要通过 LB 进行地址改写，因此网站访问量比较大的时候 LB 负载均衡调度器有比较大的瓶颈，一般要求最多之能 10-20 台节点2、只需要在 LB 上配置一个公网 IP 地址就可以了。3、每台内部的 realserver 服务器的网关地址必须是调度器 LB 的内网地址。4、NAT 模式支持对 IP 地址和端口进行转换。即用户请求的端口和真实服务器的端口可以不一致。

特点

集群中的物理服务器可以使用任何支持TCP/IP操作系统，只有负载均衡器需要一个合法的IP地址。

当服务器节点过多时，大量的数据包都交汇在负载均衡器那，速度就会变慢！

LVS DR 模式（局域网改写mac地址）

①.客户端将请求发往前端的负载均衡器，请求报文源地址是CIP，目标地址为VIP。②.负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将客户端请求报文的源MAC地址改为自己DIP的MAC地址，目标MAC改为了RIP的MAC地址，并将此包发送给RS。③.RS发现请求报文中的目的MAC是自己，就会将次报文接收下来，处理完请求报文后，将响应报文通过lo接口送给eth0网卡直接发送给客户端。注意：需要设置lo接口的VIP不能响应本地网络内的arp请求。

1、通过在调度器 LB 上修改数据包的目的 MAC 地址实现转发。注意源地址仍然是 CIP，目的地址仍然是 VIP 地址。2、请求的报文经过调度器，而 RS 响应处理后的报文无需经过调度器 LB，因此并发访问量大时使用效率很高（和 NAT 模式比）3、因为 DR 模式是通过 MAC 地址改写机制实现转发，因此所有 RS 节点和调度器 LB 只能在一个局域网里面4、RS 主机需要绑定 VIP 地址在 LO 接口（掩码32 位）上，并且需要配置 ARP 抑制。5、RS 节点的默认网关不需要配置成 LB，而是直接配置为上级路由的网关，能让 RS 直接出网就可以。6、由于 DR 模式的调度器仅做 MAC 地址的改写，所以调度器 LB 就不能改写目标端口，那么 RS 服务器就得使用和 VIP 相同的端口提供服务。7、直接对外的业务比如WEB等，RS 的IP最好是使用公网IP。对外的服务，比如数据库等最好使用内网IP。

总结

和TUN（隧道模式）一样，负载均衡器也只是分发请求，应答包通过单独的路由方法返回给客户端。与VS-TUN相比，VS-DR这种实现方式不需要隧道结构，因此可以使用大多数操作系统做为物理服务器。DR模式的效率很高，但是配置稍微复杂一点，因此对于访问量不是特别大的公司可以用haproxy/nginx取代。日1000-2000W PV或者并发请求1万一下都可以考虑用haproxy/nginx。

所有 RS 节点和调度器 LB 只能在一个局域网里面

LVS TUN 模式（IP封装、跨网段）

1.TUNNEL 模式必须在所有的 realserver 机器上面绑定 VIP 的 IP 地址2.TUNNEL 模式的 vip ------>realserver 的包通信通过 TUNNEL 模式，不管是内网和外网都能通信，所以不需要 lvs vip 跟 realserver 在同一个网段内。3.TUNNEL 模式 realserver 会把 packet 直接发给 client 不会给 lvs 了4.TUNNEL 模式走的隧道模式，所以运维起来比较难，所以一般不用。

总结：

负载均衡器只负责将请求包分发给后端节点服务器，而RS将应答包直接发给用户。所以，减少了负载均衡器的大量数据流动，负载均衡器不再是系统的瓶颈，就能处理很巨大的请求量，这种方式，一台负载均衡器能够为很多RS进行分发。而且跑在公网上就能进行不同地域的分发。

隧道模式的RS节点需要合法IP，这种方式需要所有的服务器支持”IP Tunneling”(IP Encapsulation)协议，服务器可能只局限在部分Linux系统上。

缺点：

无论是 DR 还是 NAT 模式，不可避免的都有一个问题：LVS 和 RS 必须在同一个 VLAN 下，否则 LVS 无法作为 RS 的网关。这引发的两个问题是：1、同一个 VLAN 的限制导致运维不方便，跨 VLAN 的 RS 无法接入。2、LVS 的水平扩展受到制约。当 RS 水平扩容时，总有一天其上的单点 LVS 会成为瓶颈。Full-NAT 由此而生，解决的是 LVS 和 RS 跨 VLAN 的问题，而跨 VLAN 问题解决后，LVS 和 RS 不再存在 VLAN 上的从属关系，可以做到多个 LVS 对应多个 RS，解决水平扩容的问题。Full-NAT 相比 NAT 的主要改进是，在 SNAT/DNAT 的基础上，加上另一种转换，转换过程如下：

1. FULL NAT 模式不需要 LBIP 和 realserver ip 在同一个网段；2. full nat 因为要更新 sorce ip 所以性能正常比 nat 模式下降 10%

LVS FULLNAT模式

LVS原理

LVS

Open API 即开放 API，也称开放平台。

所谓的开放 API（OpenAPI）是服务型网站常见的一种应用，网站的服务商将自己的网站服务封装成一系列API（Application Programming Interface，应用编程接口）开放出去，供第三方开发者使用，这种行为就叫做开放网站的 API，所开放的 API 就被称作 OpenAPI（开放 API ）。

OpenAPI 是什么?

传统第三方接入

项目访问路径完全暴露给第三方无法对接入请求做到统一权限把控无法对多协议请求做到统一分发（异构）需重复考虑系统流控，如流量分流

现状

Open-api接入

让后端系统服务专注于业务的处理，提高开发效率，降低开发成本实现请求的标准化接入，隐藏项目真实访问路径实现接口统一权限把控实现对多协议请求进行统一分发处理认证授权，安全管控的服务功能前置，提高服务质量

解决

OpenAPI现状及解决

统一从Open-api网关接入

统一入口

应用服务是指不同的业务接口，如获取订单列表接口、支付接口、智能场景设置接口等。

通过配置应用服务的所属服务中心、服务方法、协议等实现对不同业务请求的具体分发。

应用服务配置

服务中心是指不同的第三方平台，如CMS、Lion、DEQMock平台。

通过配置服务中心的具体实现类全限定类名或者远程地址，实现对不同服务中心的业务请求分发。

服务中心配置

应用接口是指对商户进行平台接口访问权限的配置。

可通过设置接口的调用次数上限、调用次数统计周期、调用次数超限处理策略对商户访问接口进行严格的权限把控。

应用接口配置

应用信息是指赋予商户对网关平台的访问权限，实现对商户访问平台接口的权限把控。

商户可通过向平台申请的应用信息接入网关平台。

应用信息配置

四项应用配置

认证中心

一个服务支撑中心

检查传入Context对象中的参数，如是否为空；检查应用ID appId是否合法；检查加解密密钥appKey是否合法；检查服务编码是否合法。

01 流程处理前置

记录应用ID appId的调用次数；

记录服务编码processCode的调用次数；

根据服务编码检查调用次数是否超过设置的调用次数上限。超过调用次数上限后，根据设置的处理方式选择预警还是拒绝调用者访问接口；

02 访问控制

检查调用服务的调用者IP及端口号是否处在白名单中。如果不处在白名单中，记录接入的appId的调用次数信息。

03 黑白名单

根据服务编码找到对应的服务处理类，并将请求分发到对应的服务中心的具体接口。

04 路由分发

处理请求第三方平台接口的返回数据，根据服务编码配置决定是否需要对返回数据进行解密处理等。

05 流程处理后置

五大流程管控职责链

流程管控是指对接入Open-api网关平台的请求做一系列的前置操作

流程管控

Open-api系统管理平台

一个可视化平台

应用统计黑名单统计应用调用排行服务统计远程服务统计服务调用排行

用于统计当前接入Open-api网关平台黑名单数量

黑名单统计

用于统计当前接入Open-api网关平台商户应用数量

应用统计

用于统计当前接入Open-api网关平台应用调用次数Top5的商户应用信息

应用调用排行

用于统计当前接入Open-api网关平台服务调用次数Top5的服务信息

服务调用排行

用于统计当前Open-api网关平台接入服务数量

服务统计

用于统计当前Open-api网关平台接入服务中心数量

远程服务统计

六个维度的数据统计与分析

可同时接入多项目，并具体划分文档版本号

版本项目划分

提供接口请求参数、响应参数、接口地址、具体请求及响应示例等接口详细信息介绍

接口详细信息介绍

对接口进行类型组别划分，支持自定义组别设置

接口类型组别划分

支持接口变更热发布，摒除传统文档手动更新的烦恼

接口变更热发布

在线文档

OpenAPI整体组成

OpenAPI网关

锤子科技在 T2 发布会上将门票收入捐赠给了 OpenResty 开源项目，今天我们就来为大家介绍下 OpenResty 是个什么鬼？

OpenResty 使用介绍

OpenResty 安装

安装成功后，我们就可以使用 openresty 直接输出 html 页面。首先我们可以创建一个工作目录：mkdir /home/wwwcd /home/www/mkdir logs/ conf/其中 logs 目录用于存放日志，conf 用于存放配置文件。接着，我们在 conf 目录下创建一个 nginx.conf 文件代码如下：worker_processes 1;error_log logs/error.log;events { worker_connections 1024;}http { server { listen 9000; location / { default_type text/html; content_by_lua ' ngx.say(\

Hello World 实例

启动 openresty

OpenResty 英文官网：http://openresty.org/OpenResty 中文官网：http://openresty.org/cn/Nginx 维基官网：http://wiki.nginx.org/Lua 入门教程：https://www.runoob.com/lua/lua-tutorial.html