2016-12-25

新的一年中间件技术展望

Java语言

2017年是Java语言技术大年。

  1. Java 9会在7月份发布,其中包含了推迟了若干年的模块化特性,这个会对未来的架构设计和开发方法产生深远的影响。HTTP/2,jShell,Flow API,Unified Log, Multi-Release JAR,jlink以及很多安全方面的改进和增强令人期待。

  2. SpringFramework5会发布,Reactor3成为异步框架的关键。这个新的框架将进一步提升通用Java应用的移动设备和网络应用的吞吐能力。

  3. MicroProfile已经被Eclipse组织接纳成为孵化项目,JavaEE在社区领域,出现了一个独立的开发规范集合,一大批开源框架和服务器正在不断成熟中,今后将会是Java微服务开发的主力。

  4. 如果顺利的话,JavaEE8会在四季度发布,尽管除了Servlet4之外,没有其他大的改进。但各个规范会进一步适应目前的异步化,服务化的开发需求,EE8还是非常值得期待的。

应用服务器

与Java语言傲居开发语言之首形成鲜明对比的是,JavaEE应用服务器市场规模依然在下滑,前不久Gartner Group还专门发了市场分析报告来唱衰这个市场,并预言微服务框架和PAAS平台会占据更大的份额。我基本同意应用服务器市场会从原先中间件开发平台垄断位置减少很大的市场份额,而且中间件基础软件会延续Linux的市场发展轨迹,走产品免费而订阅服务的商业模式。微服务框架产品目前已经成快速增长趋势,PAAS平台也开始被更多的企业所接纳。

然而我相信,应用服务器(或者说是整体交付的独立运行应用程序的服务器)还是有大片的市场需求的,尤其是在国内,目前各行业中企业软件还几乎全部是部署在应用服务器上。虽然各个企业都在寻求可能的服务化改进,并盯着一线互联网公司学习经验,但毫无疑问想要改变企业应用基础架构的技术路线,这个过程会非常漫长。

而且,应用服务器的市场还是会一直存在的。一个例子就是SAP的Hana服务器,近来会推出HANA2。这是一个内存杀手,把整个商业系统容纳在一个庞大的业务服务器中。给企业内部使用的,采用交付软件的方式,系统整体效率非常高,软件经过广泛的测试,成熟度和稳定性很好。

应用服务器的市场就是面向广大的企业应用,不需要很大的并发访问量(如果需要暴露数据到互联网上可以采用同步数据方式),功能特性非常丰富,需要有很强的事务处理能力,最终用户的开发力量不是很强,主要以业务用户和运营为主。在这个场景下,带有集群能力的应用服务器还是首选,使用目前较轻量级的应用服务器,可以做到快速开发部署,解开压缩包即用,几秒内迅速启动,配套的监控运维平台。在当前主流服务器硬件能力下,个位节点数组成的服务器集群,支撑上百万的并发访问不会有问题,足以满足绝大多数企业应用和中小网站的需求。

那么,为什么唱衰应用服务器呢?原因是过去它承担了太多的期望,各种应用,不论架构设计的合适还是不合适,都在应用服务器上开发和部署。各个厂商的产品都做成了大而全的大杂烩,动则500M以上,厚重而运行缓慢。Spring框架首先质疑并通过敏捷而优秀改进占领了Java服务器Web开发的大部分份额。后来OSGi技术也曾经发起过挑战,但由于自身也很复杂,学习曲线陡峭,除了集成,工控等领域,并没有被广泛运用于企业软件中。

从2014年开始,容器和微服务成为技术的热点词汇,可以说它们是相辅相成的,微服务需要一个能被管控的载体,恰好容器技术开始成熟并广泛应用。而容器技术也是一个筐,需要有具体的应用来完成技术的演进。

那么,容器和微服务真的是“新”技术么?首先容器一词,早在J2EE出现时就有了Web容器和EJB容器的说法,顾名思义,就是容纳应用的载体,开发者编写的程序通过API/插件/Addon等扩展机制,部署/运行在一个环境之中,而这个环境提供通用的技术设施和数据等服务。而微服务,Corba时代的进程,和后来的SOA,都是如假包换的服务程序。只不过如今的容器和微服务都有了更多的特点和更清晰的定义。

服务化

从技术的角度来看,JavaEE应用服务器的架构,从开始就是可以服务化的,比如Servlet通过远程调用EJB接口,只不过在规范中被定义成需要RMI/IIOP协议。这些看似“过时”的定义,其实在企业应用中可以工作的很好,如EJB3.1定义的异步接口能力,就可以大大的提高系统整体吞吐能力。而且如果能有效的进行改进,比如说未来的EE9,可以支持如gRPC等远程调用协议,将会唤回新的技术活力。

JavaEE的最大问题就是整体过于庞大,有33个子规范,而在面对某个类型应用时,绝大多数规范运用不上,能用上的呢,又定义的不是那么的细致全面,还比不上Spring框架或者第三方库等实务者。所以我们在具体技术选型时,可以忘掉JavaEE大而全,而要选择合适的,小而美的具体子规范,搭配使用来满足应用需要。

MicroProfile就是面向微服务而由社区形成的一个JavaEE子规范集,已经推出的1.0只包含三个JaxRS/CDI/JSONP,通过这三个现有的EE7子规范组合,就可以满足微服务开发的很多需求。目前Wildfly-swarm, Payara micro等已经完整支持。使用这个技术集的一个红利是:开发的产品,即可以部署在应用服务器中,也可以作为微服务程序开箱即用。

从具体的软件架构来说,传统的三层结构已经不能满足当前的互联网应用需求,分布式已经是必然要考虑的属性。而矛盾点就是,以事务为核心的企业应用,设计的一个原则就是避免分布!所以对于有扩展需求的应用,适当的软件架构非常重要。我的观点是,采纳DDD设计思路中的CQRS原则,在设计时就考虑,这样无论是在一个JVM,还是分布式架构,API是统一的,体系变得非常清晰。应用实体的修改,用事件存储机制和消息队列,数据的查询则采用类似RxJava这样的异步数据访问接口,数据直接通过中间件进行高效同步复制,并使用分布式缓存来优化存储和数据访问速度。

这样的体系架构,可以横跨应用服务器/微服务框架/PAAS运行平台,在一定程度上做到架构设计的可扩展性。从执行效率来讲,无论是命令模式API,还是消息队列,Rx式数据访问,都可以本地执行实现极速访问,也可以远程调用便于动态扩展。

新的一年,应用服务器,微服务平台,应用基础架构,中间件领域,新的机遇新的挑战。