Apache与Nginx在同一服务器反向代理共存端口冲突怎么办

Apache与Nginx在同一服务器反向代理共存端口冲突怎么办

很久以前,老王去饭店吃饭,需要先到饭店,七荤八素点好菜,坐等饭菜上桌,然后大快朵颐,不亦乐乎。有了第三方订餐外卖平台(代理),老王懒得动身前往饭店,老王打个电话或用APP,先选好某个饭店,再点好菜,外卖小哥会送上门来。由于某个品牌的饭店口碑特别好,食客络绎不绝涌入,第三方订餐电话也不绝于耳,但是限于饭店接待能力有限,无法提供及时服务,很多食客等得不耐烦了,纷纷铩羽而归,饭店老总看着煮熟的鸭子飞走了,心疼不已。痛定思痛,老总又成立了几个连锁饭店,形成一个集群,对外提供统一标准的菜品服务,电话订餐电话400-xxx-7777,当食客涌入饭店总台,总台将食客用大巴运到各个连锁店,这样食客既不需要排队,各连锁店都能高速运转起来,一举两得,老总乐开了花,并为此种运作模式起名为“反向代理”(Reverse Proxy)。反向代理在计算机世界里,由于单个服务器的处理客户端(用户)请求能力有一个极限,当用户的接入请求蜂拥而入时,会造成服务器忙不过来的局面,可以使用多个服务器来共同分担成千上万的用户请求,这些服务器提供相同的服务,对于用户来说,根本感觉不到任何差别。
一个典型的 Nginx + Apache 应用方案可以是Nginx 占用 80 端口,过滤静态请求,然后动态请求即 Proxy 到 Apache 的 8080 端口。Proxy 反向代理的好处是访问的时候,始终就是 80 端口,来访者不会觉察到有任何的区别。


但有的应用确非常“聪明”,识别到 Apache 所位于的端口是 8080 ,就会把相关的超链接都一并加上 :8080 的后续。这么就死定了,还能有正常访问麽?!


有个方法可以解决这事,就是把 apache 也运行在80端口上。同一台服务器,有Nginx 也有 Apache,2个httpd服务,都是80,不会冲突麽?


下边就是举例方法。
Nginx.conf 的配置中


server {
 listen 80;
 server_name www.xmc9.com;
}
修改一下。


server {
 listen 192.168.3.3:80;  #指定Nginx只占用某个IP的80端口。
 listen 192.168.10.3:80;  #如果你服务器中有多个IP,还可以指定多个。
 server_name www.xmc9.com;
}
如果你在Nginx有多个虚拟主机,每一个都需要这么修改。


然后轮到 apache 的 httpd.conf
把原来的


Listen 80
改为


Listen 127.0.0.1:80
跟Nginx一样,指定apache所占用的IP及端口。
保存退出,重启apache即可生效。
如果你 apache 上也有多个虚拟主机。无需好像Nginx那样逐一修改,只要都是 80 端口既可。


如:


NameVirtualHost *:80
<VirtualHost *:80>
 ServerAdmin [email protected]
 DocumentRoot /data/web_server/admin
 ServerName www.xmc9.com
</VirtualHost>
这样你是不是以为,就已经万事大吉了?非也。


这样的apache只能通过http://127.0.0.1:80才能访问,那么他还占用80端口就没有意义了。还不如apache用8080,nginx用80算了。
所以此时如果你的服务器有多ip,除了把apache绑定在 127.0.0.1 还能绑定另外一张网卡的IP,那么问题就解决。


可是一般人都是只有一个独立ip的,所以这种方法对很多人来讲就是海市蜃楼。
修改一种思路,apache还是8080端口,修改其中的一个nginx的域名的conf文件


location / {
 try_files $uri @apache;
}
  
location @apache {
 internal;
 proxy_pass http://127.0.0.1:8080;
}
  
location ~ .*.(php|php5)?$ {
 proxy_pass http://127.0.0.1:8080;
}
此时,该域名全部动作都走Apache了,包括静态文件。


也有很多人下面这种写法:


upstream zend {
 server 127.0.0.1:8080;
}
  
location / {
 proxy_pass  http://zend;
 proxy_redirect   off;
 proxy_set_header  Host $host;
 proxy_set_header  X-Real-IP $remote_addr;
 proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header   X-Scheme $scheme;
}
  
