微服務 WildFly Swarm 簡介<十二>

咱們將看到的最後一個Java微服務框架是一個相對較新的場景，它利用了 JBoss WildFly 應用服務器中已試過且受信任的 JavaEE 功能。WildFly Swarm 是 WildFly 應用服務器的一個完整的拆下來的組件，能夠被組裝並造成一個利用 JavaEE API 的微服務應用程序，這些組件被稱爲片斷大小的、可重用的組件。組裝這些部分就像在 Java Maven(或Gradle) 構建文件中包含依賴項同樣簡單，而 WildFlyS 負責處理其他部分。

近15年來，應用服務器和 JavaEE 一直是企業 Java 應用程序的操縱者。WildFly(之前的 JBoss Application Server)是一個支持企業的開放源碼應用服務器。許多企業大量投資於 JavaEE 技術(不管是開放源碼的仍是專有的供應商)，從他們如何僱用軟件人才，以及總體培訓、工具和管理。JavaEE 始終可以經過提供 servlet/JSP、事務、組件模型、消息傳遞和一致性等功能來幫助開發人員構建分層應用程序。JavaEE 應用程序的部署被打包爲 EAR ，它一般包含許多 WAR、JAR 和相關配置。一旦您有了Java存檔文件(EAR/WAR)，您就須要找到一個服務器，驗證它是按照您指望的方式配置的，而後安裝您的歸檔文件。您甚至能夠利用動態部署和從新部署(雖然在生產中不建議這樣作，但它在開發中可能頗有用)。這意味着您的檔案能夠至關精簡，而且只包括你須要的商業代碼。不幸的是，這致使了 JavaEE 服務器的膨脹，必須考慮到應用程序可能須要的任何功能。它還致使了過分優化，包括哪些依賴項要共享(只需將全部內容放在應用服務器中！)以及哪些依賴項須要隔離，由於它們的變化速度與其餘應用程序不一樣。

應用服務器爲在應用服務器的單個實例中管理、部署和配置多個應用程序提供了單一的點。一般，您能夠經過在不一樣節點上建立應用服務器的實例來對它們進行集羣以得到高可用性。當太多的應用程序共享一個部署模型、一個進程和一個JVM時，問題就開始出現了。當開發應用服務器中運行的應用程序的多個團隊擁有不一樣類型的應用程序、更改速度、性能或 SLA 需求等時，就會產生阻抗。只要微服務體系結構可以實現快速變化、創新和自治，那麼 JavaEE 應用程序服務器和將應用程序集合管理爲單一的、集於一身的服務器並不能實現快速更改。此外，從操做的角度來看，精確地管理和監視在單個應用服務器中運行的服務和應用程序變得很是複雜。從理論上講，單個JVM更容易管理，由於這只是一回事，可是JVM中的應用程序都是獨立的部署，應該將其視爲獨立部署。當咱們試圖將單個進程中的單個應用程序和服務視爲「一件事」時，咱們會感到這種痛苦，這就是爲何咱們有很是昂貴和複雜的工具來嘗試和完成這種檢討。團隊解決其中一些問題的方法之一是將單個應用程序部署到應用服務器。

儘管 JavaEE 環境中應用程序的部署和管理可能不適合微服務環境，可是 JavaEE 提供給應用程序開發人員的組件模型、API 和庫仍然提供了不少價值。咱們仍然但願可以使用持久性、事務、安全性、依賴注入等等，可是咱們但願在須要的地方按̀順序使用這些庫。那麼，咱們如何利用咱們對 JavaEE (它在微服務環境中所帶來的力量)的知識呢？這就是 WildFly Swarm 羣適合的地方。

WildFly Swarm 可使用 pom.xml (或 Gradle 文件)，肯定您的微服務實際使用的 JavaEE 依賴關係(例如CDI、消息傳遞和servlet)，而後構建一個 JAR (就像 SpringBoot 和 Dropwizard 同樣)，其中包含運行服務所需的最小 JavaEE API 和實現。這個過程被稱爲「just enough application server」，它容許您繼續使用您熟悉和喜好的 JavaEE API，並以微服務和傳統應用程序風格部署它們。您甚至能夠開始使用現有的WAR項目，WildFly Swarm能夠自動和正確地審視它們，包括必要的 JavaEE API/片斷，而沒必要顯式地指定它們。這是一種將現有應用程序遷移到微服務風格部署的很是強大的方法。

 

原文：

做者源碼：https://github.com/redhat-developer/microservices-by-example-source

有什麼討論的內容，能夠加我微信公衆號：