spring boot微服务场景下apollo加载过程解析

目录
  • 集成使用
    • 1、添加gradle依赖
    • 2、配置application.properties
      • 必须配置
      • 可选配置
  • 加载过程解析
  • postProcessEnvironment方法逻辑解析
  • initialize方法逻辑解析
  • 结语

集成使用

1、添加 gradle 依赖

implementation "com.ctrip.framework.apollo:apollo-client:1.6.0"

2、配置 application.properties

apollo 自身的配置共包含 9 项,必要配置只有 3 项,其他的都是可选的配置。apollo 在 spring-boot 环境下的配置命名和 System 参数的命名保持了一直,最终 spring 的配置会注入到 System 中,具体的逻辑下文分析。

必须配置

#应用的ID
app.id = java-project
# apollo 的 config-service 服务发现地址
apollo.meta = http://apollo.meta
# 启用 apollo
apollo.bootstrap.enabled = true

可选配置

# 在日志系统初始化前加载 apollo 配置
apollo.bootstrap.eagerLoad.enabled=true
# 加载的命名空间,默认加载 application ,多个以逗号隔开
apollo.bootstrap.namespaces = application
# apollo 的安全拉取 secret 配置
apollo.accesskey.secret = xx
# 集群配置
apollo.cluster = hk
# 缓存路径
apollo.cacheDir = /opt
# 是否保持和 apollo 配置页面的配置顺序一致
apollo.property.order.enable = true

加载过程解析

public class ApolloApplicationContextInitializer implements ApplicationContextInitializer, EnvironmentPostProcessor, Ordered {
  public static final int DEFAULT_ORDER = 0;
  private static final Logger logger = LoggerFactory.getLogger(ApolloApplicationContextInitializer.class);
  private static final Splitter NAMESPACE_SPLITTER = Splitter.on(",").omitEmptyStrings().trimResults();
  private static final String[] APOLLO_SYSTEM_PROPERTIES = {"app.id", ConfigConsts.APOLLO_CLUSTER_KEY,
      "apollo.cacheDir", "apollo.accesskey.secret", ConfigConsts.APOLLO_META_KEY, PropertiesFactory.APOLLO_PROPERTY_ORDER_ENABLE};
  private final ConfigPropertySourceFactory configPropertySourceFactory = SpringInjector.getInstance(ConfigPropertySourceFactory.class);
  private int order = DEFAULT_ORDER;
  @Override
  public void initialize(ConfigurableApplicationContext context) {
    ConfigurableEnvironment environment = context.getEnvironment();
    if (!environment.getProperty(PropertySourcesConstants.APOLLO_BOOTSTRAP_ENABLED, Boolean.class, false)) {
      logger.debug("Apollo bootstrap config is not enabled for context {}, see property: ${{}}", context, PropertySourcesConstants.APOLLO_BOOTSTRAP_ENABLED);
      return;
    }
    logger.debug("Apollo bootstrap config is enabled for context {}", context);
    initialize(environment);
  }
  /**
   * Initialize Apollo Configurations Just after environment is ready.
   *
   * @param environment
   */
  protected void initialize(ConfigurableEnvironment environment) {
    if (environment.getPropertySources().contains(PropertySourcesConstants.APOLLO_BOOTSTRAP_PROPERTY_SOURCE_NAME)) {
      //already initialized
      return;
    }
    String namespaces = environment.getProperty(PropertySourcesConstants.APOLLO_BOOTSTRAP_NAMESPACES, ConfigConsts.NAMESPACE_APPLICATION);
    logger.debug("Apollo bootstrap namespaces: {}", namespaces);
    ListnamespaceList = NAMESPACE_SPLITTER.splitToList(namespaces);
    CompositePropertySource composite = new CompositePropertySource(PropertySourcesConstants.APOLLO_BOOTSTRAP_PROPERTY_SOURCE_NAME);
    for (String namespace : namespaceList) {
      Config config = ConfigService.getConfig(namespace);
      composite.addPropertySource(configPropertySourceFactory.getConfigPropertySource(namespace, config));
    }
    environment.getPropertySources().addFirst(composite);
  }
  /**
   * To fill system properties from environment config
   */
  void initializeSystemProperty(ConfigurableEnvironment environment) {
    for (String propertyName : APOLLO_SYSTEM_PROPERTIES) {
      fillSystemPropertyFromEnvironment(environment, propertyName);
    }
  }
  private void fillSystemPropertyFromEnvironment(ConfigurableEnvironment environment, String propertyName) {
    if (System.getProperty(propertyName) != null) {
      return;
    }
    String propertyValue = environment.getProperty(propertyName);
    if (Strings.isNullOrEmpty(propertyValue)) {
      return;
    }
    System.setProperty(propertyName, propertyValue);
  }
  /**
   *
   * In order to load Apollo configurations as early as even before Spring loading logging system phase,
   * this EnvironmentPostProcessor can be called Just After ConfigFileApplicationListener has succeeded.
   *
   *
   * The processing sequence would be like this:
   * Load Bootstrap properties and application properties -----> load Apollo configuration properties ----> Initialize Logging systems
   *
   * @param configurableEnvironment
   * @param springApplication
   */
  @Override
  public void postProcessEnvironment(ConfigurableEnvironment configurableEnvironment, SpringApplication springApplication) {
    // should always initialize system properties like app.id in the first place
    initializeSystemProperty(configurableEnvironment);
    Boolean eagerLoadEnabled = configurableEnvironment.getProperty(PropertySourcesConstants.APOLLO_BOOTSTRAP_EAGER_LOAD_ENABLED, Boolean.class, false);
    //EnvironmentPostProcessor should not be triggered if you don't want Apollo Loading before Logging System Initialization
    if (!eagerLoadEnabled) {
      return;
    }
    Boolean bootstrapEnabled = configurableEnvironment.getProperty(PropertySourcesConstants.APOLLO_BOOTSTRAP_ENABLED, Boolean.class, false);
    if (bootstrapEnabled) {
      initialize(configurableEnvironment);
    }
  }
  /**
   * @since 1.3.0
   */
  @Override
  public int getOrder() {
    return order;
  }
  /**
   * @since 1.3.0
   */
  public void setOrder(int order) {
    this.order = order;
  }
}

