小谈应用服务器的未来发展

标签: 应用 服务器 未来 | 发表时间:2014-05-22 11:29 | 作者:
出处:http://www.iteye.com

InfoQ中国站发表了一篇卫滨张兄的文章“Java应用服务器前途堪忧”,链接为http://www.infoq.com/cn/news/2014/05/application-servers-are-dead。仔细看进去,Eberhard Wolff的演示稿写的很好,有针对性的分析了目前应用服务器当前的状态和存在的一些问题,提出微服务和持久交付会对应用服务器市场产生冲击,这个技术趋势我非常赞同,但是演示稿的确有标题党和片面下结论之嫌。接下来我就从应用服务器的历史发展,需求由来和互联网浪潮对其促进变化谈谈个人的观点,在一些地方辅以技术说明。

早期一些计算机教科书里写软件可以分为两大类,科学计算和业务管理,我认为是很有道理的,这种分类很好的匹配了现代计算机体系的两大主要部件:CPU和内存,一个负责计算,另一个负责存放状态数据。向后推导,进一步产生面向函数和面向对象的编程语言;软件体系架构选择聚焦在海量数据并发访问,还是选择企业应用系统事务为先。在设计一个软件之前,仔细想想这个软件是给什么人用,同时有多少人用,它的需求或者说要完成什么功能,对事务的要求高么,中间环境需要人为干预么,要积累多少业务数据,用户怎么使用最方便。这些问题一旦有了答案,软件的架构基本上就呼之欲出了。

软件的发展离不开和同期硬件能力的匹配,原先CPU是单个,需要分时分配给不同任务使用,内存更是宝贵的资源。在这种环境限制下,再加上专心做一件事的天性使然,程序员在编写程序时,会非常自然的按照时序来书写程序,所以在当代程序员的开发基因中,本能的排斥各种加锁,各种干扰程序正常流程的操作。就和我们去银行办业务,你会抱怨别的顾客插队打岔,柜员中途离开,或者你被要求到外面先填单子等一样。我们的软件框架及容器为了让开发者更快捷的编程,从各种非业务技术难点中解脱出来,会充分利用语言能力和编译/部署手段。

上世纪90年代互联网开始普及,分布式计算技术开始迅速发展,过去针对单机编写的应用程序需要移植部署在互联网上。但无论是科学计算还是业务管理应用软件,适应互联网都是一个“缓慢”的过程。在经典的企业软件设计书籍里,比如 Martin Flowler 的“企业应用架构模式”里建议慎重使用分布对象,Rod Johnson的经典“J2EE development without EJB”更是通篇对早期远程EJB进行鞭挞,而如今互联网应用中完全贯彻SOA思想,几乎全部的接口都是无状态的分布式设计方案,目前Spring社区也在主推 MicroServices 分布协作。是不是感到困惑?是大师们偏颇还是当前的架构出了问题?其实站在各自目标应用立场上,放在当时的技术背景下,都是对的。绝大多数的企业应用都不需要分布,或者说在单一领域根操作时应避免分布;而互联网网站面向海量用户,需要成千上万的机器来保障服务,天生需要分布。

那么对JavaEE中的代表EJB规范,究竟该怎么评点呢?不能以单纯好坏论之,我的观点是EJB承担了太多的责任。1.线程安全的对象。前面说过容器试图解脱程序员,开发EJB对象,是不需要考虑并发的,反而要限制你不能创建线程(3.1之前)。同时非共享成员变量也带来状态的安全,这个重要知识点并没有在程序员中深入人心;2.AOP模式的实现,可以做到让开发者聚焦业务逻辑,事务,安全等上下文信息通过容器隐式传递;3.分布式对象实现。远程EJB设计没有太大问题,关键缺憾是基于Corba相关协议和技术过时。另外对异步式支持不足,无论是异步接口还是MDB的定义,规范定义都不到位。4.还有Timer,StatefulSessionBean等内容,早期甚至还有EntityBean。
剖析EJB,其实就是在分析应用服务器,它们都面临同样的问题:太过于庞大,开发者在经验不足时很难全面把握,从而产生厌恶感。我们知道所谓规范是多个软件大厂商妥协的产物,有太多的非实用主义掺杂在里面。但还是由市场驱动的,是知识经验的凝聚。过去这几年中,除了其他语言方案,就是Java自己内部,各种技术框架就层出不穷。但我们看到无论是Spring还是OSGi,目前都不得不适应JavaEE很多子规范,比如Servlet, JPA等等。因为这些规范更好更全面的揭示了软件开发的内在原则。

