【云计算专家Joseph Ottinger系列】应用服务器本质论

<!----><!----> <!---->

原文请看： http://www.theserverside.com/tt/articles/article.tss?l=WhatIsAnAppServer

 

 

作者简介：

Joseph Ottinger 是一名工程师，目前受雇于 GigaSpaces 　 Technologies ，该公司致力于提供云计算的解决方案。你可以通过 [email protected] . 给他发邮件。

 

 

正文

 

重新给“应用服务器”下一个定义的确有必要——因为每个人对这个术语的理解如同“一千个读者，一千个哈姆雷特”。那么我们不禁要问：究竟什么才是应用服务器？如果具备下列属性特征就算应用器吗？

 

<!---->l         <!---->为 web 页面服务

<!---->l         <!---->为应用程序提供容器模型

<!---->l         <!---->为应用程序提供服务

<!---->l         <!---->受到工业领域规范的约束

<!---->l         <!---->可跨多个物理服务器分发请求

<!---->l         <!---->提供管理或布署工具

 

 

大多数读者认为 Java 应用服务器其实不过提供的是 servlet 规范的一种具体实现，也许还包括 JSP 规范的实现，或者还包括一些诸如数据连接池这样的服务等。应用服务器之间都差不多，但是它们都有一个共同点：不会在乎应用程序是什么，可以做什么，应用服务器都可以为它们提供的运行环境。

 

 

现实的 Java EE 世界中，应用服务器的定义不仅仅是 servlets ， JSP ，数据连接池。这些不过是 JavaEE 容器模型中的组成部分。应用程序通常会被折分成服务器端和客户端两部分，而服务器端又可以由不同的容器组成，从而为应用程序提供各种不同的服务。有展现前端的用户接口 servlet 容器，有管理业务逻辑的 EJB 容器，还有 JNDI ，消息服务，允许访问非 JAVA 的适配器服务，安全容器 ….. 大多了。

 

 

因为 Java EE 设计的初衷是能够处理大型复杂的应用程序，可以这么说它的容器模型已经达到让人瞠目结舌的复杂程度了。即使是高级开发人员，（要完全掌握某种应用服务器）也是一个不小的挑战。

 

 

大多数的应用程序只用到了应用服务器的一两个方面，通常集中在 servlets 和数据库连接池上。像 Spring 这样框架的兴起，更加使得容器模型变得多余。使用应用服务器是需要成本的，有了它后应用程序可以从先前自己管理资源的方案中解脱出来（比如说原来数据库连接池需要开发人员亲自处理，有了 JNDI 服务后，就可以交给应用服务器了，强调一下，这里指的是传统 J2EE 开发，不包括使用了 Spring 等 IoC 容器 ）。同时依赖注入的框架又大大简化了开发模型，使得原本那些可能的缺陷都可以弥补。（实际上，大多数关于 J2EE 开发模型的抨击围绕的中心就是配置和布署的出奇复杂）

 

 

 

这样造成的结果就是如果一个应用程序使用应用服务器的服务越少，那么对应用服务器的定义就会变得越简单。对于一个传统的 J2EE 开发人员来说，只要有涉及到用 Tomat 作为服务器的话，那么就会觉得这是一件很恐怖的事。现在，在一些更简单的开发模型下， Tomcat 和 Jettry 都可被认为是“应用服务器”（尽管严格意义上不是）。

 

 

现在的问题是 JavaEE 规范和 profiles 的观念始终与请求 / 响应的概念绑定在一起。当浏览器或客户端通过 HTTP 或 CORBA 或其它传输协议发过来一个请求，服务器接收过来，进行处理，然后进行响应。

 

 

这有什么严重的问题吗？当然没有，世上 99% 以上的应用程序适合这个模型 。那也许就是为什么有什么样的工具，就会用它上构建什么样系统——好比如，当你面对一大把钉子的时候，你会去用螺丝刀去处理它们吗（当然是用锤子啦）？但那只是在通常情况，基于请求 / 响应模型，使用 HTTP 作为传输协议的解决方案适合于绝大多数应用程序。要不然，人们早就废弃这种模型机制了。

 

 

尽管如此，有些应用程序 ( 或任务 ) 在此模型上并不适用。 JavaEE 规范已经开始意识到这点，于就是推出了个 EJB timers ，来实现计划调度。

 

 

实际上， EJB timers 是 JavaEE 的一个巨大进步。

 

 