apollo 在 spring-boot 中的加载逻辑都在如上的代码中了,代码的关键是实现了两个 spring 生命周期的接口,

  • ApplicationContextInitializer

在被 ConfigurableApplicationContext.refresh()刷新之前初始化 ConfigurableApplicationContext 的回调接口。

  • EnvironmentPostProcessor

比 ApplicationContextInitializer 的加载时机还要提前,此时 spring-boot 的日志系统还未初始化,

postProcessEnvironment 方法逻辑解析

1、初始化 System 的配置,将 spring 上下文中的配置(环境变量、System 参数、application.properties) 拷贝到 System 配置中, 如果 System 已经存在同名的配置则跳过,保证了 -D 设置的 System 参数的最高优先级。但是也带来了一个隐含的问题,默认,apollo 的配置设计支持从环境变量中取值,也遵循了环境变量大写的规范,将 System 参数的 "." 换成 "_" 拼接,然后变成大写。 比如 apollo.meta 对应环境变量的 APOLLO_META。但是在 spring-boot 的环境下,因为 spring 的配置系统默认也会加载环境变量的配置,最终在环境变量里配置 apollo.meta 也会生效。甚至比正确配置的 APOLLO_META 环境变量值的优先级还高。

2、根据 apollo.bootstrap.eagerLoad.enabled 和 apollo.bootstrap.enabled 的配置来判断是否在这个阶段初始化 apollo。 postProcessEnvironment() 执行的时候, 此时日志系统并未初始化,在这个阶段加载 apollo,可以解决将日志配置托管到 apollo 里直接生效的问题。 带来的问题是, 假如在这个阶段的 apollo 加载出现问题,由于日志系统未初始化,看不到 apollo 的加载日志,不方便定位 apollo 的加载问题。 所以博主建议,如果有托管日志配置的场景,可以先不启用 apollo.bootstrap.eagerLoad.enabled 的配置,等 apollo 集成完成后在启用。

initialize 方法逻辑解析

1、根据 apollo.bootstrap.enabled 的配置来判断,是否在这个阶段初始化 apollo ,如果此时 spring 上下文中已经包含了 apollo 的 PropertySources,代表 apollo 已经 初始化过,则直接 return 掉

