记录一次RPC服务有损上线的分析过程

京东云开发者
• 阅读 239

作者:京东零售 郭宏宇

1. 问题背景

某应用在启动完提供JSF服务后,短时间内出现了大量的空指针异常。

分析日志,发现是服务依赖的藏经阁配置数据未加载完成导致。即所谓的有损上线或者是直接发布当****应用启动时,service还没加载完,就开始对外提供服务,导致失败调用

关键代码如下

数据的初始化加载是通过实现CommandLineRunner接口完成的

@Component
public class LoadSystemArgsListener implements CommandLineRunner {

    @Resource
    private CacheLoader cjgConfigCacheLoader;

    @Override
    public void run(String... args) {
        // 加载藏经阁配置
        cjgConfigCacheLoader.refresh();

    }
}

cjgConfigCacheLoader.refresh()方法内部会将数据加载到内存中

/** 藏经阁配置数据 key:租户 value:配置数据 */
public static Map<String, CjgRuleConfig> cjgRuleConfigMap = new HashMap<>();

如果此时还未加载完数据,调用cjgRuleConfigMap.get("301").getXX(),则会报空指针异常

总结根因:JSF Provider发布早于服务依赖的初始化数据加载,导致失败调用



2. 问题解决

在解决此问题前,我们需要先回忆并熟悉下Spring Boot的启动过程、JSF服务的发布过程

1)Spring Boot的启动过程(版本2.0.7.RELEASE)

run方法,主要关注refreshContext(context)刷新上下文

public ConfigurableApplicationContext run(String... args) {
    // 创建 StopWatch 实例:用于计算启动时间
    StopWatch stopWatch = new StopWatch();
    stopWatch.start();
    ConfigurableApplicationContext context = null;
    Collection<SpringBootExceptionReporter> exceptionReporters = new ArrayList<>();
    configureHeadlessProperty();

    // 获取SpringApplicationRunListeners:这些监听器会在启动过程的各个阶段发送对应的事件
    SpringApplicationRunListeners listeners = getRunListeners(args);
    listeners.starting();
    try {
        ApplicationArguments applicationArguments = new DefaultApplicationArguments(
                args);

        // 创建并配置Environment:包括准备好对应的`Environment`,以及将`application.properties`或`application.yml`中的配置项加载到`Environment`中
        ConfigurableEnvironment environment = prepareEnvironment(listeners,
                applicationArguments);
        configureIgnoreBeanInfo(environment);

        // 打印Banner:如果 spring.main.banner-mode 不为 off,则打印 banner
        Banner printedBanner = printBanner(environment);

        // 创建应用上下文:根据用户的配置和classpath下的配置,创建合适的`ApplicationContext`
        context = createApplicationContext();
        exceptionReporters = getSpringFactoriesInstances(
                SpringBootExceptionReporter.class,
                new Class[] { ConfigurableApplicationContext.class }, context);

        // 准备上下文:主要是将`Environment`、`ApplicationArguments`等关键属性设置到`ApplicationContext`中,以及加载`ApplicationListener`、`ApplicationRunner`、`CommandLineRunner`等。
        prepareContext(context, environment, listeners, applicationArguments,
                printedBanner);

        // 刷新上下文:这是Spring IoC容器启动的关键,包括Bean的创建、依赖注入、初始化,发布事件等
        refreshContext(context);
        afterRefresh(context, applicationArguments);
        stopWatch.stop();
        // 打印启动信息:如果 spring.main.log-startup-info 为 true,则打印启动信息
        if (this.logStartupInfo) {
            new StartupInfoLogger(this.mainApplicationClass)
                    .logStarted(getApplicationLog(), stopWatch);
        }
        // 发布 ApplicationStartedEvent:通知所有的 SpringApplicationRunListeners 应用已经启动
        listeners.started(context);

        // 调用 Runner:调用所有的ApplicationRunner和CommandLineRunner
        callRunners(context, applicationArguments);
    }
    catch (Throwable ex) {
        handleRunFailure(context, ex, exceptionReporters, listeners);
        throw new IllegalStateException(ex);
    }

    try {
        // 运行中:通知所有的 SpringApplicationRunListeners 应用正在运行
        listeners.running(context);
    }
    catch (Throwable ex) {
        handleRunFailure(context, ex, exceptionReporters, null);
        throw new IllegalStateException(ex);
    }
    return context;
}

refreshContext(context)内部调用refresh()方法,此方法主要关注finishBeanFactoryInitialization(beanFactory) 实例化Bean 早于 finishRefresh() 发生

