Nginx的架构基础
为什么要讨论Nginx的架构基础尼?
因为Nginx运行在企业内网的最外层,也就是边缘节点,它处理的流量是其他应用服务器处理流量的几倍,我们知道任何一种问题在不同的数量级下解决方案是完全不同的;在Nginx它所处理的应用场景中所有的问题都会被放大,所以我们必须理解为什么Nginx采用master-worker这种架构模型;为什么worker进程的数量要和CPU的核数相匹配;当我们需要在多个worker进程间共享数据的时候;为什么在TLS或者说对一些限流,限速这样的场景,他们的共享方式是有所不同的;那么这些都需要我们对Nginx的架构有一个清晰的了解;
下面我们先来看下Nginx的请求处理流程
那么为什么要看Nginx的请求处理流程尼?
我们知道Nginx会记录access.log请求日志,记录error.log日志,也可以处理静态资源,也可以做反向代理;那么这些东西我们从nginx的内部去看,它究竟是怎么样处理这些请求?它包含一些什么样的组成部分尼?
我们从上图的最左边开始看:大致有WEB,EMAIL,TCP三种流量,进入Nginx以后,我们Nginx中有三种大的状态机;一个是处理TCP,UDP的四层的传输层状态机;和处理应用层的HTTP状态机;以及处理邮件的MAIL状态机;为什么我们叫它状态机尼?是因为Nginx核心的大的绿色的框,它是使用非阻塞的事件驱动处理引擎;也就是我们所熟知的epoll,一旦我们使用这种异步处理引擎以后尼,通常都是需要使用状态机把这个请求来正确的识别和处理的,基于这样的一种事件状态处理机尼,我们在解析出请求,需要访问静态资源的时候,走左下方的路线找到了静态资源,如果我们去做反向代理的时候尼?对反向代理的内容可以做磁盘缓存;但是我们在处理静态资源的时候会遇到一个问题。就是当整个内存不足以缓存住所有的文件信息的时候,一些调用会退化成阻塞的磁盘调用;所以在这里我们需要有一个线程池来处理;对于每一个处理完成的请求尼；我们会记录Access.log日志和Error.log日志;这里日志也是记录在磁盘中的,当然,我们也可以通过syslog协议把它记录到远程的机器上;更多的时候,我们的Nginx是作为负载均衡和反向代理来使用;这个时候我们可以把请求通过协议机传输给后面的服务器,也可以通过例如应用层的一些协议比如:FastCGI,uWSGI,SCGI,memcached 代理到相应的应用服务器;
以上这些为Nginx的请求处理流程;