location ~ .*.(php|php5)?$ {
 proxy_pass  http://zend;
 proxy_redirect   off;
 proxy_set_header  Host $host;
 proxy_set_header  X-Real-IP $remote_addr;
 proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header   X-Scheme $scheme;
}
大体类似。


Nginx的端口修改
修改 nginx.conf 文件实现。在 Linux 上该文件的路径为 /usr/local/nginx/conf/nginx.conf,Windows 下 安装目录\conf\nginx.conf。


server {
 listen  80;
 server_name localhost;
  
 ……
}
改成


server {
 listen  81;
 server_name localhost;
  
 location / {
 root html;
 index index.html index.htm;
 }
 ……
}
当然改成 8080,8081 什么的都可以,不一定要 81,但是确保 iptable 要放开对该端口的访问。


注意到 location 的配置:


root html; #根目录,相对于安装目录 
index index.html index.htm; #默认主页
默认,你把文件放在安装目录下的 html 文件夹,即可通过 Nginx 访问。


Apache与Nginx的优缺点比较 
1、nginx相对于apache的优点: 
轻量级,同样起web 服务,比apache 占用更少的内存及资源 
抗并发,nginx 处理请求是异步非阻塞的,而apache 则是阻塞型的,在高并发下nginx 能保持低资源低消耗高性能 
高度模块化的设计,编写模块相对简单 
社区活跃,各种高性能模块出品迅速啊 
apache 相对于nginx 的优点: 
rewrite ,比nginx 的rewrite 强大 
模块超多,基本想到的都可以找到 
少bug ,nginx 的bug 相对较多 
超稳定 
存在就是理由,一般来说,需要性能的web 服务,用nginx 。如果不需要性能只求稳定,那就apache 吧。后者的各种功能模块实现得比前者,例如ssl 的模块就比前者好,可配置项多。这里要注意一点,epoll(freebsd 上是 kqueue )网络IO 模型是nginx 处理性能高的根本理由,但并不是所有的情况下都是epoll 大获全胜的,如果本身提供静态服务的就只有寥寥几个文件,apache 的select 模型或许比epoll 更高性能。当然,这只是根据网络IO 模型的原理作的一个假设,真正的应用还是需要实测了再说的。 


2、作为 Web 服务器:相比 Apache,Nginx 使用更少的资源,支持更多的并发连接,体现更高的效率,这点使 Nginx 尤其受到虚拟主机提供商的欢迎。在高连接并发的情况下,Nginx是Apache服务器不错的替代品: Nginx在美国是做虚拟主机生意的老板们经常选择的软件平台之一. 能够支持高达 50,000 个并发连接数的响应, 感谢Nginx为我们选择了 epoll and kqueue 作为开发模型. 
Nginx作为负载均衡服务器: Nginx 既可以在内部直接支持 Rails 和 PHP 程序对外进行服务, 也可以支持作为 HTTP代理 服务器对外进行服务. Nginx采用C进行编写, 不论是系统资源开销还是CPU使用效率都比 Perlbal 要好很多. 
作为邮件代理服务器: Nginx 同时也是一个非常优秀的邮件代理服务器(最早开发这个产品的目的之一也是作为邮件代理服务器), Last.fm 描述了成功并且美妙的使用经验. 
Nginx 是一个安装非常的简单 , 配置文件非常简洁(还能够支持perl语法), Bugs 非常少的服务器: Nginx 启动特别容易, 并且几乎可以做到7*24不间断运行,即使运行数个月也不需要重新启动. 你还能够不间断服务的情况下进行软件版本的升级 . 


3、Nginx 配置简洁, Apache 复杂 
Nginx 静态处理性能比 Apache 高 3倍以上 
Apache 对 PHP 支持比较简单,Nginx 需要配合其他后端用 
Apache 的组件比 Nginx 多 
现在 Nginx 才是 Web 服务器的首选 


4、最核心的区别在于apache是同步多进程模型,一个连接对应一个进程;nginx是异步的,多个连接(万级别)可以对应一个进程 


5、nginx处理静态文件好,耗费内存少.但无疑apache仍然是目前的主流,有很多丰富的特性.所以还需要搭配着来.当然如果能确定nginx就适合需求,那么使用nginx会是更经济的方式. 