2、根据 apollo.bootstrap.namespaces 的配置,默认不配置为 "application" ,依次获取对应的 namespace 的配置, 并将配置使用 addFirst() 具有最高优先级属性源的设置方法, 添加到了 spring 的配置上下文中。这里解释了为什么 apollo 的配置的优先级最高,比 application.properties 中直接配置都要高, 这个优先级的问题会经常闹乌龙,在本地开发调试阶段,会直接在 application.properties 里调试配置,然后怎么改都不生效,因为 apollo 里 存在了同名的配置,启动的时候直接覆盖了本地的配置。博主也犯过几次这个错误

结语

上面列出的 9 项 apollo 配置,只有三项配置(apollo.bootstrap.enabled、apollo.bootstrap.eagerLoad.enabled、apollo.bootstrap.namespaces)是在 spring-boot 启动过程中用到的,其他的配置都被透传到 System ,供 apollo 底层 sdk 使用。 基于此而发现了一个 apollo 初始化配置时的小彩蛋,在 spring-boot 应用里,如果使用环境变量来驱动 apollo 的配置项,则带 "." 风格的配置(apollo.meta)和 "_" 风格的大写配置(APOLLO_META)的效果是等价的,并且如果两个配置同时存在环境变量中,前者的优先级要高于后者

以上就是spring boot微服务场景下apollo加载过程解析的详细内容,更多关于spring-boot下apollo加载过程的资料请关注我们其它相关文章!

(0)

