微服務架構模式與EJB 1.0類似嗎？

Question

我們在microservices上看到的是一個孤立的組件，通過協議通過網絡與該組件的父消費者進行通信。

我們看到一個與EJB 1.0非常相似的模式。

我的問題是：類似於EJB 1.0的微服務架構模式？

Answer 1

我從來沒有直接使用過EJB，但我曾與EJB團隊合作過，主要是創建與EJB服務交互（作爲服務器和客戶端）的微服務。

恕我直言，與EJB的最大區別在於它被創建用於處理更大的應用程序。有很多方面和組成EJB的技術。當考慮一個小型微服務時，他們中的一些看起來過於矯枉過正。這些技術在項目規模較大時花費在實施這些技術上的成本更高。再次，這是一種主觀意見。在創建小型微服務時，您會意識到架構非常簡單，所使用的技術可以保持在最低限度。如上所述，我認爲EJB可以在微服務環境中有效地使用。關鍵將是保持應用程序容器小而靈活，並且能夠輕鬆地通過HTTP與其他服務協同工作。

Answer 2

儘管與原始EJB規範背後的想法有些相似之處，以及微服務正在做些什麼，但存在許多差異。

EJB提供構建基於組件的架構，與合同，以確保bean的產品可以通過其他架構消耗標準的方式，而抽象掉交易，狀態和線程管理。構建組件的想法非常相似，最大的變化是我們現在稱這些組件服務。合同開發的想法也是類似的。

一些高層次的差異提供了以下：

內規範EJB陽光州「企業豆意圖是相對粗粒度的業務對象」，這是詛咒一個良好的微服務實現。對於微服務來說，最好的設計是一個有限的環境，只有一個問題。

在EJB 1.x的架構容器是持久性提供，而在微服務架構的每個服務管理自己的數據和持久性。

通過微服務模式事務管理可以通過最小化範圍來簡化，並且永遠不會跨越微服務邊界進行事務處理。

微服務線程池是服務的每個服務或實例。如果線程池耗盡，理想情況下，你會產生另一個服務實例。在EJB 1.x環境中，線程管理是容器的責任。

微服務體系結構和EJB 1.x體系結構之間還有許多其他差異，但這些都是一些亮點。我已經與兩種架構的實現合作，並且微服務架構的維護成本似乎較低。特別是在考慮混亂的EJB時，它們已經成爲單一的體系結構。