6、从个人过往的使用情况来看,nginx的负载能力比apache高很多。最新的服务器也改用nginx了。而且nginx改完配置能-t测试一下配置有没有问题,apache重启的时候发现配置出错了,会很崩溃,改的时候都会非常小心翼翼现在看有好多集群站,前端nginx抗并发,后端apache集群,配合的也不错。 


7、nginx处理动态请求是鸡肋,一般动态请求要apache去做,nginx只适合静态和反向。 


8、從我個人的經驗來看,nginx是很不錯的前端服務器,負載性能很好,在老奔上開nginx,用webbench模擬10000個靜態文件請求毫不吃力。apache對php等語言的支持很好,此外apache有強大的支持網路,發展時間相對nginx更久,bug少但是apache有先天不支持多核心處理負載雞肋的缺點,建議使用nginx做前端,後端用apache。大型網站建議用nginx自代的集群功能 


9、Nginx优于apache的主要两点:1.Nginx本身就是一个反向代理服务器 2.Nginx支持7层负载均衡;其他的当然,Nginx可能会比apache支持更高的并发,但是根据NetCraft的统计,2011年4月的统计数据,Apache依然占有62.71%,而Nginx是7.35%,因此总得来说,Aapche依然是大部分公司的首先,因为其成熟的技术和开发社区已经也是非常不错的性能。 


10、你对web server的需求决定你的选择。大部分情况下nginx都优于APACHE,比如说静态文件处理、PHP-CGI的支持、反向代理功能、前端Cache、维持连接等等。在Apache+PHP(prefork)模式下,如果PHP处理慢或者前端压力很大的情况下,很容易出现Apache进程数飙升,从而拒绝服务的现象。 


11、可以看一下nginx lua模块:https://github.com/chaoslaw...apache比nginx多的模块,可直接用lua实现apache是最流行的,why?大多数人懒得更新到nginx或者学新事物 


12、对于nginx,我喜欢它配置文件写的很简洁,正则配置让很多事情变得简单运行效率高,占用资源少,代理功能强大,很适合做前端响应服务器 


13、Apache在处理动态有优势,Nginx并发性比较好,CPU内存占用低,如果rewrite频繁,那还是Apache吧
1.nginx负载均衡
  网站的访问量越来越大,服务器的服务模式也得进行相应的升级,比如分离出数据库服务器、分离出图片作为单独服务,这些是简单的数据的负载均衡,将压力分散到不同的机器上。有时候来自web前端的压力,也能让人十分头痛。怎样将同一个域名的访问分散到两台或更多的机器上呢?这其实就是另一种负载均衡了,nginx自身就可以做到,只需要做个简单的配置就行。
  nginx不单可以作为强大的web服务器,也可以作为一个反向代理服务器,而且nginx还可以按照调度规则实现动态、静态页面的分离,可以按照轮询、ip哈希、URL哈希、权重等多种方式对后端服务器做负载均衡,同时还支持后端服务器的健康检查。
Nginx负载均衡一些基础知识:
nginx 的 upstream目前支持 4 种方式的分配 
1)、轮询(默认) 
  每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。 
2)、weight 
  指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况。 
2)、ip_hash 
  每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。  
3)、fair(第三方) 
  按后端服务器的响应时间来分配请求,响应时间短的优先分配。  
4)、url_hash(第三方)
 
2.nginx负载均衡配置,主要是proxy_pass,upstream的使用
在http段做如下配置,即可实现两个域名
 


upstream  www.xmc9.com  
{
    server   10.0.1.50:8080;
    server   10.0.1.51:8080;
}
 
upstream  xmc9.com   
{
    server   10.0.1.50:8080;
    server   10.0.1.51:8080;
}
 
server
{
    listen  80;
    server_name  www.xmc9.com;
 
    location / {
        proxy_pass        http://www.xmc9.com;
        proxy_set_header   Host             $host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    }
}
 
server
{
    listen  80;
    server_name  xmc9.com;
 
    location / {
        proxy_pass        http://www.xmc9.com;
        proxy_set_header   Host             $host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    }
}
 
3.注意的几个小问题
3.1 多台机器间session的共享问题
配置负载均衡比较简单,但是最关键的一个问题是怎么实现多台服务器之间session的共享
下面有几种方法(以下内容来源于网络,第四种方法没有实践.)
1). 不使用session,换作cookie
  能把session改成cookie,就能避开session的一些弊端,在从前看的一本J2EE的书上,也指明在集群系统中不能用session,否则惹出祸端来就不好办。如果系统不复杂,就优先考虑能否将session去掉,改动起来非常麻烦的话,再用下面的办法。
