关于springboot:如何构建-Spring-Boot-12-因素应用

71次阅读

共计 3817 个字符,预计需要花费 10 分钟才能阅读完成。

【注】本文译自:How to build a Spring Boot 12-Factor app (theserverside.com)
在这里,咱们看看 Spring Boot 框架如何反对十二因素利用的办法,以及 GitHub、Docker 和 Kubernetes 等工具填补了哪些空白。
    没有国际标准组织指定 Spring Boot 利用作为微服务必须满足的规范。Heroku 联结创始人 Adam Wiggins 向部署到 Heroku 平台的开发人员提供的 12 条倡议是开发人员最靠近的一套云原生开发指南。
    这 12 条戒律被称为“十二因素利用方法论”,已成为创立古代的以 Docker 和 Kubernetes 为部署指标的古代云原生微服务的事实标准。
    开发基于 Java 的微服务最风行的平台是 Spring Boot。以下是 Spring Boot 如何反对十二因素利用方法论的准则。

1. Spring Boot 代码库

    并非每个 12 因素的准则都间接映射到 Spring Boot。代码库准则就是责任落在 Spring 框架之外的一个例子。
    依据十二因素利用,每个 Spring Boot 微服务都应该有本人独立的代码库。这能够通过创立单个 Git 存储库来实现,开发人员能够在其中奉献代码、合并分支和修复谬误。如果您的 Spring Boot 利用托管在其本人的 Git 存储库中,那么您曾经正确地实现了 12 因素代码库要求。

2. 内部化依赖治理

    如果您应用 Spring Boot 初始化器创立一个我的项目,则必须在 Gradle 或 Maven 之间进行抉择作为我的项目的构建工具。这两个工具都将治理依赖项内部化。
    如果您将 JAR 文件放在我的项目的 lib 目录之外,并在 Maven POM 或 Gradle 构建文件中列出程序的所有内部依赖项,则您的 Spring Boot 应用程序将正确实现 12 因素 依赖项治理。

3. Spring Boot 和 Kubernetes 配置

    依据十二因素利用方法论,Spring Boot 应用程序应该从环境中读取其配置数据。例如,如果将云原生 Spring Boot 应用程序部署到 Docker 容器并在 Kubernetes 集群中进行治理,则应用程序应该从 Kubernetes ConfigMap 读取其配置数据——而不是从 JavaBean 字段甚至应用程序属性文件。Spring 的级联配置解决零碎齐全满足了这个 12- 因素要求。
    任何用 Spring @ConfigurationProperties 注解润饰的 JavaBean 都会在多个中央寻找配置数据。@ConfigurationProperties 润饰的 bean 的规定是始终应用最高内部化级别的配置。在 JavaBean 中硬编码的属性将被 ApplicationProperties 文件中的数据笼罩,这些数据将被 JVM 参数笼罩,最终将被 Docker 或 Kubernetes ConfigMap 提供的参数笼罩。
    应用 @ConfigurationProperties 注解,您的 12 因素 Spring Boot 利用将合乎配置。

4. 反对服务和 Spring Boot

    将反对服务视为附加资源的能力自 Java 语言一开始就曾经融入到 Java 语言中,因而即便开发人员群策群力,也很难违反这个 12 因素 束缚。
    例如,所有通过 Java 数据库连贯 (JDBC) 拜访的数据库都须要一个 URL 和驱动程序,这隐式地使数据库成为附加资源。如果不将数据库视为反对服务,就不可能在 Java 中执行 JDBC 或 JPA。NoSQL 数据库、Kafka 队列和 RESTful Web 服务也是如此。如果您在 Jakarta EE 或 Spring Boot 中编写代码,则简直必须依照 12- 因素指南将所有内部资源视为反对服务。

5. 构建、公布和运行

    开发人员遵循严格的构建、公布和运行策略的倡议仿佛有些显而易见。具备讥刺象征的是,这也可能是最常违反的 12 因素规定之一。
    这里的想法是您应该始终从您的代码库构建您的代码。公布是与版本化配置文件相关联的标记构建。它是您在服务器上部署和运行的标记构建和版本化配置数据的组合。
    不应更新在服务器上运行的代码来修复谬误。不应在运行时调整配置设置来克服 Java 性能问题。进入部署的所有代码都来自构建,它基于在裸 Git 存储库中进行版本控制的代码。
    一旦与构建配对以创立公布,配置数据就不得更改。如果须要更改,团队必须再次经验残缺的构建、公布和运行周期。不应该有违反 12 因素构建、公布和运行准则的捷径。

