spring cloud帮助文档 Hoxton.SR3

第一章 特性:

Spring Cloud侧重于为典型的用例和可扩展性提供良好的开箱即用体验
  • 分布式/版本化配置
  • 服务注册与发现
  • 路由选择
  • 服务间调用
  • 负载均衡
  • 熔断机制
  • 分布式消息

第二章 发布版本

Project Name Project Version
spring-cloud-build 2.2.1.RELEASE
spring-cloud-commons 2.2.1.RELEASE
spring-cloud-function 3.0.1.RELEASE
spring-cloud-stream Horsham.SR1
spring-cloud-aws 2.2.1.RELEASE
spring-cloud-bus 2.2.0.RELEASE
spring-cloud-task 2.2.2.RELEASE
spring-cloud-config 2.2.1.RELEASE
spring-cloud-netflix 2.2.1.RELEASE
spring-cloud-cloudfoundry 2.2.0.RELEASE
spring-cloud-kubernetes 1.1.1.RELEASE
spring-cloud-openfeign 2.2.1.RELEASE
spring-cloud-consul 2.2.1.RELEASE
spring-cloud-gateway 2.2.1.RELEASE
spring-cloud-security 2.2.0.RELEASE
spring-cloud-sleuth 2.2.1.RELEASE
spring-cloud-zookeeper 2.2.0.RELEASE
spring-cloud-contract 2.2.1.RELEASE
spring-cloud-gcp 1.2.1.RELEASE
spring-cloud-vault 2.2.1.RELEASE
spring-cloud-circuitbreaker 1.0.0.RELEASE
spring-cloud-cli 2.2.1.RELEASE

第三章 云原生应用(Cloud Native Applications)

Cloud Native 是一种应用程序开发风格,它鼓励在持续交付和价值驱动开发领域轻松采用最佳实践。一个相关的规程是构建包含12个因素的应用程序,在这些应用程序中,开发实践与交付和操作目标保持一致——例如,通过使用声明式编程、管理和监视。Spring Cloud以许多特定的方式促进了这些风格的开发。起点是一组特性,分布式系统中的所有组件都需要容易地访问这些特性。
这些特性中的许多都包含在Spring Boot中,Spring Cloud是在Spring Boot上构建的。Spring Cloud还提供了其他一些特性,作为两个库:Spring Cloud Context和Spring Cloud Commons。Spring Cloud Context为Spring云应用程序的ApplicationContext(bootstrap context、encryption、refresh scope和environment endpoints)提供实用程序和特殊服务。Spring Cloud Commons是一组抽象和通用类,用于不同的Spring云实现(如Spring Cloud Netflix和Spring Cloud Consul)。
如果您由于“Illegal key size”而出现异常,并且您使用的是Sun的JDK,那么您需要安装Java Cryptography Extension (JCE) Unlimited Strength Policy文件。详情请参阅以下连结:

3.1 Spring Cloud Context: Application Context Services

Spring Boot对如何使用Spring构建应用程序有自己的看法。例如,它具有用于公共配置文件的常规位置,以及用于公共管理和监视任务的端点。Spring Cloud构建在此基础之上,并添加了一些系统中的许多组件可能会使用或偶尔需要的功能。

3.1.1 The Bootstrap Application Context

Spring cloud应用程序通过创建“bootstrap”上下文来运行,该上下文是主应用程序的父上下文。此上下文负责从外部源加载配置属性,并负责解密本地外部配置文件中的属性。这两个上下文共享一个环境,该环境是任何Spring应用程序外部属性的来源。默认情况下,bootstrap属性(不是bootstrap.properties而是引导阶段加载)具有较高的优先级,因此不能被本地配置覆盖。
Bootstrap 上下文使用与主应用程序上下文不同的约定来定位外部配置。替代application.ym(或.properties),你可以用bootstrap.yml,保持bootstrap和主上下文的外部配置的良好分离。如下:
Example 1. bootstrap.yml

