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

　　InfoQ中国站发表了一篇卫滨张兄的文章“Java应用服务器前途堪忧”。仔细看进去，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的子规范技术开发占主导地位。

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