时至今日,基于微服务的架构已经随处可见了。我们见识到了Netflix与Amazon等创新者是如何通过微服务来取得业务上的成功。不过,对于那些使用Java EE服务器,编写传统系统的开发者来说应该何去何从呢?我们一直所做的都是错误的么?我们该如何让技术设计能够适应于未来?
首先,我们来看一下这些传统系统,或者说是单体应用。虽然单体这个词现在看起来颇有一种坏味道之感,但这确实是我们长久以来构建软件的方式。基本上,它指的是这样一个事实,即我们构建一个个应用来实现某些功能。单体指的就是Java EE或是一开始的Java 2 Enterprise Edition设计的目标。集中式应用可以进行伸缩与集群,但其设计却不一定具有弹性。在大多数时候,其失败场景都要依赖于底层基础设施与运维。
传统上,Java EE应用遵循着一些核心模式,并且会分成3个主要的层次:展现、业务与集成。展现层会被打包到Web Application Archives(WARs)中,业务与集成逻辑则会被划分到单独的Java Archives(JARs)中。他们会被打包作为一个部署单元,即所谓的Enterprise Archive(EAR)。围绕着Java EE的技术与最佳实践足以构建出设计良好的单体应用。不过,大多数企业级项目都不太关注架构。这也说明了为何有时设计良好的意大利面条是项目依赖与内部结构可视化的最佳方式。当这发生时,我们很快就会体会到一些严重的缺陷。由于一切都是耦合并且集成到一起的,因此即便进行一些非常小的变更也需要大量的工作(有时还需要重构),然后才能将修改过的部分放到产品中;同时,我们还需要从始至终非常小心地对应用进行测试。整个应用不仅仅只是一些程序化的构件:它还包含了很多部署描述符以及服务端配置文件,此外还有第三方环境的属性等。开发这些企业项目需要多个团队联手,需要很多人从更高的视角来审查整个项目。业务组件与领域大多数都是由既有的数据库设计或是业务对象定义所驱动的。
变更的高风险与将新配置引入到生产中的复杂性会导致发布频率变得越来越低。新的发布可能一年才有那么几次。甚至团队结构都会受到单体软件架构的严重影响。长久的测试周期就是最直观的证据。
时代在不断发展,下一代系统架构与设计在几年前出现了。随着集中式集成组件日益增长的复杂性以及应用之间连接的成本越来越高,人们开始寻求更加轻量级、更加富有弹性的解决方案,逐步开始放弃大型、重量级基础设施与设计。与之相伴的是IT部门开始重新审视应用服务器以及冗长的协议和接口技术。
对于那些基于SOA与ESB的项目来说,其服务实现回归到了更加敏捷的构件与服务中来。相对于智能路由与转换来说,微服务使用了简单路由,并且将逻辑封装到了端点本身当中。微服务是围绕单业务目标而展开的。虽然企业系统的设置让人感到非常烦恼,但对于微服务来说,最有效的运行时却并不一定是功能完善的应用服务器。它可能只是个Servlet引擎,JVM已经足以作为一个执行环境了。运行时千变万化,编程语言的选择也是数量庞大的,因此这种开发模式很可能会成为另一种运维梦魇。甚至连开发者都可能会在定义微服务以及如何将这种设计应用到既有应用中迷失方向。微服务的设计目标是要形成小型、无状态、独立且自包含的应用。在理想情况下,可以将其部署到任何地方,因为部署本身已经包含了所有必要的组件。
微服务要足够小。不过,“小型”的定义是很主观的。可以使用一些估算方法如代码行数、功能点、用例等。不过一般来说,“小型”与尺寸之间并没有什么必然的联系。在Building Microservices一书中,作者Sam Newman就微服务尺寸的定义给出了一些技术:
足够小,可以由一个小型的敏捷开发团队所拥有
可以在一两个敏捷Sprint(一般来说是2到4周)中完成重写
其复杂度不需要对服务做进一步拆分
无状态应用在处理每个请求时只会使用请求所包含的信息。微服务必须要是无状态的,在处理请求时无需记住与外部系统之前通信的信息。微服务必须要能独立处理请求,它可以与生态系统当中的其他微服务协作来进行处理。比如说,在与其他微服务交互后生成报表的微服务就是个相互依赖的系统。在这种场景中,只向报表微服务提供必要数据的微服务可能是个独立服务。全栈应用本身是可以部署的。它拥有自己的服务器、网络、托管环境。业务逻辑、数据模型与服务接口(API / UI)必须是整个系统的一部分。微服务必须是个全栈应用。
创新与持续不断的改进是企业与企业级项目背后的助推器。如果没有创新,那些过时与昂贵的基础设施组件可能要比在他们上面运行的软件的生命周期还要长。老旧的中间件可能会超期服役,结果是只有少数供应商才知道如何开发它。落后于最新标准的平台栈可能会引入临时应急的解决方案,最终则会产生技术债务。将项目快速迁移到微服务的就是那些开源项目了。Netflix OSS、Spring、Camel、Fabric8等都是很好的例子。借助于当下的PaaS,我们可以更加轻松地操纵多语言构成的全栈应用,而PasS一般来说也是由诸如Docker和Kubernetes等开源项目所维护的。
在这个快节奏的时代中,从开发到上线以及修复Bug的时间被大大缩短了。几乎没有多少企业还能够容忍几个月的产品周期,他们需要软件为业务创造更多的价值。对于那些完全由软件驱动的公司如Uber、NetFlix、Amazon等来说更是如此。我们需要针对灵活性与弹性来构建系统,而不仅仅是效率和健壮性。Java EE并不会消亡,它会得到补充和完善。
进入2016年时间还不是很长,让我们回顾下去年年底的一个预言。去年12月,来自C2B2的Steve Millidge预测,2016年将会成为Java EE微服务年。在一定程度上,这是基于Steve在JavaOne上的演讲,他在演讲中详细地讨论了这个主题。此外,Steve还是Payara的联合创始人,Payara的目标用户也是对微服务感兴趣的Java EE开发人员。Steve还认为,SOA和微服务之间的差别很小,这种观点我们以前听说并且报道过。他在视频中指出:
“微服务与SOA没什么不同。它还是关于SOA”。
当然,现在还存在争论,因为他的背景和当前的工作重心,Steve可能会发现自己很难保持客观的态度。不过,早在2014年,微服务还处于起步阶段,Adam Bien就描述了理想的Java EE微服务:
[...]理想的Java EE微服务是一个单[实体控制边界]组件,在一个WAR包中,部署在单台服务器/域中。在这种情况下,开发人员可以单独地发布和重新部署单个组件(又称微服务)。WAR包之间不可能直接调用方法,因此,WAR包将不得不使用比如JAX-RS来彼此通信。
我们在去年年底就微服务、DevOps和Java EE相关内容采访了Markus Eisele,他详细论述了自己为什么认为Java EE将会在微服务生态圈的发展中扮演重要的角色。还有一些其他使用Java EE编写微服务的方法,包括TomEE和WildFly。KumuluzEE是JavaOne 2015 Duke选择奖的其中一个获奖者,该框架是一个Java EE微服务框架。该框架的联合创建者Matjaz Juric解释说:
KumuluzEE是第一个使用标准Java API的微服务框架。微服务架构的重点是将应用程序开发成服务并将这些服务单独部署;没有一个框架提供自动化部署和配置,是不可能使用Java EE实现真正的微服务架构的。
让我们看一些人们如何看待微服务和Java EE的其他例子,这会非常有趣,因为有些人严格来讲并不属于传统的Java EE领域。例如,早在2014年,Alex Soto就论述了为什么Java EE和RxJava是一个很棒的方案。不过,并不是每个人都认可使用Java EE能使开发人员采用微服务。正如Rick Hightower所说的那样:
如果你将一个WAR文件部署到一个Java EE容器,那么你很可能不是在做微服务开发。如果你在一个容器或EAR文件中包含超过一个WAR文件,那么你肯定不是在做微服务开发。如果你将服务部署为AMI或Docker容器,而且你的微服务有一个main方法,那么你可能是在编写微服务。
而且,Rick也不认为微服务与SOA相同:
事实上,它们在许多方面是完全相反的。例如,SOA往往采用WSDL,后者是一种非常严格的、强类型的服务端点定义方式。WSDL和XML模式中所有的未知量都来自XML。
当然,我们已经多次讨论过,SOA和Web Service常常没有关系。不过,Rick及其他一些人确信,Java EE太过臃肿或者说笨拙,以其为基础构建微服务并不合适。Jeppe Cramon认为,Java EE之所以是一个糟糕的基础还有更为根本的原因:
如果我们将两路(同步)通信与小/微服务结合使用,并根据比如“1个类=1个服务”的原则,那么我们实际上回到了使用Corba、J2EE和分布式对象的20世纪90年代。遗憾的是,新生代的开发人员没有使用分布式对象的经验,因此也就没有认识到这个主意多么糟糕,他们正试图重复历史,只是这次使用了新技术,比如用HTTP取代了RMI或IIOP。
如果微服务和SOA密切相关,那么可能会有一种观点,就是微服务可以像SOA那样采用一种技术无关的方式。你认为呢?2016年会成为Java EE微服务年吗?如果有的话,Java EE会在微服务中扮演什么角色?
如果你有自己的想法,或者不同意本文的观点,欢迎加群主微信(微信号greenguolei)参与讨论。
联系客服