public void refresh() throws BeansException, IllegalStateException {
    synchronized (this.startupShutdownMonitor) {
        // 准备刷新的上下文环境:设置启动日期,激活上下文,清除原有的属性源
        prepareRefresh();

        // 告诉子类启动 'refreshBeanFactory()' 方法,创建一个新的bean工厂。
        ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();

        // 为 BeanFactory 设置上下文特定的后处理器:主要用于支持@Autowired和@Value注解
        prepareBeanFactory(beanFactory);

        try {
            // 为 BeanFactory 的处理提供在子类中的后处理器。
            postProcessBeanFactory(beanFactory);

            // 调用所有注册的 BeanFactoryPostProcessor Bean 的处理方法。
            invokeBeanFactoryPostProcessors(beanFactory);

            // 注册 BeanPostProcessor 的处理器,拦截 Bean 创建。
            registerBeanPostProcessors(beanFactory);

            // 为此上下文初始化消息源。
            initMessageSource();

            // 为此上下文初始化事件多播器。
            initApplicationEventMulticaster();

            // 在特定的上下文子类中刷新之前的进一步初始化。
            onRefresh();

            // 检查监听器 Bean 并注册它们:注册所有的ApplicationListenerbeans
            registerListeners();

            // 实例化所有剩余的(非延迟初始化)单例。
            finishBeanFactoryInitialization(beanFactory);

            // 完成刷新:发布ContextRefreshedEvent,启动所有Lifecyclebeans,初始化所有剩余的单例(lazy-init 单例和非延迟初始化的工厂 beans)。
            finishRefresh();
        }
        ...
    }

****实例化Bean中,需熟悉Bean的生命周期(重要)

记录一次RPC服务有损上线的分析过程



2)JSF Provider的发布过程(版本1.7.5-HOTFIX-T6)

类com.jd.jsf.gd.config.spring.ProviderBean调用方法com.jd.jsf.gd.config.ProviderConfig#export进行发布

JSF源码地址:http://xingyun.jd.com/codingRoot/jsf/jsf-sdk

public class ProviderBean<T> extends ProviderConfig<T> implements InitializingBean, DisposableBean, ApplicationContextAware, ApplicationListener, BeanNameAware {

    // 此处代码省略...

    public void onApplicationEvent(ApplicationEvent event) {
        if (event instanceof ContextRefreshedEvent && this.isDelay() && !this.exported && !CommonUtils.isUnitTestMode()) {
            LOGGER.info("JSF export provider with beanName {} after spring context refreshed.", this.beanName);
            if (this.delay < -1) {
                Thread thread = new Thread(new Runnable() {
                    public void run() {
                        try {
                            Thread.sleep((long)(-ProviderBean.this.delay));
                        } catch (Throwable var2) {
                        }

                        ProviderBean.this.export();
                    }
                });
                thread.setDaemon(true);
                thread.setName("DelayExportThread");
                thread.start();
            } else {
                this.export();
            }
        }

    }

    private boolean isDelay() {
        return this.supportedApplicationListener && this.delay < 0;
    }

    public void afterPropertiesSet() throws Exception {
        // 此处代码省略...

        if (!this.isDelay() && !CommonUtils.isUnitTestMode()) {
            LOGGER.info("JSF export provider with beanName {} after properties set.", this.beanName);
            this.export();
        }

    }
}
public synchronized void export() throws InitErrorException {
    if (this.delay > 0) {
        Thread thread = new Thread(new Runnable() {
            public void run() {
                try {
                    Thread.sleep((long)ProviderConfig.this.delay);
                } catch (Throwable var2) {
                }

                ProviderConfig.this.doExport();
            }
        });
        thread.setDaemon(true);
        thread.setName("DelayExportThread");
        thread.start();
    } else {
        this.doExport();
    }

}



可以看出Provider发布有两个地方

Ⅰ、Bean的初始化过程(delay>=0)

实现InitializingBean接口,重写afterPropertiesSet方法。这里会判断是否延迟发布,如果大于等于0,则会此处进行发布。具体在export方法中,当delay>0,则会延迟发布,如配置5000,表示延迟5秒发布;当delay=0,则立即发布。



Ⅱ、监听ContextRefreshedEvent事件触发(delay<0)

实现ApplicationListener接口,重写onApplicationEvent方法。属于事件ContextRefreshedEvent,当delay<-1,则会延迟发布,如配置-5000,表示延迟5秒发布;反之,则立即发布。



3)解决方案



场景1:XML方式自动发布Provider(常用)

由上面的介绍,了解到执行顺序1.Bean初始化 > 2.ContextRefreshedEvent事件触发 > 3.调用ApplicationRunner或CommandLineRunner;

上面已经知道Provider发布处于1、2过程,需避免使用方式3进行数据的初始化。

