Nginx 架构

1简介

Nginx 专注于高性能、高并发、低内存使用率。
功能：load balance，web server，caching，访问和带宽控制等等。

2高并发性为什么这么重要？

系统的并发情形在过去就一直存在，同时系统也会具有并发性，实现系统的并发性这个不难。
现在系统的并发量不断变大，那么实现系统的高并性也越发重要。

2.1高并发

2.1.1历史

过去系统并发访问不高，影响因素：Slow clients-users，通信设备等。

Slow clients-users

使用adsl通信，网速慢，下载速度慢；

通信设备

移动设备少

2.1.2原因

Internet的广泛普及
internet用户量大
网络通信方便快速
移动通信设备广泛普及
现代浏览器的行为

Another important factor contributing to increased concurrency is the changed behavior of modern browsers, which open four to six simultaneous connections to a website to improve page load speed.
以前加载一个网页，只向后端服务发送一次数据请求；如今为了加快网页数据加载速度，会同时向后端服务发送多次请求；不过这样会增加后端服务的并发量。

长连接

减少了client 与server 的通信latency,but 增加了side of server workload。

2.1.3高并发的处理方案

1.a website should be based on a number of very efficient building blocks.(高效的构建模块)

2.连接和请求限流。

3.hardware (CPU, memory, disks), network capacity, application and data storage architectures are important for web server software that client connections are accepted and processed.（硬件：资源、软件：应用和数据存储的架构）

4.数据结构、算法

5.the web server should be able to scale nonlinearly with the growing number of simultaneous connections and requests per second（随着每秒并发连接和请求数的增加，web server 应该可以非线性伸缩）。
独立的服务器，单节点资源总是有限的，避免应用不受基础资源，比如硬件资源的影响，我们的应用应该是可以伸缩的。
如何实现web server的可伸缩性？通过load balancer可以实现。
Load balancer自己如何实现高性能、高效地处理高并发？大致可以从上面说到的高并发处理方案中考虑。
同理当load balancer达到高并发处理瓶颈时，又如何实现load balancer的可伸缩性呢？一样需要寻找更强高并发处理能力的load balancer对它高并发分流。备注：可能有些load balancer不需要再依赖第三方工具，它本身就有可伸缩性能力。

Nginx基于事件驱动，不会为每一个请求而创建大量的进程或者线程。当负载增加时，内存和cpu的使用率是可控的。

在具备标准硬件的服务器上，nginx目前可以处理成千上万的并发连接。

Handling high concurrency with high performance and efficiency has always been the key benefit of deploying nginx（开发Nginx的主要目的是：高性能、高效地处理高并发）。

nginx非常适合这样做，因为它提供了一些主要的功能：高并发分流，延迟处理， SSL (secure sockets layer)，静态内容，压缩和缓存，连接和请求限流，甚至 HTTP media streaming （长连接中的数据流：from the application layer to a much more efficient edge web server layer）。还可以直接与memcahced/redis或者别的nosql解决方案集成，当服务大量的并发用户时，可以增加性能。

3架构

传统的基于进程or线程的并发处理模型包括通过一个独立单独的进程or线程来处理每个连接，以及阻塞网络or IO操作。这种架构对于内存和cpu的消耗是非常低效的。

生成一个进程或者线程需要准备一个新的执行环境，包括：heap 和stack 内存的分配；创建新的执行上下文。这些操作会花费额外的cpu时间，而且过多的线程，会出现线程上下文频繁地切换，最终导致性能低。需要有一个权衡在“提供一组丰富的通用应用特征”和“优化服务器资源利用率”之间。

Nginx的架构有更好的性能，它充分有效地利用服务器资源，受到各种操作系统基于事件的高级机制的启发。一个模块化的、事件驱动的、异步的、单线程的、非阻塞的架构。使用多路复用和事件通知，把一些特定的任务放到单独的进程去处理。连接处理是被执行在一些有限数量的worker（是一个单线程的进程）进程中一个高效的run-loop中。每一个worker每秒可以处理成千上万个并发连接和请求数。

3.1代码架构

worker code 包含：core 模块、功能模块。

3.1.1Core 模块

负责维护一个紧密的run-loop,并且在处理请求的每个阶段，选择执行相应的模块（一般指功能模块）代码。

3.1.2功能模块

由表示层和应用层功能构成。

