摘要：本文主要介紹了利用生態(tài)系統(tǒng)構(gòu)建微服務(wù)的多種方法，并分析了每種方法的利弊。也不例外，本文探討了使用生態(tài)系統(tǒng)來構(gòu)建微服務(wù)的幾種不同方式。另一種單部署就是使用一個嵌入式框架來構(gòu)建服務(wù)。在中，和項目對構(gòu)建微服務(wù)提供了很好的支持。

【編者按】微服務(wù)背后的大理念是將大型、復(fù)雜且歷時長久的應(yīng)用在架構(gòu)上設(shè)計為內(nèi)聚的服務(wù)，這些服務(wù)能夠隨著時間的流逝而演化。本文主要介紹了利用 Java 生態(tài)系統(tǒng)構(gòu)建微服務(wù)的多種方法，并分析了每種方法的利弊。

在 Java 生態(tài)系統(tǒng)中構(gòu)建微服務(wù)的策略主要有：container-less, self-contained 和 in-container；

Container-less 微服務(wù)把應(yīng)用程序及其所有依賴打包成單一的 jar 文件；

Self-contained 微服務(wù)也會將應(yīng)用及其依賴打包成單一的Jar文件，但它還包含可能含有第三方庫的嵌入式框架；

In-container 微服務(wù)會打包一個完整的 Java EE 容器，并且它的服務(wù)是在 Docker image 中實現(xiàn)。

基于微服務(wù)的架構(gòu)設(shè)計是架構(gòu)師和程序員們面臨的一項新挑戰(zhàn)。然而，隨著語言及工具的不斷更新，架構(gòu)師們完全有能力征服這樣的挑戰(zhàn)。 Java 也不例外，本文探討了使用Java生態(tài)系統(tǒng)來構(gòu)建微服務(wù)的幾種不同方式。

本文不會討論微服務(wù)的好與壞，也不會建議你提前為微服務(wù)設(shè)計應(yīng)用程序，或當(dāng)它們出現(xiàn)在你龐大的應(yīng)用中時，是否應(yīng)該剝離這些微服務(wù)。

本文介紹的方法并不是唯一的，但應(yīng)該可以達到拋磚引玉的效果。盡管本文的重點是使用 Java 生態(tài)系統(tǒng)來構(gòu)建微服務(wù)，但這些概念同樣可以轉(zhuǎn)移到其它語言和技術(shù)中。

筆者把本文用到的方法命名為 container-less、self-contained 和 in-containe。這些名稱或許不是非常正式，但足以區(qū)分相互間的差別。接下來，筆者會詳細描述每種方法。

在此方法中，開發(fā)者會將 JVM 之上的任何事物視為應(yīng)用程序的一部分。

container-less 方法會啟用所謂的單 jar 部署（也可稱作“fat jar部署”），這也就意味著，應(yīng)用程序及其所有依賴都會被打包成單一的jar文件，并且作為獨立的Java進程運行。

$ java -jar myservice.jar

該方法的第一個優(yōu)點就是當(dāng)對應(yīng)用的規(guī)模進行伸縮時，服務(wù)很容易按需求快速啟動和停止；另一優(yōu)點是方便部署，你只需要傳遞一個 jar 文件即可。

該方法的缺點就是庫的兼容性。對于事務(wù)支持這類問題，你需要自己來實現(xiàn)，或必須引入第三方庫才能實現(xiàn)。而后，如果你需要更多支持，例如持續(xù)性問題的支持，你就需要解決第三方庫之間的兼容性問題。

另一種單 jar 部署就是使用一個嵌入式框架來構(gòu)建服務(wù)。在此方法中，框架提供了所需服務(wù)的實現(xiàn)方法，開發(fā)者可以選擇在項目中包括哪些服務(wù)。

你可能會認為這個方法與 container-less 完全一樣，但筆者認為，兩者的區(qū)別在于，self-contained 方法會提供一套相互兼容的第三方庫。所以，該方法不存在庫兼容性問題。

該方法可能涉及 Spring Boot、Wildfly Swarm 之類的工具。

在Java中，Spring Boot 和 Spring Cloud Netflix 項目對構(gòu)建微服務(wù)提供了很好的支持。 Spring Boot 允許你選擇各種 Spring 工具和其它流行的工具，然后把它們和你的應(yīng)用打包成一個 jar 文件。Spring Initializr 提供了一個簡單的復(fù)選框列表來完成上面這些事。一個簡單的Hello World服務(wù)示例如下： Gist Snippet

