如何使用Java和Docker构建微服务.docxVIP

如何使用 Java 和 Docker 构建微服务 快速浏览 在 Java 生态中，构建微服务的策略包括 Self-contained ，以及 In-container 等。  Container-less， Container-less 微服务将应用及其依赖打包成一个单一的 jar 文件。 Self-contained 微服务也是打包成一个单一的 Jar 文件，但它还包括一个嵌入式框架， 这个框架含有可选的第三方 lib ，当 然这些  lib  是兼容的。 In-container 微服务打包成一个完整的 Java EE 容器，该服务 在 Docker 镜像中实现。 介绍 本文不会探讨微服务是好还是坏，也不会建议你应该事先使 用微服务设计你的 app，或者当他们在 monolith 应用出现时， 就应该提取这些服务。 这里所描述的方法并不是唯一的，但它可以让你对这些可能 性有一个良好的纵览。即使 Java 生态是本文所关注的领域， 但这些理念也可传递到其他语言和技术中。 在文中，我将这几种方法分别称为 Container-less， Self-contained ，以及 In-container 。这些术语可能尚未被完全 确立，但在这里，它们可以达到区分这几种方法的目的。我 会在接下来的几个部分中阐述它们的意义。 container-less 在 Container-less 方法中，开发者要将所有位于 JVM 顶层的 一切事物作为应用的一部分。 Container-less 方法使得所谓的单一 JAR 部署成为可能 （也称 作“ fat JAR ”部署），这意味着，应用及其依赖可以打包在 一个单一的 JAR 文件，并作为一个独立的 Java 程序运行。 $ java -jar myservice.jar 这种方法的优点是：当应用在进行扩展和收缩时，服务的启 动和停止是极其轻松的。另一个优点是部署简单，你只需传 递一个 JAR 文件。 该方法的缺点是 lib 库的兼容性，你需要自己独立解决一些 像事务处理之类的事情，或者需要引入第三方 lib 库为方案 提供支持。随后，如果你需要像持久性之类的支持，你可能 需要面对 lib 库兼容性的问题。 Self-contained 另一个单一 JAR 部署的变形是使用嵌入式框架构建微服务。 在该方法中，框架提供了所需服务的实现，同时，开发者可 以选择哪一些东西要包含在该服务中。 你可能认为这与 Container-less 的解决方案一样， 但我在这里要区分一下它们，因为 self-cotained 方法允许你使用第三方 lib 库，并且你知道这些 lib 库是兼容的。 该方法涉及到像 Spring Boot 和 Wild Swarm 之类的工具。 Spring Boot Spring Boot 和 Spring Cloud Netflix 项目对使用 Java 构建微服务有着很好的支持。 Spring Boot 允许你挑选各种 Spring 生态系统中的工具，以及流行的第三方工具，并将这些工具和 你的应用打包在一起。 Spring Initializr 使得你可以使用简单 复选框列表的方式完全这一工作，这里有一个简单的 Hello World 服务的例子， Gist Sinppet。 Wildfly Swarm 在 Java EE 中，与 Spring Boot 相对应的就是 Wildfly Swarm 。 它允许你挑选所需的部分 Java EE规范，并将其和应用以 JAR 文件的形式打包在一起。 Hello World 的例子， Gist Snippet。 Self-contained 方法的优点是你可以只挑选足以让服务运行的 组件。 该方法的缺点是配置有点复杂， 以及由此产生 JAR 文件有点 大，因为它的构建是为了实际服务中所需的容器功能。 In-container 虽然要求一个完整的 Java EE 容器能够部署一个微服务，似乎需要很大的开销，但是，需要记住的是：一些开发者主张微服务的“微”不意味着这个服务要微小或简单。 在这些案例中， 将 Java EE 容器视为所需平台似乎是合适的， 因为你所需的唯一依赖是 Java EE API。注意： 由于其实现是 由容器提供，因此该依赖项已经满足了。这意味着由此产生 的 WAR 文件是极其精实的，该服务的实现和上述 Wildfly Swarm  的例子一样，参考这里，  Gist Snippet 。 这种方法的优点是该容器通过标准  APIs  提供了测试和验证 标准功能的实现，因此，作为一名开发者，你可以完全集中 于业务功能，并且在应用代码之外维护底层代码。 该方法的另一个优点是实际应用程序代码并不依赖于