从网络和存储系统中读写数据；
传输数据内容；
各种出站过滤器（outbound filter）;
代理请求（传送请求到上游服务）；
应用服务器端包含的操作;

Nginx 的模块化架构使开发人员扩展功能时，不用去修改core.
nginx包含的模块有：core module, event modules, phase handlers, protocols, variable handlers, filters, upstreams and load balancers.

当处理与接收、处理、和管理网络连接和内容检索相关的各种动作时，nginx使用事件通知机制和linux、solaris、和基于bsd操作系统的磁盘IO性能加强像kqueue、epoll和event ports。为了能够及时地获取到异步反馈的情况包括：
入站和出站流量；
磁盘操作；
读取socket和写socket;
超时等。

3.2Worker model

Nginx 不会为每个连接创建一个进程或者线程，通过worker从一个被共享的“listen”socket 接受新的请求，执行一个高效的run-loop 去处理成千上万的连接。Nginx服务器会存在多个worker,接收请求时，请求如何分配到哪个worker，对此，nginx并没有指定的仲裁和连接分配，这是由操作系统的内核（kernel）机制决定的。启动后，会创建一组listen sockets。当处理http请求和响应时，workers 会从sockets那accept和read，写socket.

3.2.1Run-loop

Run-loop是worker代码中最复杂的部分，包含了内部调用和异步任务处理。
异步操作是通过模块化、事件通知、回调函数和计时器来实现的。
它的主要原则是尽可能的非阻塞。Nginx唯一会被阻塞的情形是：一个worker 进程没有足够的磁盘存储器性能。

3.2.2内存使用小而有效

由于nginx不会为每个连接生成一个进程或者线程，所以在大多数情况下，内存的使用率是非常小且极其有效的。

在极端的工作负载下，nginx都可以达到低cpu使用率，理由如下：
Combined with the careful use of syscalls and an accurate implementation of supporting interfaces like pool and slab memory allocators。

3.2.3节省cpu周期

因为没有持续地创建和销毁进程或者线程。

3.2.4Nginx 的工作内容

检查网络和存储器的状态
初始化新的连接
把新连接增加到run-loop中
Run-loop异步处理连接直到完成，否则连接是不会被回收和从run-loop中移除的

3.2.5伸缩性：多worker进程

Nginx 通过生成多个worker进程来处理连接，可以跨多个cpu核心很好地实现扩展。通常，每个核心一个独立的worker可以充分利用cpu的多核架构，也可以防止thread thrashing(过度切换) and lock-ups（死锁），也不能完全避免死锁。没有资源不足，资源控制机制在单线程worker中是独立的；这种模式还可以跨物理存储设备进行更多的可伸缩性，更多的磁盘利用率，防止磁盘IO阻塞。在通过跨多个worker共享的工作负载情况下，服务器资源被更有效地利用。

3.2.6Worker 数量调整

对于某些磁盘使用和CPU负载模式，应该调整nginx worker的数量。The rules are somewhat basic here, and system administrators should try a couple of configurations for their workloads.通常建议如下：

如果ngingx 工作负载是cpu密集型的，比如：处理大量的tcp/ip连接，处理ssl,或者压缩；那么worker的数量应该和cpu
核数一样。
如果工作负载是磁盘IO密集型的，比如：从存储器读取不同的内容集，或者代理；那么worker的数量是cpu核数的1.5-2倍。
有些工程师根据单个存储单元的个数来选择workder的数量，但是这种方式的效率要依赖磁盘存储器的配置和类型。

3.2.7Nginx开发中的问题

如何防止磁盘IO上的大量阻塞

对于nginx 开发者而言，一个重大的问题需要解决：如何防止磁盘IO上的大量阻塞。

如果没有足够的存储器性能服务磁盘操作（由worker生成），那么worker会阻塞在磁盘IO上。一些机制和配置指令可以减缓磁盘IO阻塞的场景。像sendfile和aio选项的组合为磁盘性能提供很大的空间。Nginx的安装计划，应该要基于数据集、nginx可用的内存数量、底层的存储器架构。

Worker 模型的另一个问题是：嵌入式script的有限支持

3.3进程角色

一个master进程,多个worker进程，还有两个特殊用途的进程：cache loader和cache manager.在nginx 1.x版本中，所有的进程的都是单线程的。进程之间通信主要是通过共享内存机制实现的，master作为根用户运行，其它进程作为非特权用户运行。

