SpringCloud中文文档参考手册中文版2018

Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具（例如配置管理，服务发现，断路器， 智能路由，微代理，控制总线）。分布式系统的协调导致了样板模式, 使用Spring Cloud开发人员可以快速地支持 实现这些模式的服务和应用程序。他们将在任何分布式环境中运行良好，包括开发人员自己的笔记本电脑，裸机数 据中心，以及Cloud Foundry等托管平台。

特性

Spring Cloud专注于提供良好的开箱即用经验的典型用例和可扩展性机制覆盖。

分布式/版本化配置

服务注册和发现

路由

service - to - service调用

负载均衡

断路器

分布式消息传递

云原生应用程序

云原生 (https://pivotal.io/platform-as-a-service/migrating-to-cloud-native-application-architectures-ebook)是一种应用开发风格，鼓励在持续交付

和价值驱动开发领域轻松采用最佳实践。相关的学科是建立12-factor Apps (http://12factor.net/)，其中开发实践与交付和运营目标相一致，

例如通过使用声明式编程和管理和监控。Spring Cloud以多种具体方式促进这些开发风格，起点是一组功能，分布式系统中的所有组件都需

要或需要时轻松访问。

许多这些功能都由Spring Boot (http://projects.spring.io/spring-boot)覆盖，我们在Spring Cloud中建立。更多的由Spring Cloud提供为两个

库：Spring Cloud Context和Spring Cloud Commons。Spring Cloud上下文为Spring Cloud应用程序（引导上下文，加密，刷新范围和环

境端点）的 ApplicationContext 提供实用程序和特殊服务。Spring Cloud Commons是一组在不同的Spring Cloud实现中使用的抽象和

常用类（例如Spring Cloud Netflix vs. Spring Cloud Consul）。

如果由于“非法密钥大小”而导致异常，并且您正在使用Sun的JDK，则需要安装Java加密扩展（JCE）无限强度管理策略文件。

Spring Cloud上下文：应用程序上下文服务

Spring Boot对于如何使用Spring构建应用程序有一个看法：例如它具有常规配置文件的常规位置，以及用于常见管理和监视任务的端点。

Spring Cloud建立在此之上，并添加了一些可能系统中所有组件将使用或偶尔需要的功能。

引导应用程序上下文

一个Spring Cloud应用程序通过创建一个“引导”上下文来进行操作，这个上下文是主应用程序的父上下文。开箱即用，负责从外部源加载配

置属性，还解密本地外部配置文件中的属性。这两个上下文共享一个 Environment ，这是任何Spring应用程序的外部属性的来源。

Bootstrap属性的优先级高，因此默认情况下不能被本地配置覆盖。

引导上下文使用与主应用程序上下文不同的外部配置约定，因此使用 bootstrap.yml application.yml （或 .properties ）代替引导

和主上下文的外部配置。

例：

bootstrap.yml

如果您的应用程序需要服务器上的特定于应用程序的配置，那么设置 spring.application.name （在 bootstrap.yml 或application.yml ）中是个好主意。

您可以通过设置 spring.cloud.bootstrap.enabled=false （例如在系统属性中）来完全禁用引导过程。

应用程序上下文层次结构

如果您从 SpringApplication 或 SpringApplicationBuilder 构建应用程序上下文，则将Bootstrap上下文添加为该上下文的父级。这

是一个Spring的功能，即子上下文从其父进程继承属性源和配置文件，因此与不使用Spring Cloud Config构建相同上下文相比，“主”应用

程序上下文将包含其他属性源。额外的财产来源是：

“bootstrap”：如果在Bootstrap上下文中找到任何 PropertySourceLocators ，则可选 CompositePropertySource 显示为高优先

级，并且具有非空属性。一个例子是来自Spring Cloud Config服务器的属性。有关如何自定义此属性源的内容的说明，请参阅 下文。

“applicationConfig：[classpath：bootstrap.yml]”（如果Spring配置文件处于活动状态，则为朋友）。

如果您有一个bootstrap.yml （或属性），那么这些属性用于配置引导上下文，然后在父进程设置时将它们添加到子上下文中。它们的优先级低于

application.yml （或属性）以及作为创建Spring Boot应用程序的过程的正常部分添加到子级的任何其他属性源。有关如何自定义这 些属性源的内容的说明，请参阅下文。

由于属性源的排序规则，“引导”条目优先，但请注意，这些条目不包含来自 bootstrap.yml 的任何数据，它具有非常低的优先级，但可用

于设置默认值。

您可以通过简单地设置您创建的任何 ApplicationContext 的父上下文来扩展上下文层次结构，例如使用自己的界面，或使用SpringApplicationBuilder 方便方法（ parent() ， child() 和 sibling() ）。引导环境将是您创建自己的最高级祖先的父级。层

次结构中的每个上下文都将有自己的“引导”属性源（可能为空），以避免无意中将值从父级升级到其后代。层次结构中的每个上下文（原则

上）也可以具有不同的 spring.application.name ，因此如果存在配置服务器，则不同的远程属性源。普通的Spring应用程序上下文行

为规则适用于属性解析：子环境中的属性通过名称和属性源名称覆盖父项中的属性（如果子级具有与父级名称相同的属性源，一个来自父母

的孩子不包括在孩子中）。

请注意， SpringApplicationBuilder 允许您在整个层次结构中共享 Environment ，但这不是默认值。因此，兄弟情境尤其不需要具有

相同的资料或财产来源，尽管它们与父母共享共同点。

改变引导位置Properties

可以使用 spring.cloud.bootstrap.name （默认“引导”）或 spring.cloud.bootstrap.location （默认为空）指定bootstrap.yml （或 .properties ）位置，例如在系统属性中。这些属性的行为类似于具有相同名称的 spring.config.* 变体，实际 上它们用于通过在其 Environment 中设置这些属性来设置引导 ApplicationContext 。如果在正在构建的上下文中有活动的配置文件 （来自 spring.profiles.active 或通过 Environment API）），则该配置文件中的属性也将被加载，就像常规的Spring Boot应用程 序，例如来自 bootstrap-development.properties 的“开发”简介。

覆盖远程Properties的值

通过引导上下文添加到应用程序的属性源通常是“远程”（例如从配置服务器），并且默认情况下，不能在本地覆盖，除了在命令行上。如果

要允许您的应用程序使用自己的系统属性或配置文件覆盖远程属性，则远程属性源必须通过设置

spring.cloud.config.allowOverride=true （在本地设置本身不起作用）授予权限。一旦设置了该标志，就会有一些更精细的设置来

控制远程属性与系统属性和应用程序本地配置的位置： spring.cloud.config.overrideNone=true 覆盖任何本地属性源，

spring.cloud.config.overrideSystemProperties=false 如果只有系统属性和env var应该覆盖远程设置，而不是本地配置文件。

自定义引导配置

可以通过在 org.springframework.cloud.bootstrap.BootstrapConfiguration 键下添加条目 /META-INF/spring.factories 来

训练引导上下文来执行任何您喜欢的操作。这是用于创建上下文的Spring @Configuration 类的逗号分隔列表。您可以在此处创建要用于

自动装配的主应用程序上下文的任何bean，并且还有 ApplicationContextInitializer 类型的 @Beans 的特殊合同。如果要控制启动

顺序（默认顺序为“最后”），可以使用 @Order 标记类。

警告

添加自定义 BootstrapConfiguration 时，请注意，您添加的类不是错误的 @ComponentScanned 到您的“主”应用程序

上下文中，可能不需要它们。对于您的 @ComponentScan 或 @SpringBootApplication 注释配置类尚未涵盖的启动配置

类，请使用单独的包名称。

引导过程通过将初始化器注入主 SpringApplication 实例（即正常的Spring Boot启动顺序，无论是作为独立应用程序运行还是部署在应

用程序服务器中）结束。首先，从 spring.factories 中找到的类创建引导上下文，然后在 ApplicationContextInitializer 类型的

所有 @Beans 添加到主 SpringApplication 开始之前。

自定义引导属性源

引导过程添加的外部配置的默认属性源是Config Server，但您可以通过将 PropertySourceLocator 类型的bean添加到引导上下文（通

过 spring.factories ）添加其他源。您可以使用此方法从其他服务器或数据库中插入其他属性。

作为一个例子，请考虑以下微不足道的自定义定位器：

传入的 Environment 是要创建的 ApplicationContext 的 Environment ，即为我们提供额外的属性来源的。它将已经具有正常的

Spring Boot提供的资源来源，因此您可以使用它们来定位特定于此 Environment 的属性源（例如通过将其绑定在

spring.application.name 上，如在默认情况下所做的那样Config Server属性源定位器）。 如果你在这个类中创建一个jar，然后添加一个 META-INF/spring.factories 包含： 那么“customProperty” PropertySource 将显示在其类路径中包含该jar的任何应用程序中。

环境变化

应用程序将收听 EnvironmentChangeEvent ，并以几种标准方式进行更改（用户可以以常规方式添加 ApplicationListeners 附加

ApplicationListeners ）。当观察到 EnvironmentChangeEvent 时，它将有一个已更改的键值列表，应用程序将使用以下内容：

重新绑定上下文中的任何 @ConfigurationProperties bean

为 logging.level.* 中的任何属性设置记录器级别

请注意，配置客户端不会通过默认轮询查找 Environment 中的更改，通常我们不建议检测更改的方法（尽管可以使用 @Scheduled 注释进

行设置）。如果您有一个扩展的客户端应用程序，那么最好将 EnvironmentChangeEvent 广播到所有实例，而不是让它们轮询更改（例如

使用Spring Cloud总线 (https://github.com/spring-cloud/spring-cloud-bus)）。

EnvironmentChangeEvent 涵盖了大量的刷新用例，只要您真的可以更改 Environment 并发布事件（这些API是公开的，部分内核为

Spring）。您可以通过访问 /configprops 端点（普通Spring Boot执行器功能）来验证更改是否绑定到 @ConfigurationProperties

bean。例如， DataSource 可以在运行时更改其 maxPoolSize （由Spring Boot创建的默认 DataSource 是一个@ConfigurationProperties bean），并且动态增加容量。重新绑定 @ConfigurationProperties 不会覆盖另一大类用例，您需要更

多的控制刷新，并且您需要更改在整个 ApplicationContext 上是原子的。为了解决这些担忧，我们有 @RefreshScope 。

【下载地址】

百度网盘链接：https://pan.baidu.com/s/1hC1dhb0ARuxktUOR8on9Yw

提取码：4jtt