Servlet是Java适配HTTP协议而设计的规范,简单好用,关键之处在于,其中的基础接口揭示了面向网络编程最重要的内容:包含消息内容的Request/Response,传递上下文的Context,状态传递的Session,拦截逻辑的Filter,各种Listener接收事件,当然还有软件执行点Servlet,和谐而稳定的构造出一个框架。同样的,JPA是Java适配关系数据库和SQL查询而设计的规范,它试图把持久介质上的关系图谱映射到内存中,使得开发人员即便面对很复杂的关系数据表格和业务逻辑,也能找到线索来理清纷繁头绪。大多数优良的JavaEE规范都是按照这个逻辑思路设计的,所以我建议涉足企业应用开发的程序员,都应该全面系统的学习JavaEE知识,相信会收益非浅。

技术和工具,只有最合适自己的才是最好的,而应用服务器在过去就承载了太多的技术期望。传统的软件采购中,中间件是其中金额很小的一块,但不光要承担应用容器载体职责,还有软件开发,架构设计,部署,监控,升级,安全之种种。面对这么多技术内容,非IT基础架构的企业是不可能,也没有能力能够全部玩转的。他们希望有一个方案,软件供应商可以通过培训让他们的技术员工能掌握部署,管理运维和部分开发定制,系统的整体一致和组件标准化是他们考量的一个重要因素。软件是由程序员开发的,其中的价值和知识凝聚在代码,文档,图示中,甚至更多在程序员的头脑里。最好的软件精华部分,就和一本好书,一支好曲子,一座百年大桥的主要设计方案一样,是由一个人或者少数人组成的团队掌控者。但软件是需要传播的,使用软件的企业也希望用的东西透明公开,可以不去了解细节,但不愿意毫无知情权。这个也是开源运动成功的关键所在。就和我们去吃庆丰包子,透明的玻璃窗后能看到包子的整个制作流程,其实客户并不关心这个包子如何做,只是这种公开透明让人产生信任,从而愿意花钱买包子而节省自己的时间。应用服务器就是帮助企业用户来节省时间,屏蔽复杂度,减少技术理解鸿沟的产品。

现在是互联网时代,别的不说,人人看得见一种鲜明对比:互联网的如日中天和企业软件厂商的不景气。互联网公司有软件平台和自己的盈利模式,它们需要构建自己的技术平台来满足自己的业务需求,开发人力是最宝贵的资源。它们可以投入大量的人力物力来打磨每一个技术细节,不为别的,就为了更好的满足自己需求。但问题是,对于非技术企业来说,它们的方案适合么?有同样的技术能力保障么?能获得后续的商业支持么?为什么说开源好,有标准好,就是因为绝大多数软件项目,即使做的再好,围绕其工作的人都是有限的,那么开放的标准的技术会有更多的人书写博客,制作文档,贡献代码,测试功能性能,不断打磨使之成熟。越来越多的互联网企业也看到这一点,尤其一些国外的互联网巨头,对开源做出了巨大的贡献。对一般企业来说,建议选择开源技术,并且选择软件产商来获得专业服务支持。

还有一个变革是Linux作为基础服务器和云计算的普及。Linux是开源而成熟的操作系统,如今已成为整个互联网的基础之一,越来越多工程师掌握了Linux知识和可以对其进行定制裁剪。软件应用最终要找一个载体,在原来Windows如日中天的微软时代,Java虚拟机作为一个可以跨越操作系统的平台,是最好的选择。如今Linux也可以做到以进程为单位,操作系统为容器,加上资源隔离,微服务等技术方式,一个和应用服务器竞争的方案产生了。我个人非常看好这个趋势,尤其认为改良后的PAAS是应用服务器的发展方向,因为可以更和谐的满足开发和部署业务程序的需要。但这有一个过程,还有面对一开始就提出的问题,是什么业务场景,客户IT应用水平等因素都需要考量。在国内,多数企业还是以windows平台为主,那么微服务这个技术推行还需以时日,即便在互联网等企业中,同样也有企业应用如财务系统,HR系统等需求,这些应用还是由JavaEE的子规范技术开发占主导地位。

所以软件应用架构没有银弹,必须根据业务的特点和自身的技术实力来选择最好的技术方案。

 



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [应用 服务器 未来] 推荐:

小谈应用服务器的未来发展

- - ITeye博客
InfoQ中国站发表了一篇卫滨张兄的文章“Java应用服务器前途堪忧”,链接为http://www.infoq.com/cn/news/2014/05/application-servers-are-dead. 仔细看进去,Eberhard Wolff的演示稿写的很好,有针对性的分析了目前应用服务器当前的状态和存在的一些问题,提出微服务和持久交付会对应用服务器市场产生冲击,这个技术趋势我非常赞同,但是演示稿的确有标题党和片面下结论之嫌.

