对比 JavaEE 深入理解微服务

作者 | 焦烈焱
来源 | CSDN

我有一个习惯,接触到新概念、新技术出现后,就会探究他的前世今生、来龙去脉,正所谓“太阳底下没有新鲜事”,喜欢从对比中找到价值点,不如此就觉得理解不透彻,就觉得少了点什么。微服务的概念出现后,由于又有了服务这个词,大家往往和面向服务架构做对比,类似文章即便不是汗牛充栋,也可算作车载斗量。

但由于 SOA 架构是企业架构层面的一种方法,视角比较宏观(例如建设银行新一代系统就是采用 SOA 架构),再者 SOA 涉及的标准规范例如 XML、SOAP、WSDL、UDDI、SCA/SDO 等又偏重在互联互通的协议上,这种对比总觉得不对等,二义性很强。

我喜欢拿 J2EE 和微服务做对比,因为 J2EE 有一系列明确的规范,可以互相印证。J2EE 出现在 1998 年(参见https://zh.wikipedia.org/wiki/Java_EE,维基百科的描写比百度百科准确很多),2006 年以后改名为 JavaEE,是 Java 企业版的意思,目前是 JavaEE7,明年应该有 JavaEE8,可惜现在关注的越来越少了。JavaEE 既然是企业版(Enterprise 这个词翻译成企业不一定合适,我觉得在英文里是一个组织的意思,政府机构也是 Enterprise,是不是翻译成“单位”,哈哈),就必然支持分布式系统,很多微服务架构的要求,在 JavaEE 规范中都有涉及,参考 JavaEE 规范可以更容易的理解如何实现微服务架构。

让我们看一下 JavaEE 规范,和微服务架构做一个比较:

(为了写这篇文章,我第一次翻出了 JavaEE 7 规范,看着这些名词,唏嘘不已,不免感叹又一个时代过去了。)JavaEE 规范涉及的内容很多,这里只对 EJB、JNDI、Servlet、JSP、JMS、JTA 等规范做一个对比说明。

1、 从 EJB 这个失败的规范理解微服务的后端服务

说起 JavaEE 规范,要先从 EJB(Enterprise Java Bean),他是一种用 Java 实现后端服务的规范。本来 EJB 是 JavaEE 中最重要的规范,但 EJB 出现后,人们一直诟病他过于复杂的使用方式,在 Spring 出现后,大家其实抛弃了 EJB,虽然他自身做了很多改革,以至于 EJB 3.0 后和 Spring 非常类似,然并卵… … 其实,EJB 的设想还是很好的,他把后端服务分为会话 Bean(Session Beans)、实体 Bean(Entity Beans)、消息驱动 Bean(Message Driven Beans)三种模式,前者又分为 无状态会话 Bean(Stateless Session Beans)、有状态会话 Bean(Stateful Session Beans),最初 EJB 完全是使用远程调用的,后来由于性能的原因,又加上了本地模式,上述四种 EJB 都可以采用本地调用。结合微服务架构,我们来回顾一下:

首先服务应该被分为本地和远程两种方式,我一向反对这两种服务处理的透明化,原因是这两种调用在应用开发上差别太大,例如远程调用应该采用异步回调模式,设置明确的超时时间,事务处理不能依赖数据库事务,数据传递需要序列化,需要传递上下文等等,而本地调用可以简单的多。EJB 开始时把所有的东西都做成远程模式,后来由试图两者都支持,结果本来复杂的事情没简单下来,简单的事情反而复杂了,所以我在微服务架构中,把本地和远程服务显示分开,采用不同的 API 进行调用,对于远程服务需要采用异步模式调用,配置超时时间、数据一致性声明、通讯报文定义等等,不去幻想用一种透明方式进行动态切换,其实把本地服务变成远程服务的工作量是远大于这几行代码开发的,所以本地 / 远程调用透明化只是一个看起来很美,这一点上 EJB 是失败的。

其次,EJB 把服务分成无状态和有状态两种,无状态服务没什么好说的,大家都在做无状态化,以便有利于横向伸缩和弹性。无状态虽好,但是业务其实是有状态的,但 Servlet 规范中有 Session,常见的客户登录信息等状态都维护在 Session 中,再者还有很多业务状态也可以在客户端维护,例如翻页时的计数器,在客户端保存,每次提交到服务端,这样有状态服务使用的场景在业务上反而少了。但移动设备出现后,多屏融合的需求让我们无法在客户端维护状态了,例如在 PC 上做一个操作,在手机上做下一步,就只有服务端维护状态才行。服务端维护状态也不是说一定要用有状态服务,因为这些信息可以维护在数据库中,即使考虑性能因素,也可以维护在集中缓存中,服务还是无状态的。上面说了很多,是说明为什么有状态服务使用比较少,但物联网出现后,有状态服务重新有抬头的趋势,例如在读取设备信息时,必须在服务端维护状态,但由于数据量比较大,集中在缓存的方式导致缓存过大,不容易维护,于是就要分而治之,有状态服务就是一个好的选择了。其实,有状态服务经常默默的为我们服务,例如客户端获得一个数据库连接,以后对这个数据库连接做操作时,数据库本身就是维护了一系列的有状态服务,服务状态包括登录信息、缓存数据等上下文信息,每次根据客户端的标识找到这个服务,提供服务。在微服务架构的实现中,需要考虑有状态的模式,可以参考 EJB 的设计,把远程服务分为无状态和有状态两种。

** 实体 Bean(Entity Beans)是含有持久化状态的分布式对象。** 这个持久化状态的管理既可以交给 Bean 自身(Bean-Managed Persistence,BMP),也可以托付于外部机制(Container-Managed Persistence,CMP)。如果说会话 Bean 出现的早期还有很多应用,实体 Bean 一出现就让人感到没法用,分布式对象这玩意,还是太复杂了。我也仅仅是做过 Demo 而已,从来没有实际的应用,不过在我看来,IBatis 和 Hibernate 应该是 BMP 和 CMP 最好的实践了,而 IBatis 和 Hibernate 都不是面向分布式应用的,他们都迎合了当时巨石应用的架构模式,以至于 EJB 3.0 中和 Hibernate 已经非常类似了。在微服务架构下,数据必然是分布式的,而数据的存储方式也从关系数据库拓展到缓存、NoSQL、图等数据存储方式,实体 Bean 实在是分布式数据的早期探索之一,只不过这个尝试失败了。

消息驱动 Bean(Message Driven Beans)是基于 JMS 事件驱动方式触发后端服务的模式,无非是在 EJB 之上加一个事件驱动的外壳。微服务架构下,也支持事件驱动的方式,以后再详细论述。

EJB 规范的目的在于为企业及应用开发人员实现后台业务提供一个标准方式,自动处理了诸如数据持久化、事务处理、并发控制、基于 JMS 的事件驱动、基于 JNDI 的名字和空间管理、基于 JCE 和 JAAS 的安全管理、应用服务器端的软件组件部署、使用 RMI-IIOP 协议的远程过程调用、将业务方法暴露为 Web 服务、以及如何将 EJB 部署至 EJB 容器当中,虽然这是一个不成功的尝试,但这些都是微服务架构需要考虑的问题。

**
**

2、JNDI Java 版的服务发现

Java 命名和目录接口(Java Naming and Directory Interface),是 Java 的一个目录服务 API,它提供一个目录系统,并将服务名称与对象关联起来,从而使得开发人员在开发过程中可以使用名称来访问对象,这个规范是 JavaSE 的一部分,而 JavaEE 建立在 JavaSE 之上,JNDI 也是 JavaEE 一个重要的基石。上面的解释比较拗口,其实解决的是服务注册、发现和配置集中管理问题。看看 JNDI 的示例:

示例:服务查找

[java] view plain copy

  1. Context ctx = …
  2. Object obj =ctx.lookup(“/MyDataSource”);

示例:注册监听器,可用于监听配置的改变

[java] view plain copy

  1. NamespaceChangeListener listener = …;
  2. src.addNamingListener(“x”,SUBTREE_SCOPE, listener);

示例:监听器被触发,获得变更前状态

[java] view plain copy

  1. evt.getEventContext()== src;
  2. evt.getOldBinding().getName().equals(“x/y”)

JNDI 规范虽好,但我们最常用就是 lookup 一个 DataSource,之所以这样我认为有几个原因:a)JavaEE 虽然号称是面向分布式应用,但实际情况绝大多数不是分布式应用,对服务注册、发现的需求很低;b) 每个应用服务器的实现差距很大,尤其是命名方式和服务绑定(bind)上,以至于后来 bind 的接口主要用于应用服务器内部实现了,一个难以做服务注册的服务发现自然难有太大的用处;c)从命名服务中查找得到的是对象,对象一般都需要实例化的,如果是远程对象又涉及到方法的调用问题,加大了复杂度。d)非 Java 的环境无法使用。这几个问题其实也是其他规范难以推广的原因,所以在微服务架构下,Zookeeper、etcd 解决的就是上述问题,重读 JNDI 对规范化服务发现、注册、配置集中管理的接口有很大的帮助。