3.3.1Master进程

主要任务：

读取,验证配置；
创建，绑定，关闭sockets;
开始，终止，维护已经配置数量的workers;
在不中断服务情况下，重新加载配置；
动态升级控制（开始新的，如果有必要可以回滚）;
重开log file;
编译嵌入的perl脚本；

3.3.2Worker 进程

主要任务：

接收，加工处理来自client的连接；
提供反向代理和过滤功能；
做几乎其它所有nginx力能所及的事件；

对于监控nginx实例的行为，系统管理员应该密切关注worker,因为它们反映了web服务器的实际日常操作的流程。

3.3.3Cache loader 进程

负责检查在磁盘上的缓存内容，使用cache元数据构建内存数据库。本质上，它是准备nginx实例去处理文件，这个文件已经存储在硬盘上的一个特定分配的目录结构中。遍历这个目录，检查缓存内容元数据，修改内存中相关联的记录，当所有的事情被清理并准备使用后，则退出。

3.3.4Cache manager 进程

负责缓存过期和失效。在正常的nginx操作过程中，它会保存在内存中，当出现故障时，master会重新启动它。

3.4缓存系统

Nginx的缓存是以在文件系统上的分层数据存储的形式实现。
缓存的keys是可配置的，不同特定的请求参数可以控制哪些数据被缓存。
缓存keys和缓存元数据被存储在共享内存块中，cache loader和cache manager可以访问这个共享内存块。Currently there is not any in-memory caching of files, other than optimizations implied by the operating system’s virtual filesystem mechanisms.每一个被缓存的响应被放置在文件系统上的不同文件中。通过nginx 配置指令来实现分层（levels and naming details）.当响应被写到缓存目录结构中是，缓存文件的路径和名称将基于代理url的md5 hash值创建。

3.4.1内存缓存的处理流程

内存缓存的处理流程，如下：
当nginx从上游服务读取响应时，响应内容首先被写到一个临时文件，位于缓存目录结构之外；当nginx完成请求处理时，会重新命名临时文件并且把它移动到缓存目录中；如果临时文件是在另外一个文件系统上，它会被复制，所以建议把临时目录和缓存目录都在同一个文件系统上；当临时目录和缓存目录被清理时，从缓存目录结构中删除文件是也是非常安全的；nginx有第三方扩展，可以远程控制缓存的内存，计划更多的工作在主发行版本中去集成这个功能。

响应数据存储在磁盘的文件系统中，响应相关的元数据存储在内存中。
如果把所有的数据都放到内存缓存，提高了访问速度，但是内存占用大。

3.5配置系统

Nginx配置系统启发于Igor Sysoev对apache的经验。他的主要观点是一个可伸缩的配置系统对于web server是不可少的。遇到的主要的伸缩问题是当对许多的virtual servers,directories,locations 和 datasets维护大量的复杂的配置时。在一个相对较大的web设置中，如果应用程序和系统工程师自己都不能正确地完成，那么这将是一场噩梦。
因此，nginx配置系统的目的是简化日常操作，并为web服务器配置的进一步扩展提供一种简单的方法。
配置文件首先被master读取并验证。worker只能读取配置不能修改。
配置文件有多个不同的context 命令块:main, http, server, upstream, location (and also mail for mail proxy)。

3.6内部组件

Nginx 代码库包含：一个core,多个moudules.

3.6.1core

core提供nginx的基础，Web和mail反向代理功能;它使用网络协议，构建必要的运行环境，确保不同模块之间的无缝交互。但是特定的协议和特定的应用特性是由moudule提供实现，core不提供实现。

3.6.2module

在内部，nginx通过module的pipeline or chain 来处理连接。换一句话说，对于每一个操作都有一个moudule来处理；比如：compression(压缩)、修改内容、连接上游服务器等。

有两个nginx模块位于核心模块和真正的“功能”模块之间：http and mail。
这两个模块在core 和 low-level 组件之间提供了抽象。它们包含了对各自的应用层协议像http、smtp等事件的处理。

与core结合，这些上层模块(http\mail)负责维护对各自的功能模块调用的正确顺序。然而http协议被实现作为http模块的一部分，未来计划把它分离到一个功能模块中，因为需要支持其它的协议like spdy。