在 Java EE 中，和 Spring Boot 相對應(yīng)是 Wildfly Swarm 。它允許你根據(jù)自己的需求挑選 Java EE 規(guī)范，然后把它們和你的應(yīng)用程序打包成一個 jar 文件。這里有一個簡單的 Hello World 示例：Gist Snippet。

self-contained 方法的優(yōu)點是你可以自主選擇用于服務(wù)運行的項目。

這種方法的缺點是配置更加復(fù)雜，由于它在實際的服務(wù)中構(gòu)建所需的容器功能，由此產(chǎn)生的 jar 文件也會稍大一些。

雖然在 Java EE 容器中部署微服務(wù)的開銷似乎很大，然而，一些開發(fā)者認為，微服務(wù)中的“微”并不表示該服務(wù)的小或者簡單。

在這些案例中，將 Java EE 容器作為所需平臺似乎是合適的。因此，你唯一需要的依賴就是 Java EE API 。注意，由于該依賴的實現(xiàn)是由容器提供的，因此該依賴項已經(jīng)滿足了，這也就意味著所產(chǎn)生的 war 文件是非常精簡的，該服務(wù)的實現(xiàn)與上面 Wildfly Swarm 的例子是一樣的：Gist Snippet。

該方法的優(yōu)點是，容器通過標(biāo)準 API 提供了經(jīng)過測試和驗證的標(biāo)準功能的實現(xiàn)。因此，開發(fā)者可以完全聚焦于業(yè)務(wù)功能，并在應(yīng)用代碼之外維護底層代碼。

另一個優(yōu)點是，應(yīng)用程序代碼不依賴 Java EE 應(yīng)用服務(wù)器，無論該應(yīng)用部署到 GlassFish、WildFly、WebLogic、WebSphere 還是任何與 Java EE 兼容的其他實現(xiàn)系統(tǒng)。

該方法的缺點是你需要把服務(wù)部署到容器中，這樣就增加了部署的復(fù)雜性。

現(xiàn)在來談?wù)?Docker 。通過把 Java EE 容器和服務(wù)實現(xiàn)打包到 Docker 鏡像，你可以得到與單一 jar 部署相似的結(jié)果。唯一的不同是服務(wù)打包在 Docker 鏡像中，而不是在 jar 文件中。

Dockerfile
FROM jboss/wildfly:9.0.1.Final
ADD myservice.war /opt/jboss/wildfly/standalone/deployments

在 Docker 引擎中啟動 Docker 鏡像可以喚醒服務(wù)：

$ docker run -it -p 8081:8080 myorganization/myservice

細心的讀者可能已經(jīng)在先前的 Spring Boot 代碼段中注意到了 @EnableEurekaClient 注解。該注解在 Eureka 中注冊服務(wù)，使其能夠被服務(wù)消費者發(fā)現(xiàn)。 Eureka 是 Spring Cloud Netflix 包的一部分，并且是一個極易使用和配置服務(wù)發(fā)現(xiàn)的解決方案。

Java EE 在外部并沒有提供這樣的功能，但是有一些開源解決方案可以使用，其中一個就是 Snoop，它的功能與Eureka相似。要使 Java EE 微服務(wù)支持任務(wù)查找，唯一要做的是使用 @EnableSnoopClient 注解，如本例所示：Gist Snippet。

在構(gòu)建微服務(wù)時， Java 是一個非常好的選擇。本文中介紹的任何一種方法都可以實現(xiàn)微服務(wù)。當(dāng)然，最好的方法還是根據(jù)服務(wù)需求而定。對于簡單的服務(wù)， container-less 或者 self-contained 服務(wù)就是不錯的選擇。不過，借助 in-container ，開發(fā)者可以更快更簡單地實現(xiàn)更高級的服務(wù)。無論針對哪種服務(wù)，Java 生態(tài)系統(tǒng)都能提供行之有效的實現(xiàn)方法。

（編譯自：https://dzone.com/articles/building-microservices-with-java ）

OneAPM 為您提供端到端的 Java 應(yīng)用性能解決方案，我們支持所有常見的 Java 框架及應(yīng)用服務(wù)器，助您快速發(fā)現(xiàn)系統(tǒng)瓶頸，定位異常根本原因。分鐘級部署，即刻體驗，Java 監(jiān)控從來沒有如此簡單。想閱讀更多技術(shù)文章，請訪問 OneAPM 官方技術(shù)博客。
本文轉(zhuǎn)自 OneAPM 官方博客