Java有哪12要素和其他因素？

Java有哪12要素和其他因素？

1. 单个代码库

◆  ◆  ◆

虽然少了一个特定的 Java 概念，这个因素一般是指单个代码库在源代码控制或管理一组的存储库是来自于一个共同的根源。 获取单个代码库 使它的构建更简洁，并在各种环境下推出任意数量不同的发布版本。当你的应用程序是由一打或者更多的代码库构成的，那么这就是最好的反面案例。虽然使用一个代码库来生产多种可以工作的应用程序是可行的，但其目标是在应用和代码库间生成一对一的关系。虽说操作通过一个代码库就可以做到，但也充满挑战。有时候，对一个团队或者组织来说，一个应用程序对应一个代码库是最简单的关系。

2. 依赖管理

◆  ◆  ◆

大多数 Java (以及 Groovy) 开发者可以利用像 Maven (以及 Gradle) 这样的工具，来声明你的应用程序正确构建和执行所需的依赖项。这个想法还可以让工具确保这些依赖关系得到满足，同时把它们打包成一个单一的二进制部署的工件（artifact）。像 Maven Shade 或 Spring Boot 这些插件可以将你的应用程序及其依赖项打包进单个 “uberjar” 或者 “fat jar” 文件中，从而提供了隔离这些依赖关系的方法。

图1是示例Spring Boot应用程序Maven构建文件pom.xml的一部分。 显示了开发人员指定的依赖性声明。

图1：显示应用程序依赖关系的POM.xml的一部分

<parent>

    <groupId>org.springframework.boot</groupId>

    <artifactId>spring-boot-starter-parent</artifactId>

    <version>1.3.7.RELEASE</version>

    <relativePath/> <!-- lookup parent from repository

    -->

</parent>

<dependencies>

    <dependency>

        <groupId>org.springframework.cloud</groupId>

        <artifactId>spring-cloud-starter-config</artifactId>

    </dependency>

    <dependency>

        <groupId>org.springframework.cloud</groupId>

        <artifactId>spring-cloud-starter-eureka</artifactId>

    </dependency>

    <dependency>

        <groupId>org.springframework.cloud</groupId>

        <artifactId>spring-cloud-starter-zipkin</artifactId>

    </dependency>

图2是在同一应用程序内列出的依赖性的一部分，显示了捆绑到应用程序的uberjar中的JAR包，其将这些依赖关系与底层环境中的变化隔离。 应用程序将依赖于这些依赖关系，而不是部署目标中存在的潜在冲突的库。

图2：MVN依赖的一部分：一个示例应用程序树

[INFO] Scanning for projects...

[INFO]

[INFO] ------------------------------------------------------------------------

[INFO] Building quote-service 0.0.1-SNAPSHOT

[INFO] ------------------------------------------------------------------------

[INFO]

[INFO] --- maven-dependency-plugin:2.10:tree (default-cli) @quote-service ---

[INFO] com.example:quote-service:jar:0.0.1-SNAPSHOT

[INFO] +- org.springframework.cloud:spring-cloud-starterconfig:jar:1.1.3.RELEASE:compile

[INFO] | +- org.springframework.cloud:spring-cloud-starter:jar:1.1.1.RELEASE:compile

[INFO] | | +- org.springframework.cloud:spring-cloud-context:jar:1.1.1.RELEASE:compile

[INFO] | | | \- org.springframework.security:springsecurity-crypto:jar:4.0.4.RELEASE:compile

[INFO] | | +- org.springframework.cloud:spring-cloud-commons:jar:1.1.1.RELEASE:compile

[INFO] | | \- org.springframework.security:spring-securityrsa:jar:1.0.1.RELEASE:compile

[INFO] | | \- org.bouncycastle:bcpkixjdk15on:jar:1.47:compile

[INFO] | | \- org.bouncycastle:bcprovjdk15on:jar:1.47:compile

[INFO] | +- org.springframework.cloud:spring-cloud-configclient:jar:1.1.2.RELEASE:compile

[INFO] | | \- org.springframework.boot:spring-boot-autoconfigure:jar:1.3.7.RELEASE:compile

[INFO] | \- com.fasterxml.jackson.core:jacksondatabind:jar:2.6.7:compile

[INFO] | \- com.fasterxml.jackson.core:jacksoncore:jar:2.6.7:compile

[INFO] +- org.springframework.cloud:spring-cloud-startereureka:jar:1.1.5.RELEASE:compile

[INFO] | +- org.springframework.cloud:spring-cloud-netflixcore:jar:1.1.5.RELEASE:compile

[INFO] | | \- org.springframework.boot:springboot:jar:1.3.7.RELEASE:compile

3. 编译，发布，运行

◆  ◆  ◆

