引言
有人说，Java确实过于臃肿，经常“小题大做”。但PHP、Nodejs扩展方面短板太明显，做小应用可以，大型应用就玩不转了。另外，JavaEE领域有太多优秀框架可以解决开发效率的问题，事实上借用Spring等框架，开发的效率丝毫不亚于PHP。互联网时代的Java开发者，很多都不是基于Servlet和EJB来开发Web应用，而且WebLogic、WebSphere也只会存在于大公司的存量系统中，互联网公司的Java都是Tomcat的世界。
那么，微服务能完全弥补JavaEE的短板吗对于JaveEE来说，微服务扮演的，究竟是拯救者还是掘墓人的角色
在Java问世之初，包括IBM、BEA、Oracle在内的一些巨头公司，看到了Java作为一门杰出的Web编程语言可能给他们带来的巨大商机。那么如何通过一门编程语言来赚钱呢答案就是，使用这门语言构建复杂无比的服务器，让那些大公司支付一大笔费用来购买这些服务器。于是紧接着就出现了JavaEE规范、JSR规范，以及WebLogic、WebSphere等服务器中间件。在这些服务器上面部署了大型的程序包，它们运行缓慢，消耗大量的内存。基于这些容器的开发和调试对开发人员来说简直就是噩梦，作为对他们的补偿，他们从雇主那里获得了丰厚的报酬。
因为耗资巨大，几乎找不到一家公司可以使用合理的费用长时间地支持Java。如果你要用Java构建一个网站，你必须支付一大笔费用来运行这些服务器，哪怕你只用到了Servlet容器。在很长一段时间里，Java被用在企业和公司里，因为只有这些大公司能够负担得起数百万美元的服务器费用，并为那些企业级开发人员支付高额的薪水。
RodJohnson在2003年发布了Spring框架，Spring提供了IoC和对POJO的支持，帮助开发人员逃脱EJB魔掌。开发效率因此得到大幅的提升，大量开发人员转向Spring，把EJB丢在一边。应用服务器开发商看到了这一点，他们在JavaEE5里提供了一些可以减轻开发人员负担的特性。可惜的是，Spring被一路追捧，人们几乎把它跟JavaEE容器混为一谈，它仍然运行在JavaEE的Servlet容器里，这些容器沿用的是十年前的设计，并没有考虑到多核CPU和NIO。
在这期间，PHP奋起直追。PHP使用更少的内存和资源，得到很多公司的支持。一些CMS平台，比如WordPress、Drupal等都是基于PHP构建的，这些平台吸引了大批PHP开发人员。不过，虽然PHP仍然是现今最流行的编程语言，但它也有自己的短板。它运行速度不是很快，而且难以横向扩展。
2009年，RyanDahl启动了Nodejs项目，它支持异步非阻塞的、基于事件驱动的I/O。如果服务器的线程使用得当，Nodejs可以极大地提升响应速度，单个服务器的吞吐量可以媲美一个JavaEE服务器集群。Nodejs是一个很好的作品，但它也有自己的局限性。Nodejs难以扩展，也难以与遗留的系统集成。
2014年，Undertow出现了，它是一个基于Java的非阻塞Web服务器。从#的测试结果来看，在一个价值8000美金的戴尔服务器上，它可以每秒钟处理几百万个请求，而谷歌需要使用一个集群才能处理一百万个同样的请求。它是轻量级的，它的核心部分只需要1M内存，它还包含了一个内嵌的服务器，这个服务器使用不到4M的堆内存。
基于UndertowCore构建的LightJavaFramework是一个微服务容器，它支持设计驱动及生成代码，并支持运行时安全和运行时验证。
JavaEE厂商多年前，JavaEE厂商，比如Oracle和IBM，他们花费数亿美元开发应用服务器(WebLogic和WebSphere)，这些服务器以数百万的价格卖给了大型组织。但现在这些服务器卖不动了，因为JBoss迅速抢占了市场份额，Oracle对JavaEE的支持正在走下坡路：#/story/16/07/02/1639241/oracle-may-have-stopped-funding-and-developing-java-ee
随着微服务越来越多地受到关注，这些应用服务器很难有好的销量，因为这些服务器更适合用来部署单体应用。有一个包含了数百个EJB的应用，为了在WebLogic上测试一行代码改动，居然用了45分钟时间。
JavaEE客户
从客户角度来看，耗费巨资购买这些服务器是不值得的，因为JavaEE所承诺的未必都是真的。一个为WebSphere开发的应用无法部署在WebLogic上，所以你需要花更多的钱去升级服务器，因为厂商可能不再支持旧版的服务器，而这样的更新会花费你数百万美元。于是一些聪明人不禁要问，为什么我们要把应用部署在这些庞然大物上为什么我们要把应用打包成一个ear包或war包，而不是jar包为什么我们不能把大型的应用拆分成更小的块，让它们可以独立部署和扩展
微服务
微服务是这些问题的解药。Wikipedia把微服务定义为“一种软件架构风格，复杂的应用由一些独立的进程组成，这些进程使用与语言无关的API进行交互。这些进程服务规模很小，高度离散，聚焦在一个很小的任务上，使用模块化方式来构建系统”。微服务架构让构建应用变得更加容易，而且应用被拆分成单独的服务，这些服务可以被任意组合。每个服务可以被独立部署，也可以被组合成一个应用。这些服务还可能会被其他应用依赖。它加快了服务的开发速度，因为只要定义好接口，服务可以并行开发。
微服务具备d性和伸缩性。微服务不只依赖单个服务器和部署，它们可以被发布到多个机器上，或者多个数据中心及其它任何可用的区域。如果一个服务失效，可以启动另外一个。因为整个应用被分解成了微服务(小型服务)，可以很容易地对其中某些热门的服务进行横向扩展。
如果你曾经使用过COM、DCOM、CORBA、EJB、OSGi、J2EE、SOAP和SOA等，那么你就会知道服务和组件并不是什么新生事物。企业在使用组件方面存在的一个最大问题是他们依赖大型的硬件服务器，并在同一个服务器上运行很多应用。我们有EJB、WAR包和EAR包，以及各种组件包，因为服务器资源太过昂贵，要尽可能地物尽其用。
不过从最近几年的发展情况来看，之前的方式有些落伍。 *** 作系统服务器一直在变化，虚拟资源可以被当成组件发布，比如EC2、OpenStack、Vagrant和Docker。世界变了。微服务架构看到了这种趋势，硬件、云技术、多核CPU和虚拟技术也在发展，所以我们要改变以前的开发方式。
在开始新项目的时候不要再使用EAR包或WAR包了。现在我们可以在Docker里运行JVM，Docker只不过是一个进程，但它可以表现得像一个 *** 作系统一样。Docker运行在云端的 *** 作系统上，而云端的 *** 作系统运行在虚拟机里，虚拟机运行在Linux服务器上。这些服务器不是归谁所有，而是被很多互不相识的人共享。如果出现流量高峰怎么办很简单，使用更多的服务器实例。这就是为什么要把Java微服务运行在一个单独的进程里，而不是JavaEE容器或servlet容器。
微服务一般会提供基于>
使用微服务架构的应用程序应该是模块化、可编程和可组合的。微服务之间可以相互替换。应用程序的局部可以被重写或改进，而不会影响到整个应用。如果所有的组件都提供了可编程的API，那么微服务之间的交互就会变得更简单(永远不要相信那些不能通过curl访问的微服务)。
随着微服务逐渐流行起来，很多厂商开始尝试把他们的JavaEEWeb服务转成微服务，这样他们就可以继续卖他们的过时产品，APIGateway就是这些厂商中的一个。
JasonBloomberg是Intellyx的主席，他在一篇文章里指出了传统Web服务和微服务的区别，并对把传统Web服务转成微服务的趋势提出了质疑：
#/dangers-microservices-washing-get-value-strip-away-hype
微服务不是企业服务总线里的Web服务，也不是传统的面向服务架构，尽管它沿袭了SOA的一些基本概念。从根本上来说，微服务跟SOA是不一样的，因为整个环境已经发生了彻底的转变。
微服务架构的环境是没有边界的：端到端，基于云的应用程序运行在完全虚拟和容器化的基础设施上。容器把应用程序和服务组件化，DevOps为IT基础设施提供框架，帮助自动化开发、部署和管理环境。
虽然容器对微服务来说不是必需的，不过微服务可以很容易地运行在容器里。况且，把非微服务的代码部署在容器里不是一个明智的选择。
Docker和其他容器技术在某种程度上已经被视为微服务的最好伴侣。容器是运行微服务的最小资源子集。Docker简化了微服务的开发，让集成测试变得更简单。
容器有助于微服务开发，但不是必需的。Docker也可以被用来部署单体应用。微服务与容器可以很好地相融并进，不过微服务包含的东西远比容器多!
结论
应用开发的风格这几年一直在变化，而微服务变得越来越流行。大公司把大型应用拆分成可以单独部署的小型应用，这些小型应用被部署在云端的容器里。开源微服务框架LightJava为这些运行在容器里的微服务提供了很多特性，它支持设计驱动，开发者只需要把注意力专注在业务逻辑上，剩下的事情可以由框架和DevOps流程来处理。那么问题来了，你怎么看
在开源的Java应用服务器领域 像JBoss Tomcat及Apache的Geronimo 他们不仅仅是商业领域的领跑者 同时是技术领域的先行者 当然 所有的Java EE应用服务器的实现不尽相同 但其很多方面具有一定程度的可比性 本文对JBoss Geronimo 及Tomcat 三种开源的Java EE应用服务器 就他们的特性 部署及性能等方面进行一一比较 一 前言 当企业级的Java应用程序需要真正的应用部署时 Java EE应用服务器是必不可少的工具 研究表明 除了商业的应用服务器之外 开源的Java EE应用服务器开始成为很多Java企业级应用的最佳选择 而JBoss Tomcat及Apache的Geronimo是其中最主流的开源Java EE应用服务器 而这三者中 尽管JBoss和Tomcat并非 %的实现了Java EE 标准 但这二者占有的市场份额相对比较大 Geronimo是对Java EE 标准 %的实现 正在快速的发展 如果读者想在Java EE领域找份像样的工作 对这三种开源的应用服务器应该达到比较熟悉的程度 并能在一定程度上进行比较区分 在本文中 对这三种主流的应用服务器 就其特性 部署及性能等方面进行比较 分析了他们各自的特色对该应用服务器的重要性 当然 也提供了一些如何选择适合项目的服务器的原则及建议
二 特性比较 表 就JBoss Tomcat 及Geronimo 的特性进行全面的比较 请注意 表中用到的 部分支持 表述 表明该应用服务器并非完全的支持 需要安装一些额外包 而其中的 原则上支持 表述 表明该应用服务器需要第三方的安装包的支持 注 三种应用服务器均在Linux Solaris Windows及Mac OS X上进行过测试 表 Java EE应用服务器特性比较
特性 JBoss Geronimo Tomcat Java EE 一致性 部分支持 完全支持 部分支持 支持EJB 支持 支持 原则上支持 JSP 和Servlet 支持 支持 支持 JSF 支持 支持 原则上支持 客户化插件 支持 支持 不支持 业务规则引擎 原则上支持 原则上支持 原则上支持 Hibernate x 支持 原则上支持 原则上支持 集群 支持 支持 部分支持 Eclipse IDE 支持 支持 支持 当读者的应用需要比较特殊的扩展 或是想与Java EE 最贴近时 那么 Geronimo 是最佳的开源Java EE应用服务器选择 尽管JBoss 与Sun的Java EE标准在实现上有一定的出入 但JBoss team提供了许多与Java EE标准很符合的技术 同时也扩充了Java EE 的标准范围 而Tomcat 本身就是一种轻量级的解决方案 所以它不并包括Java EE 的所有特性 或是在JBoss及Geronimo中所提供的特性 但正是由于它的轻量级 才使它对内存的占有量比较少 并且比其它两种服务器运行起来更快 ．Java EE 一致性 Sun公司的Java EE 标准是一种行业标准 而作为这种标准的实现 开源的Java EE 应用服务器应该与其尽量的保持一致 因此Java EE 的一致性是一个很重要的指标 在这三种开源的实现中 Geronimo是实现得最好 与Java EE 标准最贴近的应用服务器 JBoss 支持绝大部分Java EE 的特性 当然 不久即将发布的JBoss 将完全支持Java EE 的所有特性 而Tomcat一般看成是JSP/servlet的容器 仅仅支持Java应用服务器的基本特性．支持EJB EJB（Enterprise JavaBeans）是指能在Java EE服务器部署的Java组件 它通常将一些业务功能打包成可重用的组件 新发布的EJB 提供了许多新功能 解决了旧版本中许多问题 JBoss 及Geronimo 均支持EJB Tomcat 本身并不支持EJB 但Apache OpenEJB项目可以使Tomcat支持EJB 据称Tomcat可以运行一种嵌入式的JBoss EJB 容器
．支持JSP /Servlet 对JSP/servlet的支持是绝大部分Java服务器应提供的最基本功能 JSP 和Servlet 是Java EE 对JSP/servlet的升级功能 JBoss Geronimo 及Tomcat 均支持JSP/servlet这一特性
．支持JSF JSF（Java Server Faces）是一种在Java EE应用部署的组件式架构 提供基本的Web开发的用户界面 与请求驱动的MVC（Model View Controller）的架构不同的是 JSF采用了组件驱动的模式 就目前的JSF 而言 JBoss 及Geronimo 都有很好的支持 而运行在Tomcat 时有不少的问题待解决
．支持客户化插件 客户化插件支持 意味着可以在原有应用服务器功能的基础上 开发新的功能 并能很好的协同使用 在JBoss中使用MBeans（managed beans）来处理插件开发 而Geronimo也采用类似的处理方式 只是名称不一样 叫GBeans 这些客户的Beans为开发及部署客户资源时 提供一系列统一的接口
．支持业务规则引擎 几乎所有的应用程序都是建立在一系列业务规则之上 或称之为业务逻辑 而业务规则引擎组件则能帮助管理与简化业务逻辑编程 一般的编程过程中 程序员最常见的逻辑有如if/then逻辑 而有了业务规则引擎 则可以实现许多更加智能的业务逻辑 Drools作为一种业内很流行 标准化的业务规则引擎 在JBoss Geronimo 及Tomcat 中均可得到支持 Geronimo完全支持Drools 而JBoss支持Drools的历史最久 已达三年之久 并使JBoss/Drools成为了一种非常有市场竞争力的业务规则解决方案
．支持Hibernate x Hibernate为Java编程提供了强有力的关系/对象模型（ORM Object relational mapping） Hibernate可以将面向对象的模型映射为关系型数据库 这对Java开发来说是最有吸引力的 Hibernate作为一种开源的软件 最早就是由于JBoss的一个团队所开发（Gavin King） 当然 JBoss Geronimo 及Tomcat 均支持Hibernate
．支持JBoss Seam JBoss Seam是一种著名的应用框架 集成了众多的Java及Web技术 例如Ajax JSF Java Portlets BPM（Business process management）等技术 Seam是JBoss的项目 理所当然 JBoss 自然支持它 同样Geronimo 也支持JBoss Seam 据JBoss Seam的开发团队称 Tomcat可以通过使用JBoss嵌入式EJB 容器来支持JBoss Seam
．支持集群 集群通过并行在多台服务器运行同样的服务 从而大大的提高应用的吞吐量 达到所谓的高负荷的效果 由于采用了数台服务器同时运行 所以当其中的某台服务暂时或死机时 对客户不会造成服务停止 从而达到业务的可持续 集群极大的提高了企业级的Java应用的性能 吞吐量等能力 JBoss Geronimo 及Tomcat 均以同样的方式来支持集群 JBoss在集群层使用及时复制的方式来达到集群的目的 而Geronimo所发布的集群 还处于测试阶段 需要时间的考验 如果有兴趣 可以与Apache基金组织联系
． 支持Eclipse IDE Eclipse是目前最流行的Java开发工具 自然 与Eclipse的集成是众多Java EE 应用服务器应该提供的功能 JBoss Geronimo及Tomcat均支持与Eclipse整合 特别地 JBoss还有自己的Eclipse版本 称为Red Hat Developer Studio 目前正处于测试的阶段 利用Geronimo提供的工具 可以省去手工配置XML文件的烦琐 同时 数据库连接池工具都可以自动的下载所需要的数据库连接驱动
三 部署 这三种应用服务器的安装均十分简单 在相关的网站上下载zip或tar包进行解压 唯一需要配置的是设置JAVA_HOME环境变量（不过一般均有配置） 注意 在Linux/Unix系统下 需要先发送chmod命令 ．Geronimo 对Geronimo 来说 进行配置及部署Java应用程序非常的简单 特别是通过它提供的Web控制台更加简单 Geronimo控制提供了许多简单的功能来帮助开发人员进行应用程序的配置 可以进行数据库的连接池测试及安全设置或配置等
图 Geronimo控制台
JBoss JBoss 有非常漂亮的Web管理控制台 但它所提供的管理功能及特性与Geronimo不尽相同 首先看到的是JBoss的状态及其监测信息 但并没有提供部署功能 而部署Java应用时 只需要将它复制到default/deploy文件夹下面 JBoss会自动的检测到它并进行相关的快速部署 当然 也可以通过修改配置jboss service xml来进行客户应用程序所在目录的映射
图 JBoss控制台 Tomcat Tomcat 不愧为一款快速的轻量级的应用服务器 它的控制台提供了基本的部署功能 可以通过Tomcat的控制台进行服务的启动/停止及WAR包的deploy/undeploy *** 作 当然也提供了Tomcat的运行状态及监测信息 同时有很好的用户授权系统
图 Tomcat控制台
四 性能 就可靠性而言 性能应该是所以的应用服务器所应该提供的最重要的特性 在本文中 笔者做了一个小实验 使用JSP页面及编译好的servlet来测试应用服务器所能处理的用户会话个数以及所能连接的用户数量 当然 实际的Java应用是更加复杂的 而本实验中的JSP页面及servlet是比较简单的 主要用于测试Web应用服务器的稳定性 可靠性及速度 使用的测试机器为 双核 位 CPU G的内存 在实验中 让第一种应用服务器运行到 个会话 当然 这些会话不并是同时连接
图 多Session测试JSP页面结果
lishixinzhi/Article/program/Java/ky/201311/28190
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）