相关推荐

  • SpringBoot整合Apollo配置中心快速使用详解

    目录 一.简介 二.使用 1. 测试项目搭建 2. Apollo配置中心的配置 3. 项目启动与测试 4.常见整合问题 附录 一.简介 1.Apollo 是什么?Apollo(阿波罗)是携程框架部门研发的分布式配置中心.服务端基于Spring Boot和Spring Cloud开发. 2.为什么要使用Apollo? 安全性:配置跟随源代码保存在代码库中,容易造成配置泄漏 时效性:普通方式配置,修改配置,需要重启服务才能生效 局限性:无法支持动态调整:例如日志开关.功能开关 二.使用 1. 测试项

  • Springboot apollo原理及使用方法详解

    文章背景 如果在spring boot中接入apollo官方文档:https://github.com/ctripcorp/apollo/wiki使用官方的apollo 演示环境(Demo): 106.54.227.205账号/密码:apollo/admin 添加配置 spring-boot中如何使用 pom.xml中添加配置 <dependency> <groupId>com.ctrip.framework.apollo</groupId> <artifactI

  • SpringFramework应用接入Apollo配置中心过程解析

    环境: SpringFramework:4.3.5.RELEASE apollo-client:1.5.1 1.在项目的 resources/META-INF/ 目录下添加 app.properties 文件: #Apollo配置id app.id = phpdragon-demo apollo.bootstrap.enabled = true apollo.eagerLoad.enabled = true apollo.cacheDir = /data/app_data/apollo_cach

  • apollo与springboot集成实现动态刷新配置的教程详解

    分布式apollo简介 Apollo(阿波罗)是携程框架部门研发的开源配置管理中心,能够集中化管理应用不同环境.不同集群的配置,配置修改后能够实时推送到应用端,并且具备规范的权限.流程治理等特性. 本文主要介绍如何使用apollo与springboot实现动态刷新配置,如果之前不了解apollo可以查看如下文档 https://github.com/ctripcorp/apollo 学习了解一下apollo,再来查看本文 正文 apollo与spring实现动态刷新配置本文主要演示2种刷新,一种

  • spring boot微服务场景下apollo加载过程解析

    目录 集成使用 1.添加gradle依赖 2.配置application.properties 必须配置 可选配置 加载过程解析 postProcessEnvironment方法逻辑解析 initialize方法逻辑解析 结语 集成使用 1.添加 gradle 依赖 implementation "com.ctrip.framework.apollo:apollo-client:1.6.0" 2.配置 application.properties apollo 自身的配置共包含 9 项

  • 浅谈Spring Boot 微服务项目的推荐部署方式

    如果开发过spring boot的程序,应该都知道,使用spring boot官方的maven打包插件(spring-boot-maven-plugin) 来打包,打出来的jar包一般有40M以上. 如果公司的服务器上传带宽不高,那么手动上传一个jar或者jenkins部署一次jar,都是非常痛苦的........ 但是,如果打包的时候不引入lib,那么打出来的jar包一般只有几十k而已,非常小,想怎么传就怎么传......... 本文会提供一个bash启动脚本,只需要稍做更改,即可适应你的程序

  • spring boot微服务自定义starter原理详解

    这篇文章主要介绍了spring boot微服务自定义starter原理详解,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下 使用spring boot开发微服务后,工程的数量大大增加(一定要按照领域来切,不要一个中间件客户端包一个),让各个jar从开发和运行时自包含成了一个重要的内容之一.spring boot starter就可以用来解决该问题(没事启动时别依赖于applicationContext.getBean获取bean进行处理,依赖关系

  • 教你在Spring Boot微服务中集成gRPC通讯的方法

    一.首先声明gRPC接口 这里引入的是最新的gRpc-core 1.37版本, 采用的grcp-spring-boot-starter封装的版本进行实现,github地址: https://github.com/yidongnan/grpc-spring-boot-starter 要实现gRpc通讯, 先定义接口以及入参出参信息 syntax = "proto3"; option java_multiple_files = true; option java_package = &qu

  • Vue+webpack实现懒加载过程解析

    这篇文章主要介绍了Vue+webpack实现懒加载过程解析,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下 实现方式: 1.webpack method require.ensure([''], callback, chunkName) ; 2.es6 motehod import() import().then() import(/* webpackChunkName: async-chunk-name */ /* webpackMode: l

  • 详解Spring Cloud微服务架构下的WebSocket解决方案

    WebSocket在现代浏览器中的应用已经算是比较普遍了,在某些业务场景下,要求必须能够在服务器端推送消息至客户端.在没有WebSocket的年代,我们使用过dwr,在那个时候dwr真实一个非常棒的方案.但是在WebSocket兴起之后,我们更愿意使用标准实现来解决问题. 首先交代一下,本篇文章不讲解WebSocket的配置,主要讲的是针对在微服务架构集群模式下解决方案的选择. 微服务架构大家应该都不陌生了,在微服务架构下,服务是分布式的,而且为了保证业务的可用性,每个服务都是以集群的形式存在.

  • 详解Spring简单容器中的Bean基本加载过程

    本篇将对定义在 XMl 文件中的 bean,从静态的的定义到变成可以使用的对象的过程,即 bean 的加载和获取的过程进行一个整体的了解,不去深究,点到为止,只求对 Spring IOC 的实现过程有一个整体的感知,具体实现细节留到后面用针对性的篇章进行讲解. 首先我们来引入一个 Spring 入门使用示例,假设我们现在定义了一个类 org.zhenchao.framework.MyBean ,我们希望利用 Spring 来管理类对象,这里我们利用 Spring 经典的 XMl 配置文件形式进行

  • 详解Spring Boot微服务如何集成fescar解决分布式事务问题

    什么是fescar? 关于fescar的详细介绍,请参阅fescar wiki. 传统的2PC提交协议,会持有一个全局性的锁,所有局部事务预提交成功后一起提交,或有一个局部事务预提交失败后一起回滚,最后释放全局锁.锁持有的时间较长,会对并发造成较大的影响,死锁的风险也较高. fescar的创新之处在于,每个局部事务执行完立即提交,释放本地锁:它会去解析你代码中的sql,从数据库中获得事务提交前的事务资源即数据,存放到undo_log中,全局事务协调器在回滚的时候直接使用undo_log中的数据覆

  • Spring实现上拉刷新和下拉加载效果

    本文实例为大家分享了Spring实现上拉刷新和下拉加载效果,供大家参考,具体内容如下 导依赖: compile 'com.android.support:recyclerview-v7:25.3.1' compile 'com.liaoinstan.springview:library:1.3.0' compile files('libs/glide-3.7.0.jar') activity_main布局 <?xml version="1.0" encoding="ut

  • Node.js+ES6+dropload.js实现移动端下拉加载实例

    最近要涉及微信移动端项目,所以尝试学习一些移动端的实用技能,这个demo服务由Node搭建服务.下拉加载使用插件dropload,数据渲染应用了ES6中的模板字符串.有兴趣的小伙伴可以自己尝试下. 1.Node+express -- 服务搭建 由于该demo是在服务器端实现,所以需要通过npm包引入express模块,用来搭建简易服务. 1.官网下载node,npm包管理工具会同时自动下载. 2.命令行输入:npm install express -g //安装express模块 3.在项目中新

随机推荐