前提建议:delay默认配置为-1,可以不配置,或者配置负数。则JSF Provider发布则处于过程2,即监听ContextRefreshedEvent事件触发



方式1:Bean的初始化过程中

解决方法:使用 @PostConstruct注解、实现InitializingBean接口、配置init-method方法均可
@Component
public class DataLoader {

    @PostConstruct
    @Scheduled(cron = "${cron.config}")
    public void loadData() {
        // 数据加载
        System.out.println("数据加载工作");
    }

}

注意:该Bean如果依赖了其他Bean,需确保依赖Bean已实例化,否则会报空指针异常。



方式2:ContextRefreshedEvent事件触发

ContextRefreshedEvent事件是如何发布的

调用过程 AbstractApplicationContext#finishRefresh -> AbstractApplicationContext#publishEvent-> SimpleApplicationEventMulticaster#multicastEvent

public void multicastEvent(final ApplicationEvent event, @Nullable ResolvableType eventType) {
   ResolvableType type = (eventType != null ? eventType : resolveDefaultEventType(event));
   for (final ApplicationListener<?> listener : getApplicationListeners(event, type)) {
      Executor executor = getTaskExecutor();
      if (executor != null) {
         executor.execute(() -> invokeListener(listener, event));
      }
      else {
         invokeListener(listener, event);
      }
   }
}

SimpleApplicationEventMulticaster的multicastEvent方法中调用invokeListener()进行事件发布,getTaskExecutor()默认值是null(除自定义设置Executor对象),所有ApplicationListener实现类串行执行onApplicationEvent方法。

getApplicationListeners(event, type)获取所有的实现类,继续向下看内部会调用AnnotationAwareOrderComparator.sort(allListeners)对所有ApplicationListener进行排序,allListeners 是待排序的对象列表。该方法将根据对象上的排序注解或接口来确定排序顺序,并返回一个按照指定顺序排序的对象列表。具体来说,排序的规则如下:

1.首先,根据对象上的 @Order 注解的值进行排序。 @Order 注解的值越小,排序优先级越高

2.如果对象上没有 @Order 注解,或者多个对象的 @Order 注解值相同,则根据对象是否实现了 Ordered 接口进行排序。实现了 Ordered 接口的对象,可以通过 getOrder() 方法返回一个排序值。

3.如果对象既没有 @Order 注解,也没有实现 Ordered 接口,则使用默认的排序值 LOWEST_PRECEDENCE(Integer.MAX_VALUE)。特别的:如果BeanA和BeanB排序值都是默认值,则保持原顺序,即Bean的加载顺序



总结:默认情况所有ApplicationListener实现类串行执行onApplicationEvent方法,而顺序取决于AnnotationAwareOrderComparator.sort(allListeners),@Order 注解的值越小,排序优先级越高

解决方法:使用@Order注解保证执行顺序早于ProviderBean
@Component
@Order(1)
public class DataLoader implements ApplicationListener<ContextRefreshedEvent> {
    @Override
    public void onApplicationEvent(ContextRefreshedEvent event) {
        // 数据准备
        System.out.println("初始化工作");

    }
}

此外带有@SpringBootApplication的启动类中实现也是可以的(在Spring Boot中默认使用基于注解的方式进行配置和管理Bean,所以注解定义的Bean会在XML定义的Bean之前被加载)

@SpringBootApplication
public class DemoApplication implements ApplicationListener<ContextRefreshedEvent> {

    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }

    @Override
    public void onApplicationEvent(ContextRefreshedEvent event) {
        System.out.println("初始化工作");
    }
}

场景2:API方式发布Provider(较少使用)

应用启动完成后,先做初始化动作,完成后再手动发布Provider。这种就可以通过实现接口ApplicationRunner或接口CommandLineRunner去执行初始化。

@Component
public class DataLoader implements ApplicationRunner {

    @Override
    public void run(ApplicationArguments args) throws Exception {
        // 数据准备
        System.out.println("初始化工作");

        // 发布provider
        // 参考:https://cf.jd.com/pages/viewpage.action?pageId=296129902
    }
}

场景3:XML方式手动发布(不常用)

provider的dynamic属性设置为false

标签 属性 类型 是否必填 默认值 描述
provider dynamic boolean true 是否动态注册Provider,默认为true,配置为false代表不主动发布,需要到管理端进行上线操作



3. 总结

RPC服务(如JSF、Dubbo)进行优雅上线,常用的两种方式:1、延迟发布 2、手动发动

如果你的服务需要一些初始化操作后才能对外提供服务,如初始化缓存(不限与藏经阁、ducc、mysql、甚至调用其他jsf服务)、redis连接池等相关资源就位,可以参考本文中介绍的几种方式。

