设为首页 收藏本站
查看: 731|回复: 0

[经验分享] Tomcat的对象化处理和apache的统一式处理 -- 转载

[复制链接]

尚未签到

发表于 2017-1-13 06:06:13 | 显示全部楼层 |阅读模式
  tomcat是一个很优秀的轻量级的web引擎和java容器,它本身用java开发,而java是一个面向对象的语言,因此面向对象的语言开发出来的tomcat当然也就继承了面向对象的特征,tomcat还说明,OO真的使得开发变得简单,而且开发出来的产品天生就带着OO的特点,不光开发和维护本身,就连产品也OO了。反过来看apache,标准c语言开发,纯粹过程式的处理,十分符合http的处理流程,单个http请求本身的处理就是串行的过程化的,其实那个年代的东西都是这样,比如c语言,比如unix,当然还包括Tcp/ip协议族,虽然c开发的apache很稳定,性能也不错,但是它的最大的用武之地在于它对静态页面的推送,这也是http协议最基本的初衷,随着web应用日趋复杂,静态页面已经不能解决所有的问题,于是大量的动态页面出来了,像asp,php,jsp等,此时,apache本身解析并推送处理这些动态页面就有些力不从心了,毕竟这不是它的强项,即使设计了相应的模块,那么由于apache设计上的因素,对于动态页面它还是不适合的,不过由于apache性能以及稳定性的优势,它很适合做web服务器的前端,将请求定向给后端复杂的应用服务器或者动态页面容器,然后从后端接收处理后的静态元素,最终推送给客户端web浏览器。从过滤器这个web服务器的一个模块最能看出该web服务器的架构。 
     apache以往的过滤器都是连成一条链,分为输入过滤链和输出过滤链,前者可以将请求过滤而后者可以将推送给客户的内容过滤。所有的请求无一遗漏的要通过事先安好的所有的过滤钩子,这种方式虽然工作得很不错,但是由于页面都是静态的,所以缺点当然无法暴露,试想动态页面的处理结果,有些钩子只在特定的动态解析结果下起作用,对于大多数不起作用,如果将这个过滤钩子安装的话,很多处理都要在它里面白跑一趟,这很损失性能,或者说这很丑陋。apache新版本的做法是,实现了一个过滤器的动态安装,对于输出过滤器,在内容处理器处理完以后,也就是动态元素已经解析完毕,这个时候就可以根据解析的结果裁定要不要安装输出过滤器了,如果要的话,那么此时才安装,如果不要,就不安装了,而且,新的apache还可以为一个过滤器注册多个策略,在内容处理器的任务完毕之后根据结果裁决最终哪个策略作为过滤器被使用,如此一来就可以在某种意义上实现“每请求”的钩子过滤了,而不是以前的对所有的请求安装相同的过滤钩子,然后在钩子函数内部裁定对这个请求是否起作用。这可以说是apache从静态向动态发展的一项创举,但是apache天生的设计问题决定了它也只能走到这里,下面的主角该是tomcat了,它就是由于要解析动态jsp要求而生的。 
既然如此,tomcat的优势就不言自明了,它具有OO的特性,里面的模块设计得特别人性化,特别的OO,它虽然比不上apache的强大与灵活,但是它的设计我感觉比apache的要好得多,毕竟儿子终归要超越父亲的。在tomcat中实现了“每网站”配置,就是每个网站在遵循tomcat总体的大的配置之后还可以拥有自己个性的配置,总体的配置在tomcat安装目录\conf目录下,而每网站的配置在网站\WEB_INF目录下的web.xml文件,之所以如此就是因为tomcat是以动态jsp页面解析为主的,既然是动态的,那么当然需要很多的配置策略才可以进行,最起码你要告诉解析引擎在哪里可以找到一些servlet类,而每个网站使用的类很大程度上是不同的,因此每网站配置就成了必须,如此的解决方案就是,将所有网站的共性配置放到tomcat安装目录\conf\web.xml中,将个性配置放到每网站的配置中。对于过滤,tomcat也使用了不同于apache的方式,在tomcat中,解析引擎根据每网站的配置文件为每一个网站的每一个过滤器生成了一个唯一的实例,之后针对这个网站的所有的请求都使用这一个实例,如果你想设计一个过滤器针对于所有的网站,那么很好办,只需要将过滤器的代码放到所有网站共享的shared\classes目录下即可,然后再在公共的配置文件里配置过滤器,这样的好处在于可以方便的进行不同请求间的通信和同一请求的不同过滤器之间的通信,执行引擎只需要简单得将这些通信转化为类的对象之间的通信,而类的对象之间的通信在java的OO规范中有明确的定义。tomcat之所以可以如此灵活,全在于它的OO特性,在传统的apache中,一切都是以函数调用为基础的,因此很难在执行过程的层面上形象地表达真实世界,而tomcat的执行是以对象为基础的,对象的设计如果设计的好的话必然是现实世界的写照,因此执行过程才显得如此简单而易懂。 
因此可以说,apache并没有过时,它是针对http协议的,而tomcat是针对应用的,它和http协议没有冲突,如果你用tomcat作web服务器亲自处理http,那么我感觉不如用apache,如果你将tomcat作为一个serlet容器,这才是它的职责,apache和tomcat的分工是不同,apache使http协议实现的一个例子,而tomcat某种意义上是http上面的东西,为了使http更灵活,使http承载的内容更丰富,http为繁多的应用铺就了一条道路而已。简单的说,apache就是接受http请求,热后解析,最后将结果推送给客户端浏览器,这里的解析就是一个机制,具体怎么解析,http不管,而apache很多时候也是交给了可加载模块,让模块找到合适的解析者,比如tomcat,比如websphere,比如weblogic等等,这些已经不是apache本身的事情了,如果它们能如此分工的话,运行于它们之上的web网站一定很强大。

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-327558-1-1.html 上篇帖子: Apache与Tomcat整合实现动静分离与负载均衡的配置实践 下篇帖子: Tomcat的对象化处理和apache的统一式处理
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表