8

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

我们在 EJB 1.0 中看到了非常相似的模式。

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

4

2 回答 2

6

虽然与原始 EJB 规范背后的想法和微服务所做的事情有一些相似之处，但也有很多不同之处。

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

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

  • EJB 规范指出：“企业 bean 旨在成为相对粗粒度的业务对象。” 这与良好的微服务实现形成对比，其中最好的设计是具有单一关注点的有界上下文。

  • 在 EJB 1.x 架构中，容器是持久性提供者；而在微服务架构中，每个服务都管理自己的数据和持久性。

  • 使用微服务模式，事务管理通过最小化范围和永远不会跨越微服务边界来简化。

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

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

于 2015-12-08T19:12:09.520 回答
0

我从未直接与 EJB 合作过，但我与 EJB 团队合作过，主要创建与 EJB 服务交互（作为服务器和客户端）的微服务。

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

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

于 2015-05-15T14:18:03.607 回答