2). 应用服务器自行实现共享
  php可以用数据库或memcached来保存session,从而在php本身建立了一个session集群,用这样的方式可以令 session保证稳定,即使某个节点有故障,session也不会丢失,适用于较为严格但请求量不高的场合。但是它的效率是不会很高的,不适用于对效率要求高的场合。
以上两个办法都跟nginx没什么关系,下面来说说用nginx该如何处理:
3).  ip_hash
  nginx中的ip_hash技术能够将某个ip的请求定向到同一台后端,这样一来这个ip下的某个客户端和某个后端就能建立起稳固的session,ip_hash是在upstream配置中定义的:
 


upstream backend {
    server 127.0.0.1:8080 ;
    server 127.0.0.1:9090 ;
    ip_hash;
}
  ip_hash是容易理解的,但是因为仅仅能用ip这个因子来分配后端,因此ip_hash是有缺陷的,不能在一些情况下使用:
  nginx不是最前端的服务器。ip_hash要求nginx一定是最前端的服务器,否则nginx得不到正确ip,就不能根据ip作hash。譬如使用的是squid为最前端,那么nginx取ip时只能得到squid的服务器ip地址,用这个地址来作分流是肯定错乱的。
  nginx的后端还有其它方式的负载均衡。假如nginx后端又有其它负载均衡,将请求又通过另外的方式分流了,那么某个客户端的请求肯定不能定位到同一台session应用服务器上。这么算起来,nginx后端只能直接指向应用服务器,或者再搭一个squid,然后指向应用服务器。最好的办法是用location作一次分流,将需要session的部分请求通过ip_hash分流,剩下的走其它后端去。
4). upstream_hash
  为了解决ip_hash的一些问题,可以使用upstream_hash这个第三方模块,这个模块多数情况下是用作url_hash的,但是并不妨碍将它用来做session共享。假如前端是squid,他会将ip加入x_forwarded_for这个http_header里,用upstream_hash可以用这个头做因子,将请求定向到指定的后端:可见这篇文档:http://www.sudone.com/nginx/nginx_url_hash.html
在文档中是使用$request_uri做因子,稍微改一下:
hash   $http_x_forwarded_for;


这样就改成了利用x_forwarded_for这个头作因子,在nginx新版本中可支持读取cookie值,所以也可以改成:
hash   $cookie_jsessionid;


  假如在php中配置的session为无cookie方式,配合nginx自己的一个userid_module模块就可以用nginx自发一个cookie,可参见userid模块的英文文档:http://wiki.nginx.org/NginxHttpUserIdModule
  另可用姚伟斌编写的模块upstream_jvm_route:http://code.google.com/p/nginx-upstream-jvm-route/
3.2 后端服务器自动加上端口的问题

  一个典型的 Nginx + Apache 应用方案可以是Nginx 占用 80 端口,过滤静态请求,然后动态请求即 Proxy 到 Apache 的 8080 端口。Proxy 反向代理的好处是访问的时候,始终就是 80端口,来访者不会觉察到有任何的区别。但有的应用确非常“聪明”,识别到 Apache 所位于的端口是 8080 ,就会把相关的超链接都一并加上 :8080 的后续。这么就死定了,还能有正常访问麽?!有个方法可以解决这事,就是把 apache 也运行在80端口上。同一台服务器,有Nginx 也有 Apache,2个httpd服务,都是80,不会冲突麽?


nginx.conf 的配置中
 


server {
    listen 80;
    server_name www.xmc9.com;
    ....
}
修改为:
 


server {
    listen 123.123.123.123:80; #指定Nginx只占用某个公网IP的80端口。
    #listen 123.123.123.124:80; #如果你服务器中有多个IP,还可以指定多个。
    server_name www.xmc9.com;
....
}
把 apache 的配置文件 httpd.conf 中的
Listen 80


改为
Listen 127.0.0.1:80


跟Nginx一样,指定apache所占用的IP及端口。

保存退出,重启apache即可生效。

小麦藏阁

猜你喜欢

转载自blog.csdn.net/my0592/article/details/80073994