為何 Java EE 是更好的選擇

這些天，似乎每個人都在談論微服務的好處和新架構。大多數關于微服務新豪華架構的文章都認為，Java EE 運行慢，內容單一，而且規模小 。看起來人們對Java EE的認識存在很大的誤區。我認為微服務新世界的年輕追隨者們還不夠了解Java EE的理念。就每個開發者都會遇到的問題，我舉出三個例子，相信你對Java EE會有不一樣的認識。

數據庫連接池

如果你在開發一個應用, 大部分情況下，你將訪問數據庫對數據進行讀寫操作。 在Java中使用一個JDBC連接來實現對數據庫進行操作。 每一種數據庫都有一個對應的數據庫驅動并且使用起來非常簡單。 但是打開一個JDBC連接,從數據庫中檢索數據,最后關閉連接，都是在你的代碼中必須要做的工作。 因為創建JDBC連接花費昂貴,所以一個好的解決辦法是盡可能地在多個查詢或更新中重用這些連接。

這就需要連接池，如果你熟悉這些概念并且知道如何處理一個JDBC連接池,你可能會樂于實現自己的連接管理器。 但是如果你不熟悉相關概念,你應該留意,或者你應該看一看Java EE。 一個Java EE應用服務將你的代碼與JDBC連接解耦。 如果你需要訪問一個數據庫,你只需要注入一個JNDI數據庫資源。 數據庫資源完全被應用服務以連接池管理。

請注意下面的圖片,該圖片是Wildfly的管理界面的截圖：

你不僅可以管理連接池，還可以對驗證,超時設置,內部緩存的預編譯語句進行管理。 上述功能使得你可以細粒度的管控數據庫連接。 我不太相信（所謂的）新的實踐，即“讓我們 啟動一個 tomcat新實例”是一個合適的解決方案。

服務

下一個例子是用一段簡單的代碼實現一些業務邏輯。假設這段代碼執行一個復雜的計算，用時或多或少。這樣問題就產生了，一個較長時間的執行過程會阻礙其它調用。該怎么辦呢？當然我們可以啟動更多的 Tomcat 服務器，但對于當前這個例子，這種解決方案是非常昂貴的，還不用說可能有些執行過程還會花更長的時間。另一種解決方法是構建和管理一個服務池，每個服務都實現了我們的業務邏輯（這稱之為工廠模式）。我們可在多個調用間共享這些服務，而不需要重新實例化，這也是發明 EJB 的原因。EJB 是可以在多線程運行環境中分享的一小段代碼。再來看看 Wildfly 的某頁配置：

應用服務器的 EJB 容器可以通過各種方法來配置。可以配置 Bean 和線程池，以及這些池在集群中如何工作。有幾種 EJB 類型適應不同的問題。因此如果有復雜的邏輯，簡單無會話狀態的 EJB 能大部分問題——甚至是僅在一臺應用服務器上。

事務處理

我想討論的最后一個用例是事務管理，它是軟件開發中最復雜的問題之一。如果你遇到了需要一個或多個數據庫連接的HTTP請求，同時還必須為不同的業務邏輯執行不同的代碼組，那么在一個獨立的操作中處理所有事情將變得非常困難。事務管理是Java EE中的核心概念之一，不管你需要哪一種類型的service EJB或者哪一種JNDI源。每個請求都可以通過服務器在不同的容器中以一個或多個事務管理。對于絕大多數軟件項目來說，幾乎不可能獨立的處理所有的問題和基本事務并正確執行它們。再看一下Wildfly中事務子系統中的一個配置頁面。

總結

我在這里到底需要傳遞什么信息呢？開發商業應用是一個復雜的問題。 在性能和擴展性方面很多的細節需要被考慮。 但是這些細節從軟件開發之初直至開發完的兩年內都不易被發現。 Java EE 提供了一個平臺能夠規避掉大量細節問題。 因此如果你不是 Amazon, Netflix, 或者 Facebook 的架構師,最好不要不經思索采用他們的策略。 微服務是個好辦法，并且我相信將一個業務邏輯封裝成一個獨立的服務是值得的,但是很多情況下這也依賴于Java EE.