晚上看了一篇从JavaEE谈微服务的文章，里面不少观点还是很有启发的，下面最有感触的，从失败的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容器当中，虽然这是一个不成功的尝试，但这些都是微服务架构需要考虑的问题。