微服务架构模式是否与EJB 1.0类似？

Question

我们在微服务中看到的是一个孤立的组件，通过线路通过协议与该组件的父消费者进行通信。

我们看到与EJB 1.0非常相似的模式。

我的问题是：微服务架构模式与EJB 1.0类似吗？

Answer 1

虽然与原始EJB规范背后的想法有一些相似之处，但微服务正在做些什么，但存在许多差异。

EJB提供了一种构建基于组件的体系结构的标准化方法，通过契约确保bean的产品可以被其他体系结构使用，同时抽象出事务，状态和线程管理。构建组件的想法非常相似，最大的变化是我们现在正在调用这些组件服务。基于合同的发展理念也是类似的。

下面提供了一些高级差异：

在EJB Sun状态规范中，企业bean旨在成为相对粗粒度的业务对象＆＃34;这是一个很好的微服务实现的诅咒。对于微服务，最好的设计是有限的关注点。

在EJB 1.x体系结构中，容器是持久性提供程序，而在微服务体系结构中，每个服务都管理自己的数据和持久性。

通过微服务模式，通过最小化范围简化事务管理，并且不会让事务跨越微服务边界。

使用微服务线程池是服务的每个服务或实例。如果线程池已用尽，则理想情况下会生成另一个服务实例。在EJB 1.x环境中，线程管理是容器的责任。

微服务架构和EJB 1.x架构之间还有许多其他差异，但这些是一些亮点。我已经使用过这两种架构的实现，到目前为止，微服务架构的维护成本似乎更低。特别是在考虑混乱时，EJB已经成为单片架构。

Answer 2

我从未直接使用EJB，但我曾与EJB团队合作，主要是创建与EJB服务交互的微服务（包括服务器和客户端）。

恕我直言，与EJB的最大区别在于它是为处理更大的应用程序而创建的。构成EJB的方面和技术有很多。在考虑使用小型微服务时，其中一些似乎有些过分。当项目更大时，这些技术在实施它们上花费的成本更高。同样，这是一个主观意见。在创建小型微服务时，您会意识到架构的简单性以及所使用的技术可以保持在最低限度。

尽管如此，我认为EJB可以在微服务环境中有效使用。关键是保持应用程序容器小巧灵活，并能够轻松地通过HTTP与其他服务协同工作。