此文是笔者通过读取源码+本地验证得出的结论,如有错误遗漏或者更好的方案还烦请各位指出共同进步!

点赞
收藏
评论区
推荐文章
Wesley13 Wesley13
3年前
SPI应用场景及详解
java中spi(serviceproviderinterface)是jdk内置的一种服务发现机制,可以基于配置,在运行时加载指定服务。java中提供了很多服务提供接口,如jdbc、jndi等。面对分布式的开发,很多系统之间的调用都是使用rpc直接调用,但是有的时候上游的系统需要调用下游系统很多的接口,导致开发工作量很大。因此上游系统使用sp
Stella981 Stella981
3年前
Kerberos无约束委派的攻击和防御
 0x00前言简介当ActiveDirectory首次与Windows2000Server一起发布时,Microsoft就提供了一种简单的机制来支持用户通过Kerberos对Web服务器进行身份验证并需要授权用户更新后端数据库服务器上的记录的方案。这通常被称为Kerberosdoublehopissue(双跃点问题),
Stella981 Stella981
3年前
Kafka 异步消息也会阻塞?记一次 Dubbo 频繁超时排查过程
线上某服务A调用服务B接口完成一次交易,一次晚上的生产变更之后,系统监控发现服务B接口频繁超时,后续甚至返回线程池耗尽错误ThreadpoolisEXHAUSTED。因为服务B依赖外部接口,刚开始误以为外部接口延时导致,所以临时增加服务Bdubbo线程池线程数量。配置变更之后,重启服务,服务恢复正常。一段时间之后,服务B
Stella981 Stella981
3年前
Spring boot 2.3优雅下线,距离生产还有多远?
前言在生产环境中,随着云原生架构的发展,自动的弹性伸缩、滚动升级、分批发布等云原生能力让用户享受到了资源、成本、稳定性的最优解。但是在应用的缩容、发布等过程中,由于实例下线处理得不够优雅,将会导致短暂的服务不可用,短时间内业务监控会出现大量io异常报错;如果业务没做好事务,那么还会引起数据不一致的问题,那么需要紧急手动订正错误数据;甚至每次发布
Stella981 Stella981
3年前
Spring Cloud构建微服务架构
在微服务架构中,我们将系统拆分成了一个个的服务单元,各单元应用间通过服务注册与订阅的方式互相依赖。由于每个单元都在不同的进程中运行,依赖通过远程调用的方式执行,这样就有可能因为网络原因或是依赖服务自身问题出现调用故障或延迟,而这些问题会直接导致调用方的对外服务也出现延迟,若此时调用方的请求不断增加,最后就会出现因等待出现故障的依赖方响应而形成任务积压,线程资
京东云开发者 京东云开发者
3星期前
InheritableThreadLocal从入门到放弃
作者:京东零售田超辉背景:一个上线了很久但是请求量很低(平均每天一两次)的历史功能突然出现空指针报错:我们翻开代码定位到对应的报错代码:结合堆栈和代码可以确定是由于bdIdJobMap的值为null导致往bdIdEmployeeJobMap这个map中pu
消失的死锁:从 JSF 线程池满到 JVM 初始化原理剖析 | 京东云技术团队
在一次上线时,按照正常流程上线后,观察了线上报文、接口可用率十分钟以上,未出现异常情况,结果在上线一小时后突然收到jsf线程池耗尽的报警,并且该应用一共有30台机器,只有一台机器出现该问题,迅速下线该机器的jsf接口,恢复线上。然后开始排查问题。
记录一次RPC服务有损上线的分析过程
1\.问题背景某应用在启动完提供JSF服务后,短时间内出现了大量的空指针异常。分析日志,发现是服务依赖的藏经阁配置数据未加载完成导致。即所谓的有损上线或者是直接发布,当应用启动时,service还没加载完,就开始对外提供服务,导致失败调用。关键代码如下数据
京东云开发者 京东云开发者
9个月前
【京东云新品发布月刊】2024年3月产品动态
1.【言犀模型服务】新品上线言犀模型服务平台致力于为开发者提供AI原生应用开发的全链路服务,内置丰富的应用插件,提供便捷的集成方式,结合企业专属数据和API,助力企业高效完成大模型应用构建。2.【数据库管理服务DMS】新品上线数据库管理服务DMS(Data
京东云开发者 京东云开发者
6个月前
Lombok注解引发的空指针问题分析
一、问题描述在一次上线后,日志中出现空指针的报错,但是报错代码位置以及相应工具类未进行过修改,接下来进一步分析。以下为报错堆栈信息:java.lang.NullPointerException:nullatnet.sf.cglib.core.Reflect