功能模块分为:event 模块，phase hanlder, output filters,variable hanlders,protocols,upstreams和负载均衡器。这些模块大多数都补充nginx 的http功能，然而event模块和protocol也用于mail功能。Event 模块提供了特定的依赖于操作系统的通知事件机制如kqueue or epoll.
Nginx 使用的event 模块依赖操作系统的特性和构建配置。Protocols 模块允许nginx通过HTTPS, TLS/SSL, SMTP, POP3 and IMAP进行通信。

一个典型的http请求处理周期如下：
1.客户端发送http 请求；
2.Core模块选择合适的phase hanlder,它是通过location配置指定的用于请求匹配；
3.如果这样配置，load balance选择一个上游服务代理；
4.Phase hanlder 执行任务，并把output buffer 传送到第一个filter;
5.第一个filter 传送output buffer 到第二个filter;
6.第二个filter 传送它到第三个，以此类推；
7.最后响应被传送到客户端；

Nginx 模块调用是非常通用的。通过一系列的回调函数执行，这些回调函数使用指针指向可执行的函数。这样做的缺点是当程序员想要写自己的模块时，会给他们带来很大的负担，因为他们必需要明确定义模块应该执行的时间和方式。
为了减缓这种情况，nginx api和开发文档已经被改善并且更加可用。

在worker中，run-loop（响应是在run-loop中生成创建的）中的动作，如下：
1.开始执行ngx_worker_process_cycle()；
2.使用操作系统特定的机制（如kqueue or epoll）处理事件；
3.接收事件，并分配相关联的actions;
4.处理/代理请求header and body;
5.生成响应内容（header,body）,并传送到客户端；
6.完成请求；
7.Re-initialize timers and events.
The run-loop itself (steps 5 and 6) ensures incremental generation of a response and streaming it to the client.
处理http请求更加详细的视图可能如下：
1.初始化请求处理；
2.处理header;
3.处理body;
4.调用相关的handler;
5.遍历processing phases;

当nginx处理http请求时，会传送请求经过许多的processing phases。在每一个phase中会有一些hanlders调用。通常，phase hanlders 处理一个请求，并产生相应的output。phase handlers被添加到locations(在配置文件被定义)。
Phase handlers 会做四件事情：get location 配置，生成适当的响应，send header,send body。一个handler有一个参数：一个描述请求的特定的结构。这个请求结构中包含了client请求中许多有用的信息，例如请求method,uri,header。

当读取到http请求header时，nginx查找相关的虚拟服务器配置。如果虚拟服务器找到，这个请求会经过六个phase:
1.server rewrite phase;
2.Location phase;
3.Location rewrite phase(可以把请求带回到上一个phase);
4.Access control phase;
5.Try_files phase;
6.Log phase;

尝试在请求的响应中生成必要的内容，nginx把请求传送到合适的内容handler中。依赖明确的location配置，nginx首先尝试无条件调用的handler,像perl,proxy_pass,flv,mp4等，如果这个请求不匹配上面内容hanlders中的任何一个，那么选择下面handlers的一个，明确的顺序：random index,index,autoindex,gzip static,static.
在nginx文档中可以找到indexing 模块的明细，然而这些模块都是通过trailing slash(尾部斜杠/).如果一个特定的模块像mp4 or autoindex 不合适，那么内容会被当作是一个文件or目录，并且被static content handler 所提供。For a directory it would automatically rewrite the URI so that the trailing slash is always there (and then issue an HTTP redirect).

内容handlers 的内容被发送到filters.filters也是被添加到locations.一个location 可能配置多个filters.filters对output（被一个handler 生成）操作，filters的执行顺序是编译的时候指定的。对于开箱即用的filter是预定义的，对于第三方filters可以在构建阶段配置的，在现有的nginx实现中，filter仅可以改变出站。目前没有提供机制去写和添加filter转换input内容。
Input filter 会在未来的版本中出现。

Filters 遵循特殊的设计模式（filter模式）。一个filter被调用，开始执行，调用下一个filter,直到chain中最后一个filter被调用。之后filters完成响应。Filters不需要等待上一个filter完成。下一filter一旦取到上一个filter的input就可以开始执行工作。在来自上游服务的全部的响应被接收之前，生成的响应可以被发送到client.

有header filter and body filter。nginx会把响应的header和body放到相应的独立的filter中。
Header filter包含三个基本的步骤：
1.决定是否对这个响应进行操作（decide whether to operate on the response）；
2.对这个响应进行操作；
3.调用下一个filter；