6. 无状态 Spring Boot 过程

    Java 和 Jakarta EE API 有许多类和接口,它们隐式地向应用程序增加状态,其中最重要的是 Servlet 和 JSP API 的 HttpSession 对象。
    为了实现 12 因素合规性,Spring Boot 为 HttpSession 提供了一个替代品,称为 Spring Session。这有助于内部化数据,否则这些数据将被有状态地保留在 Tomcat 或 Jetty 等应用程序服务器上。这是 Spring Boot 如何提供额定 API 并从新实现罕用类以确保应用程序和微服务放弃 12 因素合规性的一个次要示例。
    此外,Spring Boot 容许开发人员轻松地将 NoSQL 数据库(如 Cassandra 和 MongoDB)中的状态内部化,这也有助于简化无状态微服务的开发。
    必须指出的是,确保微服务作为无状态过程运行的责任也很大水平上落在了软件开发人员的肩上。如果开发人员决定将用户状态保留在一个实例变量中,而不是在共享资源中将该数据内部化,那么 Spring、Docker 或 Kubernetes 无奈让该应用程序作为无状态过程进行扩大。

7. 端口绑定

    端口绑定是另一个 12 因素 准则,它超出了 Spring Boot 框架的范畴。相同,Docker 容器会将 Tomcat 或 Undertow 服务器应用的外部端口映射到公共端口。在集群环境中,kubectl 实用程序会将 Kubernetes Pod 的端口绑定为公共服务。无论哪种形式,Spring Framework 都不负责端口绑定要求。
    Spring 的确提供了更改打包的 Spring Boot 应用程序外部应用的端口的能力,但 Kubernetes 或 Docker 将负责内部端口绑定,使云原生应用程序可公开拜访。

8. 并发性

    依据十二因素利用方法论,云原生利用应该可能横向扩大,以反对来自客户端的大容量并发申请 - 响应周期。只有 Spring Boot 利用是无状态的,Kubernetes 正本集就会负责应用 Docker 容器创立新的 Pod,这些容器能够同时解决一直减少的工作负载。

9. 疾速启动和敞开

    十二因素利用方法论的第 9 条准则是可处理性,它保持微服务应该疾速启动并优雅地敞开。
    为了便于解决,Spring Boot 实现了提早加载设计模式。它还执行智能初始化以缩小在云原生微服务启动时创立的对象数量。此外,当开发人员应用 Spring 框架提供的资源类时,控制能力的反转确保资源在 Kubernetes 节点耗尽或 Docker 容器下线时优雅地终止。

10. 环境之间的奇偶校验

    开发、用户验收测试、预生产和生产环境之间总会存在差别。但十二因素办法保持这些环境尽可能类似。
    为了促成环境对等,Spring Boot 构建将创立一个可运行的 JAR 文件,其中嵌入了一个应用程序服务器,例如 Tomcat。打包在 Docker 容器中的雷同嵌入式 Tomcat JAR 文件将用于每个不同的部署环境。因为每个环境都部署了雷同的编译代码和应用服务器,最终实现了环境间的对等。
    此外,Spring Profiles 提供了一种简略的办法来定义和配置须要从一个环境更改到另一个环境的属性,从而容许开发人员解决不可避免地产生的环境之间的差别。

11. 日志作为事件流

    十二因素利用保持将日志视为事件流。
    Spring Boot 应用的所有规范 Java 日志框架都将它们的数据写入事件流,该事件流被保留到运行 Docker 容器的 Kubernetes 节点上的公共目录中。而后这些日志文件很容易被 Kubernetes DaemonSets 应用,比方 FluentD 或 Logstash。这些 DaemonSet 而后将日志流式传输到 Elasticsearch 和 Logstash 等工具以供应用。
    只有您应用框架规范的 Java 日志框架,您就能够释怀,在日志耗费方面,您领有一个合乎 12 因素规范的 Spring Boot 应用程序。

12. 治理过程治理

    利用通常须要运行治理过程,这些过程与解决客户端 - 服务器交互的申请 - 响应循环没有间接分割的。依据十二因素利用,不应将实现这些过程的代码放在独自的代码库中。治理过程应打包为规范的、受版本控制的构建的一部分,并且过程自身应在利用应用的雷同运行时环境中执行。
    在云原生 Spring Boot 应用程序中增加对治理过程的反对非常容易。Spring Batch 我的项目能够轻松增加对运行一次并退出的作业的反对。此外,任何 Git 存储库都能够配置为蕴含文件夹,这些文件夹容许增加能够在须要时在 REPL shell 中运行的脚本。
    云原生微服务的开发没有明确的规范,但十二因素利用办法很靠近。如果您是一名 Java 开发人员并且想要创立 12 因素利用,Spring Boot 将帮忙您的团队放弃云原生合规性。

正文完
 0