**
**

3、Servlet:Java API 网关

Servlet 是用 Java 编写服务端程序的接口,在 J2EE 出现之前,服务端程序一般都是用 CGI 实现的, Servlet 的出现让 Java 的服务端程序有了统一的模式。早期我们会把每一个响应请求的类都实现 Servlet 的接口,后来在很多框架中都把 Servlet 做成统一的入口,由框架进行分发,编程的时候就看不到 Servlet 了。Servlet 一直在被广泛使用,在微服务架构中也可以被做为前端接入存在。

**
**

4、JSP:成功的服务端模板技术

JSP 是一种把 Java 语言嵌入到静态页面,动态生成 HTML 或其他格式 Web 网页的技术标准,他解决了 Servlet 生成 Web 网页比较麻烦的问题。JSP 促进了很多框架的产生,不过在 Axaj 模式出现后,JSP 的使用方式也发生了很大变化,前端更加趋向于客户端的渲染,而不是在服务端生成全部 Web 页面。微服务架构下前端有很多实现方式,JSP 只是选择之一。我们曾经在全国产平台上做过测试(龙芯、麒麟等组合),由于国产芯片的计算能力不足,造成浏览器上的渲染速度不够,这时候前端动态渲染的效果很不好,反倒是传统 JSP 在服务端生成 Web 页面的模式体验更佳。