Body filter 转换生成的内容，包含的动作：
server-side includes
XSLT filtering
image filtering (for instance, resizing images on the fly)
charset modification
gzip compression
chunked encoding
Filter chain 处理完之后，响应被传送到writer.连同writer有两个额外的特定用途的filter:copy filter,postpone filter.
Copy filter负责把相关响应的内容（可能被存储在一个代理的临时目录中）填充的内存 buffer中。
Postpone filter应用于subrequests.
Subrequests对于request/response处理是非常重要的机制。Subrequests也是nginx最强大方面之一。使用子请求，nginx可以从与client最初请求的URL不同的URL返回结果.一些web 框架调用内部重定向。然而，filters不仅可以执行多个subrequests和整合outpus到单个response中，而且subrequest也可以是内嵌和分层的。一个subrequest可以执行它自己的subrequests,并且一个sub-subrequest可以发起sub-sub-subrequests.subrequests可以映射到硬盘上的文件，其它的handlers,or 上游servers.subrequest大多用于insert 额外的内容（基于最初的response的data）.例如，ssi(server-side include)模块使用filter解析返回的document的内容，而且使用指定的urls的内容替换include directives.又或者比如，创建一个filter，把document 的全部内容当作是要重新取回的url,并append 这个新的文档到url它自己。

Upstream和load balancers模块也值得简要描述。Upstreams被用于实现什么可以被识别为一个content hanlder，它是一个反向代理（proxy_pass handler).
Upstream 模块主要准备把请求发送到一个upstream server (or backend),并接收来自upstream server的响应。这里没有对output filter的调用。
Upstream做的事情是：设置callbacks，以便在write和read upstream时被调用。Callback实现的功能，如下：
1.制作一个request buffer(or a chain of them)发送到upstream server.
2.重新初始化/重置upstream server的连接（再次创建请求之前发生）。
3.处理upstream响应的第一部分，并保存从upstream server接收的payloads的指针。
4.中止请求（当client贸然中止时）；
5.当nginx完成upstream server的读取时，结束请求；
6.整理response body;

当多于一个upstream server符合条件时，load balancer 通过proxy_pass hanlder 去选择一个upstream server.A load balancer registers an enabling configuration file directive,提供额外的upstream 初始化功能（解析dns中upstream names等），初始化连接结构，request路由的判定，修改统计信息。目前,nginx对于upstream servers的load balance提供了两个标准的算法：round-robin,ip-hash.

Upstream 和load balancing 处理机制包含一些算法：探测失败的upstream servers,重新路由新的请求到剩下的upstream servers(这些是没有失败的)，然而计划了很多工作去加强这个功能。通常，对load balancer计划了更多的工作，在nginx的下个版本中，跨不同的upstream servers分配load的机制和health checks 将会极大地被改善。

有两个别的有意思的模块，在配置文件中，它们提供了额外的变量集去使用。当nginx的变量被创建和跨不同的模块被修改时，有两个专用的模块用于变量：geo,map.geo模块用于促进client的跟踪，基于client的ip 地址。这个模块可以创建任意的变量，这些变量依赖于client的ip地址。Map module allows for the creation of variables from other variables,实际上是提供了hostnams和别的运行变量的灵活映射。这种module可以被称为variable hanlder.

在单个nginx worker中实现的内存分配机制，在一些程度上是受到apache的启发。Nginx内存管理高层次描述，如下：
对每一个连接，必要的内存buffers是动态分配，连接，存储和操作request和response的header和body,并且在连接release时释放。注意这一点很重要，nginx 尽可能的avoid复制内存中的data,并且大部分数据是通过指针值传递的，而不是通过调用memcpy.

深入一点，当response被一个module生成时，取到的内容被放入一个内存buffer，这个buffer被增加到一个buffer chain link中。Subrequest 使用这个buffer chain link处理工作。在nginx中，buffer chain非常复杂，因为有多个处理场景，依赖于module type 而不同。例如，当实现一个body filter module时，精确地管理buffer是非常棘手的.这样一个module同时只能操作buffer chain中的一个buffer,并且需要判断是否overwrite input buffer,是否使用新分配的buffer替换旧的buffer,或者在这个buffer出问题之前或者出问题之后，insert 一个新的buffer.更为复杂的事情是，有时一个module将会接收多个buffer,所以这个module会有一个不完整的buffer chain(module必需对它操作)。然而，这时nginx只提供了一个low-level api去操作这个buffer chain，所以任何第三方module实现之前，开发者应该要非常熟悉nginx的这神秘的部分。
根据以上的方式，需要注意的是，内存buffer被分配到连接的整个生命周期，因此长连接会保留一些额外的内存。同时，在闲置的keepalive连接上，nginx只使用550 bytes内存。Nginx未来的发布版本可能会优化：对于长连接，重用和共享内存buffer.