J2EE( 早期规范的命名，从 2005 年后正式取消了版本号，改为 JavaEE) 通过 JCA 规范，将其托管各种组件发挥的淋漓尽致，比如说建立线程，访问文件系统，控制外部请求或操作邮件服务器等。

 

 

但是，一旦有了 EJB timers ，就不再需要产生大量线程来监听 time lapse ( 调度程序的时间时隔 ) 。不过请注意，这并不意味着不再需要 JCA 组件了，而是相对于 JCA 组件，在对待处理大多数普通的需求来说， EJB timers 已经绰绰有余了。

 

 

 

尽管如此， EJB timers 和 JCA 组件都是很了不起的推动者，并且如果与一个实现不错的 JMS 容器配合使用时，会让 JavaEE 程序得到很大程度的扩展。但这一切仍然表明： JavaEE 规范瞄准仅仅是广泛的普通 (middle ground ，主要是指需求没有什么特别之处 ) 应用程序。这一点倒是无可厚非，毕竟对绝大多数应用程序来都是普通的，所使用 J2EE 就足够了。

 

 

话虽如此，对某些应用程序来说，即使是 servlet 引擎也算是“重量级”的。因为这些应用程序需要的是“实时性”，或者需要通过向上扩展来处理惊人的负载。 JavaEE 还没有真正的满足这样的需求。

 

 

Java 目前的情况是一系列这样那样的规范，这样基于规范的实现导致了一些有趣的问题。要不要举个例子？看看 http://blog.griddynamics.com/2008/07/gridgain-on-ec2.html 上的

“在 Amazon EC2 上用 GridGain 软件模拟 Monte Carlo 的 Scalability Benchmark 测试。”该 Benchmark 测试将一个计算密集型的算法运行在 512 个 EC2 实例上 ，并且还宣称在超过 256 个实例后，仅仅只有 20% 的性能下降 。

 

 

那听起来，太不可思议了 ( 你知道，这一块往往是 JMS 容器的瓶颈 ) 。它的任务其实就是不停的分发新的数据，只有 20% 的性能损失，真的很完美啊。注意，目前只有一个 JMS 容器（ Sun 的 Open MQ ）被测试过，虽然使用了 ActiveMQ ，但仍然免不了出现扩展问题。其它 JMS 容器也许比 Sun 做的好点，但结果还是不容乐观。

 

 

这里我要澄清一点：我不是想责备 JMS ，它只是一个规范。既然这样的话，要怪也只能怪实现这个规范的容器了——但人们往往又很少去考虑或者衡量容器的实际影响，假设他们可以使用容器 X ，那么就用得这个容器。这个失效期望 (failure of expectation) 与平台是无关的，但平台有义务去调整这个期望。

 

 

Grid Dynamics benchmark 测试是完全符合逻辑的，但是使用网格 (grid) 还会拥有更大的潜力。 Grid Dynamics 的测试还远远没有展现出网格应有的强大力量。（ Nikita Ivanov 说这个测试其实就是想证明 Amazon EC2 具备针对同一个应用程序，可运行 512 个结点的能力。）但是，如果你可以这么轻而易举的向外扩展 (scale out) 并管理网格上的事务和数据的话，那线性扩展 (scale linearly) 不就意味着只要你负担的起硬件设备（不管是一台只有 300 美元的桌面 PC ，还是按小时付费的 EC2 结点），你的计算能力不就可以大大增强了吗 ？

 

 

目前，网格的挑战主要来自下面三个方面：架构 (architecture) ，编码学 (coding methodologies) 和布署 (deployment) ：

 

 

<!---->l         <!---->架构的改变并对网格造成的影响并不是很大，因为开发人员总是趋向于接受架构本身的限制，而这些限制又恰巧不是网格的核心部分。

<!---->l         <!---->编码学同样也会改变。 JavaEE 作为请求 / 响应的典范，开发人员的认知都单单从产品和客户角度来考虑，基本上不会去考虑对一个假定的处理做什么向外扩展，倒是负载均衡可以优先考虑。还有，因为又不太可能弄出一个通用的模型用来编写网格应用程序，因此，我可以很负责的说，如果使用了网格，它会千方百计去影响你的最终模型（需要谨慎考虑）。

<!---->l         <!---->关于网络的布署问题大多集中围绕在动态配置 (dynamic provisioning) 。我想说的原则是：当且仅当系统确实需要网格时，才使用它。

 

 

云计算并不是应用服务器唯一一个新增定义。传统 Java 应用服务器打包机制都是中规中距的： web archives, ejb jars, enterprise archives, resource archives 。随着 OSGi 的到来，它提供的模块 (Module) 的规范成为了应用服务器的新平台。

 

 

