Apache-Tomcat: 虚拟主机VirtualHosts

接续此前的 “嘗試 Apache + Apache Tomcat (簡稱 Tomcat)融合” , -R/H2SL ,和 第二篇,“apache tomcat: mod_jk missing uri map”, -R/n2SK ,  这次叙述一下在 Apache 和 Tomcat 下融合搭配虚拟主机 Virtual Hosts的事, 顺带回应前述,为何技术选型是 Apache + Tomcat ,而不是 Nginx + Resin ?

1. 为何选用“Apache + Tomcat”?
单一就性能而言, Ningx 在服务静态页面胜过 Apache , Resin 在服务动态页面上胜过 Tomcat,那么强强联手,Ningx + Resin 的搭配应该会胜过 Apache + Resin. 至少理论上是这样,然而理性的技术选型中,技术性能是一方面,也会考虑经济性,这也是一些互联网公司曾经有过的关于去 IOE (IBM, ORACLE和EMC,分别代表大规模计算, 数据处理和存储)的浪潮的一个依据。

在从计算机&IT业早期,我所接触的就是 Resin 作为Java的Application Server,多年过去之后,当我再次思考这个问题的时候,我的认识发生了改变,这次我选择了 Tomcat,而不是 Resin,经济是一方面,其开源和社区属性应该是另外一面,相应地性能优势已经不是那么明显。
由于硬件性能几十年来一直以摩尔定律(单位面积上的集成电路晶体管数量每18-24个月翻一倍,性能提升而价格-成本下降)的速度在发展,如果纯粹的开源软件无需考虑这些,而如果是以一定的成本购买来的性能提升,是否该软件带来的性能提升速度能够跟得上硬件摩尔定律的发展?
设若以1000$的硬件运行A软件(1000$)获得性能为1000个并发,B软件(0$)为500个并发;一两年后,1000$的硬件自然地能够运行B软件(0$)获得1000个并发。此时如果A软件(1000$)相应地预期应该能够获得2000个并发,如果不能,我们认为这笔开支是不理性的。实际运营需求,可能对性能的要求并没有快过硬件的摩尔定律式的发展。这一问题回归,就是花成本在购置软件上的获得性能提升是否值得或者经济,尤其是在分布式,云计算大行其道的情况下? 可能的场景是,如果现在花1000$购置某闭源软件带来+500个并发性能,而1-2年后,同样的硬件成本可以0$的获得+500个并发性能,此时额外的1000$到底该不该花?

决策时的另一个考虑是,无论是 Ningx 还是 Resin 其开源版本总是给人一种“阉割版”的印象,要想要更高级的功能,都需要花钱才能实现,这多少令人不爽。开源和闭源都可能打造较好的软件,但免费推出“阉割版”,然后根据高级功能收费,这种做法,在我看来是不合适的,只好对 Ningx 和 Resin 说再见,尽管他们在性能上有优秀的表现,我更相信对 Apache 和 Tomcat 的站队投资,能促使其不断成长、优化和改进,形成良性循环。

多年来,随着 -gMIS-GWA2 的成长、成熟,从软件开发者的角度,我越来越能理解到,一款所谓好的软件,就是有人不断地使用,不断地应对新的scenarios,不断地修正bugs,从而不断地健壮、丰富和强大。Apache, Tomcat 应该也是这样,软件发展注定会是马太效应,强者更强,弱者更弱,某个细分领域,某个独特场景下,最终可能只会存在1-2款软件。

几年前,在 -人民网 进行某个互联网项目前期调研时,其中对互联网应用的发展趋势,有个小结是,互联网因的越来越具有服务方式的排他性和内容格式的统一性——大白话就是某种应用(服务)只存在其本身就够了,天下无二;在其上,各种内容兼容并包,既有文字、图片、动画,也有音频和视频,基于这些小众内容分类创新也基本不用想了。

这是今次我这么选择 Apache + Tomcat 的原因。接下来继续回复关于在 Apache 和 Tomcat 下设置虚拟主机VirtualHost的细节。

2. Tomcat 的虚拟主机配置
虚拟主机的配置,在以前的blog里提到过,”apache, resin, ssl对虚拟主机的支持”,  -R/12SY , 这次就不再重复在 Apache 里设置虚拟主机的情况,转而重点在 Tomcat 对虚拟主机的支持及设置情况.

Tomcat对虚拟主机的支持,官方文档和网上教程也有一些,下面是一个小结。

在 Tomcat 的 conf/server.xml 中,在
<Server>
    –> <Service>
        –> <Engine>
            –> <Host> 
中并列地新增一个 <Host> 标记即可。例如,默认的 <Host> 形式为

<Host name=”localhost” autoDeploy=”true” appBase=”webapps” …

在此之后,并列的新增一个针对虚拟主机的 <Host>设置,一般情况的形式为

<Host name=”srvXXX.ufqi.com” autoDeploy=”true” appBase=”/www/webroot/srvXXX”>
    <Context path=”” docBase=”/www/webroot/srvXXX”></Context>
    <!– something else –>
</Host>

其中 “<Context>” 需求强调的是,如果不通过其设置 docBase, 按 Tomcat的默认,则请求 http://srvXXX.ufqi.com/abc.jsp 时会将解析指向默认 <Host> 的默认 docBase ,通常是 默认 <Host> 的 appBase , 也即 webapps/ROOT .
通过 <Context> 设置新的 docBase之后,这可以解决这一解析寻址路径,再次请求 http://srvXXX.ufqi.com/abc.jsp 路径时,会按图索骥地在 /www/webroot/srvXXX 目录下进行寻找,从而能够获得预期的请求资源。

进一步地,由于 Tomcat 的部署默认对象单位是 application,所以即便不指定 docBase ,在 /www/webroot/srcXXX 子目录(application)下的相应资源是能够被准确定位的。上述情况,如果不指定 docBase , 通过访问路径 http://srvXXX.ufqi.com/pathX/abc.jsp 则是能够获得相应地资源的。

3. 对SSL 的支持
在设置相应的虚拟主机时,如果在 Apache 上启用了 SSL支持,可能一般情况下都会启用,而且以后会成为默认选项。
按 “apache, resin, ssl对虚拟主机的支持”,  -R/12SY  的描述需要在 Apache 的 conf/extra/http-ssl.conf 中做相应的设置,才能使得 Apache + Tomcat 对 SSL 的预期的支持。

This entry was posted in 服务器运维, 编程技术, 计算机技术 and tagged , , , . Bookmark the permalink.

发表评论

电子邮件地址不会被公开。 必填项已用*标注