一个独立的代码库是通过编译构成并生成独立构件；然后和项目外部的配置信息进行合并。代码库随后被发布到云环境下运行。千万不要在运行期间改变代码。由于系统提供了使用相同方式把构件组装到一起的单独的位置，编译的思想在于自然地过渡到下一步的集成 (CI)。

现代的Java框架可以生成uberjars文件,或者更传统的WAR文件, 这些文件作为独立的容易集成的构件。发布阶段主要是合并外部的配置信息(参考下面的配置)和独立的项目构件以及像JDK，OS，和Tomcat这样的依赖。目的是生成可执行的、版本化的、可以撤销的发布版本。云平台拿到发布版本后使用一种严格独立的方式来处理运行阶段。

4. 配置

◆  ◆  ◆

这一要素是具体化配置的形式，随着部署环境的变化有所不同。(开发, 演示, 生产). 配置信息无处不在: 分布在应用的代码中, 在如YAML这样的属性源文件中, Java属性, 环境变量, CLI参数, 系统参数, JNDI, 等等。有多重解决方案—重构代码以寻找环境变量。

对于简单的系统, 一个最直接的方案是使用Java的System.getenv()功能从环境中拿到一个或者多个配置信息，或者全部key值和value值的Map. 图 3是代码示例.

图 3: POM.xml的一部分，显示应用程序依赖关系

private String userName = System.getenv(“BACKINGSERVICE_UID”);

private String password = System.getenv(“BACKINGSERVICE_PASSWORD”);

对于更复杂的系统, Spring Cloud和Spring Boot 更流行,它们提供了强大的功能来控制源文件以及解析配置数据。

5. 日志

◆  ◆  ◆

日志应该被视为事件流：一个由应用产生的具有时序性的事件序列。 因为你不能使用文件的形式在云上记录日志，所以你要你需要将日志输入到stdout/stderr上，让云端提供者或相关工具来处理。例如， Cloud Foundry的loggregator将日志以流的形式输出，以供日志聚合和集中管理。在java中以stdout/stderr的方式记录日志的简单实例如下:

Logger log = Logger.getLogger(MyClass.class.getName());

log.setLevel(Level.ALL);

ConsoleHandler handler = new ConsoleHandler();

handler.setFormatter(new SimpleFormatter());

log.addHandler(handler);

handler.setLevel(Level.ALL);

log.fine(“This is fine.”);

6. 自由支配

◆  ◆  ◆

如果一段流程需要一段时间来启动或关闭，那么该流程需要分离一个后台服务并优化提高相应性能。

一个依赖云建立的程序是可自由支配的—它能在任何时间被创建或者销毁。这种设计有助于确保服务长时间运行良好，并且使你从这种类似于自动扩展的特性中受益。

7. 支持服务

◆  ◆  ◆

一个支持服务是一些你的app依赖的外部事物，例如一个数据库或者一个消息服务器。 app应该以外部配置的方式声明所需的支持服务，例如YAML或者一个跟踪配置服务。一个云平台处理绑定你的app到相应服务，理想情况下绑定或重新绑定不需要重新启动你的app。这种松耦合有许多优势,例如允许你使用断路器模式优雅地处理一个强迫停运的情景

8. 环境一致

◆  ◆  ◆

共同开发和QA沙箱环境，从生产规模和可靠性角度与生产环境比都有不同，但你不能使用一个“雪花”（差距过大，无法正确评估性能）环境！云平台保持多app环境一致并且可以消除调试环境的差异。

9. 管理流程

◆  ◆  ◆

这些就像计时器任务，一次性脚本，以及其他你使用shell编程可能做的事情。来自云平台的支持服务和其他功能可以帮助运行这些， 虽然Java（目前）没有提供像Python或Ruby这样的shell，但是生态系统有很多选项，可以方便地运行一次性任务或者创建一个shell接口。

10. 端口绑定

◆  ◆  ◆

在非云环境中，通常能看到几个应用程序在同一个容器中运行，通过端口号分隔每个应用程序，然后使用DNS提供一个友好的名称来访问。 而在云端，你避免了这种微管理——云提供者会根据进程和缩放比例来管理端口分支。

虽然它可能依赖外部机制，为您的app提供流量，但这些机制在容器、机器与平台之间各不同。端口绑定为你提供全量控制，提示你该如何接收与响应应用请求，而不管其部署在哪里。

11. 进程

◆  ◆  ◆

这里提及的原始12-因素定义指出app是无状态的。但是，有一些状态需要出现在指定的地方。沿着这些线，这个因素提倡将任何长期运行的状态转换为高速缓存或者数据存储，来实现外部的、逻辑的支撑服务。

12. 并发

◆  ◆  ◆

云平台构建为可以水平扩展。 这里的设计考虑到 - 你的应用程序应该是一次性的，无状态的，并使用无共享的过程。 使用平台的流程管理模型对于利用自动缩放，blue-green部署等功能非常重要。

java直播资料思维交流群：175161984（←长按可复制）获取学习资料可