目前，只有一款主流应用服务器是基于 OSGi 的，那就是 SpringSource 的 Application Platform( 应用程序平台 ) 。不过别的应用服务器也开始追赶了，比如说 Glassfish 也整合了 OSGi ，布署应用程序的工作变成了指定一个模块及其相应的依赖模块的发布。

 

 

SpringSource 的 Application Platform 之所以叫平台而不是应用服务器，就在于对大多数人来说“应用服务器”就意味着 JavaEE 。要将“应用服务器”应该从“ JavaEE ”中分离出来，

不如建立新的 buzzword 供世人牢记。

 

 

过去应用服务器的定义很简单：它表示对应用程序有帮助的一类事物。 SAP 将自己定义成了应用服务器，它也确实是这么做的——很久以前它就开始提供 NetWeaver 平台了。在 Java 的大背景下，“应用服务器”还是很狭隘的局限于 J2EE 的服务器。现在，随着云计算的到来，关于应用服务器的定义不得不又再放宽——不仅仅只局限于 JavaEE ，还包括任何可以为开发人员提供服务的应用程序平台。

 

 

现在大家应该知道什么是应用服务器，它应该是什么，以及当前它的现状了吧。

 

 

 

参考链接：

 

<!---->1.         <!---->http://searchsqlserver.techtarget.com/sDefinition/0,,sid87_gci211584,00.html , "What is application server?" Note the emphasis on HTTP as a transport.

 

<!---->2.         <!---->http://java.sun.com/javaee/5/docs/tutorial/doc/bnabo.html , "Java EE Containers."

 

<!---->3.         <!---->The client portion of a Java EE application can be seen as one (or more) of three environments: a client-side rich application, a web browser, or an applet running inside of a web browser.

 

<!---->4.         <!---->This is often with HTTP, although other protocols like SMTP are fully possible if you use a different port and, well, use Servlet instead of HttpServlet...

 

<!---->5.         <!---->Interested in the whole list? See http://java.sun.com/javaee/5/docs/tutorial/doc/bnacj.html , "Java EE APIs."

 

<!---->6.         <!---->With the advent of Sarbanes-Oxley, this changed somewhat: an application should not manage its own database passwords and the like. The Java Naming and Directory Interface was designed to isolate confidential information from the developer: see http://www.ibm.com/developerworks/library/j-jndi/?ca=dnt-62 , "The role of JNDI in J2EE"

 

<!---->7.         <!---->In fact, the Java EE 6 specification created the idea of "profiles," built around the idea that containers like Tomcat are, in fact, acceptable application servers, and should be recognized as such by the specification.

 

<!---->8.         <!---->For example: batch processing, map/reduce architectural problems, complex flows without a specific request/response phase, or event-driven architectures - although it should also be noted that when all you have is a hammer, everything looks like a nail. People can use and have used J2EE for all of these, no matter what a pain it was to do so.

 

<!---->9.         <!---->http://java.sun.com/j2ee/connector/ , "J2EE Connector Architecture," a rather underappreciated specification thanks to its arcane structure.

 

<!---->10.     <!---->Thus enabling safe usage of Lucene: see https://lucenerar.dev.java.net/ and https://lucene-connector.dev.java.net/

 

<!---->11.     <!---->A mail polling JCA component is the basis for the JCA tutorial.

 

<!---->12.     <!---->"I ... don't think that Grid Dynamics claims anything beyond just this test - you can simply perform computationally intensive tasks with almost linear scalability on 512-node strong Amazon EC2 cloud," from http://www.theserverside.com/news/thread.tss?thread_id=50262#266007 target=

 

<!---->13.     <!---->In the interest of product neutrality, I don't think I can fairly go into more on architectural changes for a grid. I work for GigaSpaces Technologies; my bias is pretty easy to discover.

 

<!---->14.     <!---->Note that there are (at least) two vendors who might protest that statement: Azul and Terracotta. Both claim to take an application written traditionally and scale them out. I won't say otherwise; however, I'd say that even with Azul and Terracotta DSO you'll see a greater benefit from modifying your architecture to leverage the platforms' capabilities.

 

<!---->15.     <!---->JbossAS used to inspire a lot of hilarity for me with some of their additions to the set of archive formats, with things like hibernate archives and service archives. These were good ideas, really, and it's sad that I lacked the forethought to appreciate them. Mea culpa.