Nginx pool allocator管理内存分配。共享内存被用于接收mutex,cache元数据，ssl session cache以及与带宽监控和管理相关的信息。Nginx实现了一个slab分配器来管理共享内存分配。允许同时安全地使用共享内存，一些锁机制是可用的（mutex and semophore）.为了组织复杂的数据结构，nginx还提供了一个red-black 树实现。Red-black tree 用于在共享内存中保留cache元数据，
跟踪不是正则表达式（non-regex）的location 定义和处理一些其它的任务。

不幸的是，上述所有内容从未以一致和简单的方式描述过，为nginx开发第三方扩展是非常复杂的。但是在nginx内部存在一些好的文档。

不管与第三方开发相关的困难，nginx用户社会目前出现了许多的第三方modules.for instance, an embedded Lua interpreter module for nginx, additional modules for load balancing, full WebDAV support, advanced cache control and other interesting third-party work that the authors of this chapter encourage and will support in the future.

4工作流程

Nginx 架构原理相关推荐

深入浅出Nginx实战与架构原理
本文主要内容如下(让读者朋友们深入浅出地理解Nginx,有代码有示例有图): 1.Nginx是什么? 2.Nginx具有哪些功能? 3.Nginx的应用场景有哪些? 4.Nginx的衍生生态有哪些? ...
kafka和mysql内存机制_一文五分钟让你彻底理解Kafka架构原理
对于kafka的架构原理我们先提出几个问题? 1.Kafka的topic和分区内部是如何存储的,有什么特点? 2.与传统的消息系统相比,Kafka的消费模型有什么优点? 3.Kafka如何实现分布式的 ...
Nginx 架构详解
Nginx 架构详解 nginx的下篇将会更加深入的介绍nginx的实现原理.上一章,我们了解到了如何设计一个高性能服务器,那这一章将会开始讲解,nginx是如何一步一步实现高性能服务器的. Ngin ...
Nginx工作原理及相关介绍
Nginx工作原理及相关介绍一.Nginx工作原理与模块介绍 1.Nginx基本工作原理 NGINX以高性能的负载均衡器,缓存,和web服务器闻名.Nginx由内核和模块组成,其中,内核的设计非常微 ...
Nginx系列1: 正向代理和反向代理、Nginx工作原理、Nginx常用命令和升级、搭建Nginx负载均衡
一.什么是正向代理.什么是反向代理 1. 正向代理,意思是一个位于客户端和原始服务器(origin server)之间的服务器,为了从原始服务器取得内容,客户端向代理发送一个请求并指定目标(原始服务器 ...
NGINX工作原理解析
1 反向代理 1.1 概念反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给intern ...
面试官：关于负载均衡你了解多少 | Nginx面试题 | Nginx架构
面试官:关于负载均衡你了解多少,知道哪些常用框架? 问题分析: 工作中小编也会经常接触到 Nginx,比如美团的 Oceanus 框架,是一款 HTTP 服务治理框架,这个框架就是基于 Nginx和 ...
nginx工作原理和实现高并发请求的原因
一.进程.线程? 进程是具有一定独立功能的,在计算机中已经运行的程序的实体.在早期系统中(如linux 2.4以前),进程是基本运作单位,在支持线程的系统中(如windows,linux2.6)中,线 ...
阿里高可用、高并发不传之秘！Spring Cloud+Nginx架构核心编程笔记限时开源！
Spring Cloud+Nginx相结合的分布式Web应用架构已经成为IT领域应用架构的事实标准.Spring Cloud+Nginx架构具有高度可伸缩.高可用.高并发的能力,这使其成为各新产品.新 ...
初探Nginx架构之进程模型与事件处理机制
from http://tengine.taobao.org/book/chapter_2.html#connection http://blog.csdn.net/yankai0219/articl ...

Nginx 架构原理