【监控应用服务器】系列博文目录

- - CSDN博客架构设计推荐文章
前言:做了一个监控应用服务器(Tocmat、WebSphere、WebLogic)的项目,为了留下点印记,给后来人留下点经验之谈,助之少走弯路,特意把这些经验整理出来,与大家分享. 如有疑问,可以Q我:562116039. 监控Tomcat解决方案(监控应用服务器系列文章一). 讲解两种监控Tomcat的解决方案:一是通过Tomcat提供的manager应用,二是通过JMX的方式.

大数据在服务器运营中的应用

- - 博客园_知识库
  腾讯公司从2012年开始,通过对服务器运营流程、工具系统的建设,服务器从一线到三线的运营基本转入线上自动化. 在服务器静态配置、动态的运行状态和生命周期各个节点的运营这几个方面,产生了大量的运营数据,这些信息像滚雪球一样,以几何量级快速增长. 数据越来越多,该如何着手处理呢. 这就像刚入门的厨子一样,在农贸市场里面对堆积如小山般的食材,无从下手.

应用服务器上在线备份Oracle数据库代码

- - CSDN博客数据库推荐文章
做在线备份时,输出做一个修改,动态把输出内容传到浏览器页面上去. 作者:qm4050 发表于2013-2-28 10:34:34 原文链接. 阅读:75 评论:0 查看评论.

使用epoll 在 linux 上开发高性能应用服务器

- - C++博客-首页原创精华区
epoll是linux提供一种多路复用的技术,类似各个平台都支持的select,只是epoll在内核的实现做了更多地优化,可以支持比select更多的文件描述符,当然也支持 socket这种网络的文件描述符. linux上的大并发的接入服务器,目前的实现方式肯定都通过epoll实现. 有很多开发人员用epoll的时候,会开多个线程来进行数据通信,比如一个线程专门accept(我个人早些年在FreeBSD用kqueue的时候,由于对内部机制没有基本了解也这样搞),一个线程收发,或者接收和发送都用各自独立的线程.

2014年最受欢迎的Java应用服务器

- - Java译站
注:数据有限,一家之言,仅供娱乐. 回顾2013年应用服务器市场份额已经有超过一年的时间了. 为了看下这14个月来格局有没有发生变化,我们收集了从去年1月到2014年5月间启动了On Demand Plumbr的783个不同环境的配置信息. 数据是从引导类路径下收集来的——因此下面的数据是基于类似"grep -i tomcat classpath.log"这样的查询结果得到的.

减少使用Java应用服务器,迎接Docker容器

- - ITeye资讯频道
【编者的话】随着Docker的发展,越来越多的应用开发者开始使用Docker. James Strachan写了一篇有关Java开发者如何使用Docker进行轻量级快速开发的文章. 他告诉我们,使用Docker和服务发现的机制,可以有效减轻Java运维人员的负担,进行项目的快速启动和持续迭代. 多年来,Java生态系统一直在使用应用服务器.

Java HeartBeat 0.4 发布,应用服务器心跳检测

- - 开源中国社区最新新闻
HeartBeat 0.4 发布, 该版本的主要更新如下. 下载链接:  http://git.oschina.net/mkk/HeartBeat/raw/V-0.4/dist/HeartBeat-0.4.zip. 在线测试:  http://andaily.com/hb/. 心跳检测各类应用服务器(如Tomcat,Jetty),WEB服务器(如 Apache,Nginx) 的JAVA WEB应用程序.

监控Tomcat方案调研(监控应用服务器系列文章一)

- - 博客园_首页
前言: 最近在做一个监控应用服务器(Tocmat、WebSphere、WebLogic)的项目,目前已小有规模,回头看看,一路走来,也算是磕磕绊绊,遇到过种种问题,走过不少弯路,不过程序员最不怕的就是遇到问题——有什么问题就解决什么问题. 为了给后来人留下点经验之谈,助之少走弯路,特意把这些经验整理出来,与大家分享.

文章: James Ward谈使用HTML5和Java开发客户端/服务器应用

- - InfoQ cn
谈到应用开发,不管是客户端/服务器类应用、传统的Web应用还是移动Web应用,最近的趋势是使用像流式网格布局(Fluid Grid Layout)和响应式网页设计(Responsive Web Design)这样的模式,以及像HTML5、CSS3和JavaScript(客户端和服务器都支持)这样的技术.