spring:
  application:
    name: foo
  cloud:
    config:
      uri: ${SPRING_CONFIG_URI:http://localhost:8888}

如果您的应用程序需要来自服务器的任何特定于应用程序的配置,则最好设置spring.application.name(在bootstrap.yml 或 application.yml中)。如果spring.application.name属性被用来作为应用上下文的id,那么你必须把它配置在bootstrap.yml(.properties )中

如果你想重新制定特定的配置文件,你需要在bootstrap.[properties | yml]文件中配置spring.profiles.active。

您可以通过设置spring.cloud.bootstrap.enabled=false来完全禁用引导进程。 (for example, in system properties).

3.1.2 Application Context Hierarchies(应用上下文等级)

如果你从SpringApplication或SpringApplicationBuilder构建应用程序上下文,则Bootstrap上下文将作为父上下文添加到该上下文。Spring的一个特性是,子上下文从它们的父上下文继承属性源和配置文件,因此,因此,与不使用Spring Cloud配置构建相同的上下文相比,“main”应用程序上下文包含额外的属性源。额外的参数配置来源是:

  • “bootstrap”:如果再bootstrap上下文中找到任何PropertySourceLocators 属性,并且其不为空,则一个可选的CompositePropertySource将以高优先级出现。一个例子是来自Spring Cloud配置服务器的属性。查看“自定义引导程序属性源”了解如何自定义此属性源的内容。
  • “applicationConfig: [classpath:bootstrap.yml]”(以及相关启用的配置文件):如果你有一个bootstrap.yml(或properties),则使用这些属性来配置Bootstrap上下文,然后当子context设置了此父context的时候就会将这些属性添加到子上下文中。这些父context中的属性的优先级低于application.yml(或properties)和任何其他作为创建Spring Boot应用程序过程的正常部分添加到子 context的属性源。请参阅自定义引导程序属性源 的说明,了解如何自定义这些属性来源的内容。
    由于properties sourcer的排序规则,“bootstrap”entries 优先,但请注意,这些条目不包含bootstrap.yml中的任何数据,它们的优先级非常低,但可用于设置默认值。
    你可以通过设置你创建的任何ApplicationContext的父上下文来扩展上下文层次结构——例如,通过使用它自己的接口或使用SpringApplicationBuilder便利方法(parent()、child()和sibling())。引导上下文是你自己创建的最高级祖先的父类。层次结构中的每个上下文都有自己的“引导”(可能是空的)属性源,以避免无意中将值从父级提升到其后代级。如果有一个配置服务器,那么层次结构中的每个上下文(原则上)也可以有一个不同的spring.application.name,从而有一个不同的远程属性源。常规的Spring应用程序上下文行为规则应用于属性解析:来自子上下文的属性通过名称和属性源名称覆盖父上下文中的属性。(如果子元素具有与父元素同名的属性源,则子元素中不包含父元素的值)。
    注意,SpringApplicationBuilder允许您在整个层次结构中共享一个环境,但这不是默认情况。因此,兄弟上下文(特别是)不需要具有相同的配置文件或属性源,即使它们可能与父上下文共享相同的值。

3.1.3. Changing the Location of Bootstrap Properties

bootstrap.yml的位置可以通过设置spring.cloud.bootstrap.name(默认是:bootstrap),spring.cloud.bootstrap.location(默认是:空)或者spring.cloud.bootstrap.additional-location(默认是:空)来指定–例如在系统参数中。
这些属性的行为与具有相同名称的spring.config.*变体相同,实际上它们通过在bootstrap ApplicationContext 的Environment中设置这些属性来设置bootstrap ApplicationContext。如果存在active profile(来自spring.profiles.active或通过您正在构建的context中的Environment API配置),那么该配置文件中的属性也将被加载,就像在常规的Spring Boot应用程序中一样,例如。“development” profile的bootstrap-development.properties。

3.1.4. Overriding the Values of Remote Properties

通过引导上下文添加到应用程序中的属性源通常是“Remote ”,(例如来自Spring Cloud Config 服务).默认情况下,不能在本地覆盖它们。如果您想让您的应用程序使用它们自己的系统属性或配置文件来覆盖远程属性,远程属性源必须通过设置spring.cloud.config.allowOverride=true来进行授权(本地设置无效)。一旦设置了该标志,两个更细粒度的设置将控制远程属性相对于系统属性和应用程序的本地配置的位置:

  • spring.cloud.config.overrideNone=true:从任何本地属性源重写。
  • spring.cloud.config.overrideSystemProperties=false: 只有系统属性、命令行参数和环境变量(而不是本地配置文件)应该覆盖远程设置。

3.1.5. Customizing the Bootstrap Configuration

通过向/META-INF/spring.factories中添加以org.springframework.cloud.bootstrap.BootstrapConfiguration 为key的条目可以训练bootstrap context执行任何您想要的操作。这个key对应的值是逗号分隔的@Configuration类列表,这些类用于创建bootstrap context。这个key对应的值是逗号分隔的@Configuration类列表,这些类用于创建bootstrap context。您想要在 “main” application context中可以自动装配的任何bean都可以在此处创建,并且该上下文中还有一个ApplicationContextInitializer类型的@Beans特殊规范。如果要控制启动顺序(默认顺序为“last”),可以使用@Order标记类。
添加自定义BootstrapConfiguration时要小心,您添加的这些类不能错误地@ComponentScanned到您的 “main” application context中,因为 “main” application context中可能不需要它们。对于尚未由@ComponentScan或@SpringBootApplication注释的配置类所包含的boot 配置类,使用单独的package name。

bootstrap process结束于将initializers注入主SpringApplication实例(即普通的Spring Boot启动sequence,无论它是作为独立应用程序运行还是部署在 application server中)。首先,通过spring.factories中的类创建bootstrap context,然后在启动之前,将所有类型为ApplicationContextInitializer的@Beans添加到主SpringApplication中。

3.1.6. Customizing the Bootstrap Property Sources

bootstrap process添加的外部配置的默认属性源是Config Server,但可以通过将类型PropertySourceLocator的Bean添加到bootstrap context(通过spring.factories)来添加其他属性源。例如,您可以使用指定的数据源从不同的server或数据库插入其他属性。

作为例子,请考虑以下简单的 custom locator:

@Configuration
public class CustomPropertySourceLocator implements PropertySourceLocator {

    @Override
    public PropertySource<?> locate(Environment environment) {
        return new MapPropertySource("customProperty",
                Collections.<String, Object>singletonMap("property.from.sample.custom.source", "worked as intended"));
    }

}

传入的Environment是要创建的ApplicationContext的Environment,这个Environment也就是我们为其提供附加属性源的Environment。这个Environment将拥有普通的Spring Boot-provided property sources,因此您可以使用这些property source来定位特定于此Environment的property source(例如,通过在spring.application.name上键入它,如在缺省Config Server property source locator)。

如果你创建了一个jar包含这个类,然后添加一个META-INF / spring.factories包含如下内容:

org.springframework.cloud.bootstrap.BootstrapConfiguration=sample.custom.CustomPropertySourceLocator
那么任何包含该jar的application中,“customProperty” PropertySource都可用。

3.1.7. Logging Configuration

:如果您使用Spring Boot来配置日志设置,则应该将此配置放在bootstrap.[yml | properties]如果你希望它适用于所有事件。

3.1.8. Environment Changes

应用程序将监听EnvironmentChangeEvent并以一些标准方式对更改做出反应(额外的ApplicationListener可以通过正常方式添加为@Beans)。当观察到EnvironmentChangeEvent时,这个event将有一个已更改的key-value列表,并且应用程序将使用这些key-value来:

  • 在上下问中重新绑定任何的@ConfigurationProperties实体
  • 为logger .level.*中的任何属性设置logger级别

请注意,Config Client不会默认轮询 Environment中的更改,通常我们不会建议用于检测更改的方法(尽管您可以使用@Scheduled注释进行设置)。如果您有多个客户端应用程序,则最好将EnvironmentChangeEvent广播到所有实例,而不是让他们轮询更改(例如,使用Spring Cloud Bus)。
EnvironmentChangeEvent涵盖了一大类刷新使用场景,只要您可以对Environment进行实际更改并发布该事件(这些API是公开的并且是Spring核心的一部分)。您可以通过访问/ configprops端点(普通的Spring Boot Actuator功能)来验证更改是否绑定到@ConfigurationProperties bean。例如,DataSource可以在运行时更改其maxPoolSize(由Spring Boot创建的默认DataSource是一个@ConfigurationProperties bean)并动态增加容量。重新绑定@ConfigurationProperties不包含另一大类场景,这些场景中需要您需要更多地控制刷新,并且这里需要对整个ApplicationContext进行原子级更改。为了解决这些问题,我们使用了@RefreshScope。

3.1.9. Refresh Scope

标记为@RefreshScope的Spring @Bean将在配置更改时得到特殊处理。这解决了有状态bean被初始化时仅注入它们自己的配置的问题。例如,如果通过Environment更改数据库URL时,如果DataSource已打开了连接,我们可能希望这些连接的持有者能够完成他们正在执行的操作。然后当有人从连接池借用一个连接时,他会得到一个新的URL。
有时候,在一些只能初始化一次的bean上应用@RefreshScope注释可能是强制性的。如果一个bean是“不可变的”,那么您必须使用@RefreshScope来注释这个bean,或者在属性键下指定classname: spring.cloud.refresh.extra-refreshable。

Refresh scope beans是在它们被使用时(即,当调用方法时)进行初始化的惰性代理,并且scop充当初始化值的缓存。要强制一个bean在下一次方法调用时重新初始化,只需要使其缓存项无效。

RefreshScope是上下文中的一个bean,它有一个公共refreshAll()方法,通过清除目标缓存来刷新范围内的所有bean。刷新端点公开此功能(通过HTTP或JMX)。要按名称刷新单个bean,还有一个refresh(String)方法。
要公开/refresh端点,您需要向您的应用程序添加以下配置:

management:
  endpoints:
    web:
      exposure:
        include: refresh

@RefreshScope在技术上适用于@Configuration类,但它可能会导致令人惊讶的行为:例如这并不意味着该类中定义的所有@Beans本身都是@RefreshScope。具体来说,anything依赖这些RefreshScope beans不能相信这些RefreshScope beans会在refresh初始化的时候更新,除非它本身也位于@RefreshScope中(上面所说的anything将在刷新时重建并重新注入它的依赖项,这些依赖项会从刷新的@Configuration重新初始化)

3.1.10. Encryption and Decryption

Spring Cloud有一个Environment pre-processor用于本地解密属性值。它遵循与配置服务器相同的规则,并且使用encrypt.* 作为key。因此,您可以使用{cipher}*格式的加密值,只要有一个有效的密钥,那么它们将在主应用程序上下文获取Environment之前被解密。要在应用程序中使用加密功能,您需要在您的类路径中包含Spring Security RSA(Maven协调“org.springframework.security:spring-security-rsa”),并且您还需要JVM中的全功能JCE扩展。

如果由于“Illegal key size”而导致异常,并且您正在使用Sun的JDK,则需要安装Java加密扩展(JCE)
文件。详情请参阅以下连结:

3.1.11. Endpoints

对于Spring boot Actuator 应用程序,可以使用一些附加的管理端点。您可以使用:

  • POST to /actuator/env to update the Environment and rebind @ConfigurationProperties and log levels.
  • /actuator/refresh to re-load the boot strap context and refresh the @RefreshScope beans.
  • /actuator/restart to close the ApplicationContext and restart it (disabled by default).
  • /actuator/pause and /actuator/resume for calling the Lifecycle methods (stop() and start() on the ApplicationContext).

3.2. Spring Cloud Commons: Common Abstractions

服务发现、负载平衡和断路器等模式提供了一个公共抽象层,所有Spring cloud客户端都可以使用这个抽象层,与实现无关(例如,使用Eureka或领事进行发现)。

3.2.1. The @EnableDiscoveryClient Annotation

Spring Cloud Commons 提供了 @EnableDiscoveryClient注解,这通过META-INF/spring.factories查找DiscoveryClient接口的实现。Discovery Client的实现类将在spring.factories中添加一个配置类,这个配置类的key是org.springframework.cloud.client.discovery.EnableDiscoveryClient。DiscoveryClient 实现的例子有Spring Cloud Netflix Eureka, Spring Cloud Consul Discovery, 和Spring Cloud Zookeeper Discovery.
默认情况下,DiscoveryClient的实现将自动注册本地Spring Boot服务器为remote discovery server。这可以通过在@EnableDiscoveryClient中设置autoRegister = false来禁用。

不再需要使用@EnableDiscoveryClient。只需在类路径上有一个DiscoveryClient实现就足以让Spring Boot应用程序注册service discovery server。

Health Indicator

DiscoveryClient实现可以通过实现DiscoveryHealthIndicator接口加入Commons创建的Spring Boot HealthIndicator。要禁用composite HealthIndicator,请设置spring.cloud.discovery.client.composite-indicator.enabled = false。一个基于DiscoveryClient的通用HealthIndicator是自动配置的(DiscoveryClientHealthIndicator)。要禁用它,请设置`spring.cloud.discovery.client.health-indicator.enabled = false。要禁用DiscoveryClientHealthIndicator的描述字段,请设置spring.cloud.discovery.client.health-indicator.include-description = false,otherwise it can bubble up as the description of the rolled up HealthIndicator.

哎呀,先稳稳,存个档
断点传送门

发布了41 篇原创文章 · 获赞 22 · 访问量 5万+

猜你喜欢

转载自blog.csdn.net/qq1049545450/article/details/104837625
今日推荐