**
**

5、JTA:分布式事务的尝试

Java 事务 API(Java Transaction API) 是在 Java 环境中,允许完成跨越多个 XA 资源的分布式事务。JTA 的接口比较简单,但是实现起来却比较复杂,事实上很少有人尝试使用基于 XA 资源的分布式事务,JTA 往往被框架(例如 Spring)做为底层的本地事务接口,实现业务逻辑的事务一致性声明。在事务声明方面 EJB 作出了很大贡献,是他率先将 Required、RequiresNew、Mandatory、NotSupported、Supports、Never 这样的事务声明引入到 Java 的体系中,后来在 Spring 中被广泛大家使用了,而 JTA 正是这一实现的支撑。在微服务架构中,本地事务还应该是这种方式,麻烦的是远程服务的事务。对分布式事务的实现方式,请参考我的同事田向阳《微服务架构下的数据一致性保证(一)》和刘相《分布式事务:不过是在一致性、吞吐量和复杂度之间,做一个选择》的文章,在此之上,我们也应该参考 EJB 或者 Spring 的方式,用事务声明的方式维护数据的一致性,当然这个声明会远远复杂于本地事务。

**
**

6、JMS:通过 JMS 看成功的 JavaEE 规范

Java 消息服务(JavaMessage Service)是一个 Java 平台中关于面向消息中间件(MOM)的 API,用于在两个应用程序之间,或分布式系统中发送消息,进行异步通信。应该说 JMS 规范的使用还是很多的,是 JavaEE 中比较成功的一个规范,除应用服务器之外的很多消息系统也都支持这个规范(例如 kafka)。既然是一个很受欢迎的规范,对这个技术本身我没什么可说的,继续保持发扬吧,我想说的是,这个规范为什么做的好,受欢迎。究其原因是当时人们对于消息编程的理解比面向对象编程更加深刻,面向批处理编程、面向消息编程是在面向对象编程之前的状态,JavaEE 规范的出现正是人们基于 Java 这样面向对象的语言实现企业应用的过程,这也证明严格的面向对象方式实现企业分布式应用并不是好的选择,在 JavaEE 规范中使用比较好的 JSP、Servlet、JDBC、JMS 等都不是面向对象的编程模式,JSP 是模板式的、Servlet 是请求响应式的、JDBC 是面向结果集的、JMS 是面向消息的。

**
**

7、从 JavaEE 部署规范看 Docker 与微服务架构的关系

JavaEE 规范中,EAR、WAR、JAR 的部署模式是大家最常见的方式,按照 JavaEE 的设想,每一个模块都是一个独立的可部署单元,前端界面、后端服务都是可以独立部署的,而应用服务器对多个模块进行统一管理。但是,由于 JavaSE 天然的缺陷,应用之间难以实现隔离,而应用对第三方类库的依赖也让多应用的管理变得难以接受。而 Docker 的到来既实现了应用的隔离,也加快了应用的部署。所以,我把 Docker 用在应用的部署上,用于解决 JavaEE 没有解决好的问题上。在我看来,Docker 不是一个轻量级的虚拟机,他不应该仅仅用在替换虚拟机上,而是把他们之间的区分使用,把资源的分配、安全等问题交给虚拟机,而 Docker 象 EAR 一样做应用的打包工具,这样,把 Docker 部署在虚机上就不显的奇怪了,谁会对 EAR 部署在虚机上感到奇怪呢?

最后,我要说的是 JavaEE 规范建立在三层 / 多层应用架构体系之上(如下图左),但在数字化时代应用程序必须支持多个客户端渠道(例如,桌面,移动,社交),并且这些前端应用程序与后端服务交付(如下图右)。未来 SOA 仍然是企业架构的核心,但 SOA 的实现将从 JavaEE 的三层架构向轻量级的微服务架构演进,API 是服务的接口,微服务架构则代表了提高敏捷性和可伸缩性的范例。我们提供的微服务应用平台,其实就是实现新一代的应用服务器:将中间件微服务化,将微服务工程化。

在下图上,我把微服务架构中与 JavaEE 规范对应的部分画出来,供大家在实现微服务时做参考: