Spring 启动慢？提速利器 SpringFu 来了

函数是应用在Serverless世界里的一种极轻量形态，每个函数通常专注提供单一功能的服务。它们相互串联，井然有序，时而成群结队的出现，在完成既定任务后又很快的消失，此起彼伏，辉映成趣，将云的灵巧与飘逸发挥得淋漓尽致。

与此同时，扎根在中后台辛勤耕耘了十多年的Spring，早已是一位心宽体阔、中年发福了的明星大叔。倘若将他邀请到函数的舞台上，那就成了绝佳的娱乐新闻题材。其实Spring本尊也确曾出演过一部收视率不太高的“古装情景喜剧”《Spring Cloud Function 1.0》，尽管使出了反应式（Reactive）架构、云平台集成等等经典绝技，无奈臃肿的身材难以跟上轻快的舞步，被Nodejs和Python等晚辈小生调戏得窘态频现。于是，Spring立下宏志，即刻减肥，不瘦30斤，不回江湖。如今，Spring终于功成归来，不仅习得新技能Functional Bean，还为社区带来了两位新伙伴：SpringInit和SpringFu。

根据非官方实验数据，将SpringMVC应用改造为SpringFu结构，启动时间大约能缩短50%。这点提速当然不算瞩目，然而SpringFu的关键价值在于，它使Spring框架能够摆脱JVM动态特性束缚，从而适配AOT编译模式。倘若搭配上GraalVM编译器，应用启动速度就能直线下降到原先的大约1%，彻底甩掉“起跑永远慢半拍”的帽子。

一 Spring 5.0的创新

关于SpringFu的故事，还得从Spring 5.0版本说起。

纵观Spring的演化过程，Bean对象的定义方式是一条脉络清晰的主线。早期“SSH时代”的Spring框架只能使用xml文件定义Bean，写一个Java项目，一半是xml文件。即便如此，Spring 1.0依然带领着这支“尖括号加代码”大军击溃了更加笨拙繁琐的EJB框架。平定天下以后，Spring内部开始了自我进化，Spring 2.0推出了基于注解的Bean定义机制，逐步替换过去的xml文件。最终在SpringBoot项目的强力助攻下，注解全面取代xml，完成大国一统。眼看太平盛世刚刚到来，可就在最近几年里，Spring社区又刮起了一股更年轻的“去注解”风潮。

这股风潮的兴起与云原生以及GraalVM项目蓬勃发展有着不可忽视的联系。了解过AOT编译的读者应该知道，反射、动态代理等运行时特性都是妨碍Java代码进行AOT编译的首要因素，然而基于注解的Bean扫描过程恰恰大量依赖了这些Java动态特性。这就相当于说，曾经代表着先进生产力的Spring注解，现在正在成为制约Spring继续演进的束脚石。

事已至此，Spring自个也不含糊。“注解不要也罢，直接暴露接口”，2017年底，正赶在Spring 5.0新品发布会的节骨眼上，Spring当机立断的拿出了布局未来的一张牌：Functional Bean。

发展才是硬道理。

这项肩负重任的Functional Bean究竟是何神技呢？不瞒您说，其实关键的修改就是加了一个成员方法。

对于Spring系统而言，IoC容器是其中最核心的部分，在代码上就是BeanFactory和各种ApplicationContext。这当中，最功绩显赫的要数能从xml文件装载Bean的ClassPathXmlApplicationContext，和能从代码上下文扫描Bean的
AnnotationConfigApplicationContext，它俩的光辉事迹早已在网上被广泛传诵，无需多述。比较有意思的地方在于，若从继承关系来看，这两位老爷子顶多也就算得上是远房亲戚，虽然都继承自ApplicationContext，在中间隔却了好几代血缘。而与Functional Bean相关的“改进”发生在AnnotationConfigApplicationContext的父类，也就是GenericApplicationContext类型里。

Spring 启动慢？提速利器 SpringFu 来了

在Spring的历史上，GenericApplicationContext并不是一位经常抛头露面的IoC容器。据文档记载，一直到Spring 5.0之前，GenericApplicationContext的适用场景都是配合其他DefinitionReader对象完成非标准来源的Bean注册，比如从properties文件加载Bean定义。它有一个registerBeanDefinition()方法，但实际的代码实现却只是将传入的Bean定义直接转交给代管的beanFactory对象。

就是这么个低调的小副手，在Spring 5.0里忽然被赋予了如同AnnotationConfigApplicationContext一样独立加载和操控Bean的权力，就像78岁高龄的前副总统被提名大选，虽是情理之中，却也有些意料之外。新增加的方法叫做registerBean()，共有6种重载，其中前5种都是最后1种的参数简化版本，因此本质上就是一个方法，其完整定义如下：

<T> void registerBean(String beanName, Class<T> beanClass, Supplier<T> supplier, BeanDefinitionCustomizer... customizers)

一共4个参数：

beanName：给Bean取的名字
beanClass：注册Bean的类型
supplier：关键参数，用于生成Bean对象
customizers：可选参数，对生成的Bean对象进行配置

其中supplier和customizers参数所属类型都是只有一个方法的接口，在Java 8以上版本里，这种接口参数可以直接传入Lambda函数作为匿名类来使用。例如下面这个Bean定义：

context.registerBean("myService", MyService.class, 
    () -> new MyService(),   // supplier参数，定义Bean对象的创建方法
    (bean) -> bean.setLazyInit(true)   // customizers参数，配置Bean
);

用Lambda函数定义Bean，没有注解，没有反射，没有动态特性，这就是Functional Bean。

由于AnnotationConfigApplicationContext本身也是一种GenericApplicationContext，因此在代码里访问它一点也不困难。比如继承ApplicationContextInitializer接口，然后通过其提供的initialize()回调方法参数拿到GenericApplicationContext对象。或者在Spring容器里的任意地方用@Autowired注解直接拿到全局GenericApplicationContext对象等等。然而对于早已习惯了“Spring == 各种注解”的现有开发者来说，相比写@Component、@Configuration等等注解，要自己获取应用容器，再调用registerBean()方法来注册Bean，适应成本实在有点高。即使在最适用的Serverless函数场景下，愿意折腾的开发者早就投奔了Nodejs阵营，不愿折腾的开发者继续Spring注解将就用，这种“丑陋”的Bean注册方式即便官方博客多次宣传，在发布过后的近一年里依然几乎无人问津。

眼看不温不火的Spring Cloud Function 2.0同样难以扛起推广Functional Bean的大旗，Spring此时亟待一位像当年SpringBoot那样席卷全球的网红节目来反转自己在Serverless战线上一度低迷的票房。为此，一个崭新的项目，SpringFu出现在了大家的视线里。

二 SpringFu vs SpringMVC

SpringFu项目的发起人Deleuze先生来自法国，已经为Pivotal公司的Spring团队效力超过6年，我猜他大概是位中国迷。根据项目作者的阐述，Fu有三种含义，首先是Functional的前两个字母缩写，其次是来源于单词Kong-Fu（功夫），最后则是谐音中文的“赋”（函数声明式的定义写起来像是有节奏韵律的诗歌）。

这款项目的设计也正如其名所述，将Spring Bean的定义过程编制得如同有行云流水般的顺滑。来看个例子：

public class Application {
    public static void main (String[] args) {
        JafuApplication jafu = webApplication(app -> app.beans(def -> def
            .bean(DemoHandler.class)
            .bean(DemoService.class))
            .enable(webMvc(server -> server
                .port(server.profiles().contains("test") ? 8181 : 8080)
                .router(router -> {
                    DemoHandler handler = server.ref(DemoHandler.class);
                    router.GET("/", handler::hello)
                          .GET("/api", handler::json);
                }).converters(converter -> converter
                    .string()
                    .jackson()))));
        jafu.run(args);
    }
}

相比我们印象中Spring项目里东一个@Service西一个@Controller的松散型结构，基于SpringFu编写的代码非常紧凑，信息密度极高。事实上SpringFu的大部分核心能力依然直接来自于Spring的各个子项目，但它与SpringMVC项目用各种注解区分不同Bean的方式完全不同，SpringFu让用户显式的调用不同的注册接口来将所需的不同Bean对象注册到Spring上下文容器，整个机制完全不依赖反射和其他Java动态特性。因此只要用户自己没有故意使用Java动态语法，采用SpringFu编写的程序就能天然支持GraalVM的AOT编译，生成启动速度极快的二进制文件。其效果要比提供大量运行时信息给GraalVM编译器更简洁而显著，这也是SpringFu能带来近百倍提速的主要原因。

为了更直观的感受SpringFu这种声明式代码的独特Feeling，下面以SpringMVC的几种典型注解为线索，对比一下二者的差异。

首先是普通的Bean定义，在SpringMVC通过@Configuration类注解和@Bean方法注解来表示。

@Configuration
public class MyConfiguration {

    @Bean
    public Foo foo() {
        return new Foo();
    }

    @Bean
    public Bar bar(Foo foo) {
        return new Bar(foo);
    }
}

在SpringFu里对应的是ConfigurationDsl类型的beans方法，该方法接收一个Consumer接口对象作为参数，按照惯例，Consumer接口的实现通常采用Lambda方法来定义，因而在代码中不会显式的见到BeanDefinitionDsl的身影。

ConfigurationDsl config = beans(def -> def
    .bean(Foo.class)
    .bean(Bar.class) // 隐含使用构造函数注入其他Bean
)

在实际的代码里，一般也极少出现单独的ConfigurationDsl，它总是以Consumer的形式出现，并且隐藏在Lambda方法里面被传递给需要它的对象。

像SpringMVC中使用@Component、@Service等注解的地方，在SpringFu里的处理方法与前例是相同的，只需将原类型的注解去掉，然后通过beans()方法来注册。例如下面这两个定义：

@Component
public class XxComponent {
    // ...
}

@Service
public class YyService {
    // ...
}

在SpringFu里大致是这个样子：

public class XxComponent {
    // ...
}

public class YyService {
    // ...
}

beans(def -> def
    .bean(XxComponent.class)
    .bean(YyService.class)
)

稍有特殊的是@Controller注解（以及@RestController注解），由于它是业务请求的入口，与API的路由息息相关，因此在SpringFu中有专门的DSL类型与之对应，比如WebMvcServerDsl和WebFluxServerDsl，它们提供诸如port()、router()等方法来定义与HTTP监听相关的属性。例如这两个SpringMVC的接口：

@RestController
@RequestMapping("/api/demo")
public class MyController {

    @Autowired
    private MyService myService;

    @GetMapping("/")
    public List<Data> findAll() {
        return myService.findAll();
    }

    @GetMapping("/{id}")
    public Data findOne(@PathVariable Long id) {
        return myService.findById(id);
    }
}

在SpringFu里，通常将处理请求的入口类命名为Handler（而不是Controller，这种命名更符合函数定义的惯例），如果将上述代码“直译”为SpringFu结构，大概会长这样：

public class MyHandler {

    private MyService myService;
    public MyHandler(MyService myService) {
        this.myService = myService;
    }

    public List<Data> findAll() {
        return myService.findAll();
    }

    public Data findOne(ServerRequest request) {
        val id = request.pathVariable("id");
        return myService.findById(id);
    }
}

router(r -> {
    MyHandler handler = server.ref(MyHandler.class);
    r.GET("/", handler::findAll)
     .GET("/{id}", handler::findOne);
}

实际更符合惯例的SpringFu写法则是将MyHandler类型本身也匿名掉，这样上述代码可以进一步精简成：

router(r -> {
    MyService myService = server.ref(MyService.class);
    r.GET("/", myService::findAll)
     .GET("/{id}", request -> {
         return myService.findById(request.pathVariable("id"));
     });
}

这种流畅的声明式代码对于天生小巧的Serverless函数十分契合，尤其搭配上同样简洁的Kotlin语言时，往往仅需一个文件就能完成许多中等复杂程度函数的定义。

不过从SpringFu的业务范围来看，它的目标并非替代SpringMVC。在Spring布局的Functional Bean蓝图里，SpringFu更像是一支精锐的突击小分队，专攻以Serverless函数为典型的新型轻应用场景。对于Spring框架的传统优势领域，中后台大型服务而言，把所有Bean集中定义在一个地方毕竟过于理想。在通往Serverless的道路上，其实SpringFu并不孤单，它还有一个姐妹项目叫SpringInit，该项目立足于通过编译期代码增强，将用户编写的SpringMVC注解偷偷换成Functional Bean的方式注册，从而实现大型JVM服务的Serverless适配。而这个同样异想天开的项目作者正是大名鼎鼎的SpringBoot和SpringCloud项目创始人Dave Syer。由于篇幅所限，本文不对SpringInit项目再做展开，有兴趣的同学可移步Github围观。

三源码解读

在设计之初，SpringFu就是奔着DSL（特定领域语言）的思路去的，项目分为JaFu（Java-Fu）和KoFu（Kotlin-Fu）两个部分，分别对应了符合Java和Kotlin语言语法的新型高效Spring服务编写方式。由于开发人手不足，其中JaFu子项目在0.1.0版本后曾暂停过一段时间，代码也从仓库里移除了，后来社区呼声强烈，在0.3.0版本里又再次复出。两者的本质原理大差不差，以下的源码分析以JaFu的最新发布版本v0.4.3作为参考。

项目结构十分简洁，一共3个模块：

autoconfigure-adapter：公共的ApplicationContextInitializer对象

jafu：SpringFu的Java DSL实现

kofu：SpringFu的Kotlin DSL实现

其中autoconfigure-adapter模块被jafu和kofu共用，它实现了许多ApplicationContextInitializer对象，这些对象用于在SpringBoot初始化过程中通过Functional Bean机制预注册某些系统的Bean。这当中，有些是为了从而加速服务的启动过程，比如ServletWebServerInitializer中注册的TomcatServletWebServerFactoryCustomizer，在这里直接注册会比让SpringBoot自己去扫描快许多；有些是为了改变服务行为，比如在JacksonJsonConverterInitializer会注册一个名称为mappingJackson2HttpMessageConverter的Bean，它会影响json对象通过HTTP接口返回时的序列化方式。总之这个模块属于针对函数场景的Spring定制优化，涉及很多Spring内部细节，我们点到为止。

在jafu模块下的源文件并不多，放在顶层目录最显眼位置的JaFu.java是用户程序的发动机，提供了进入SpringFu世界的三种入口方法application()、webApplication()和reactiveWebApplication()。它们负责创建出Spring的ApplicationContext容器，然后将其包装成一个匿名的JafuApplication对象返回，在之后在各种DSL里传递的context成员都是这个容器的引用。

几种入口的区别在于创建的ApplicationContext容器类型，application()生成的是原始的GenericApplicationContext类型容器（能够提供Functional Bean所需的registerBean()方法的最基础容器类型），而webApplication()和reactiveWebApplication()生成的是功能更丰富的ServletWebServerApplicationContext和ReactiveWebServerApplicationContext容器，它俩都来自SpringBoot项目，从这里已经可以看出，SpringFu麻雀虽小，却是站在巨人肩膀上起飞的。

在入口方法上还有一个关键细节，是创建JafuApplication对象时候要接收一个ApplicationDsl类型的参数。这个ApplicationDsl是SpringFu整套DSL机制的总指挥舱，里面琳琅满目的装载着其他所有DSL元素。

至此，SpringFu的外观轮廓已经出来了。任何SpringFu程序的最外层代码都可以概括成下面这种三部曲模式：

application(         // 构造，也可以是webApplication()或reactiveWebApplication()
    ApplicationDsl   // 配置
).run()              // 启动

第一步“构造”完成，接下来是内容最丰富的一个部分：“配置”。

从继承关系来看，ApplicationDsl是一种ConfigurationDsl，而ConfigurationDsl以及其他各种DSL元素都来自AbstractDsl。

Spring 启动慢？提速利器 SpringFu 来了

在所有类型中，孤零零的LoggingDsl是唯一没有继承AbstractDsl的漏网之鱼。作为SpringFu项目里最简单的DSL元素，去掉空行和注释，LoggingDsl类型的有效代码只有20行。不过，即便如此特立独行，在LoggingDsl身上依然保留着一项与其他DSL元素相同的特征：构造方法接收以自身类型为模板的Consumer对象作为参数。

LoggingDsl(Consumer<LoggingDsl> dsl) {
    dsl.accept(this);
}

构造函数里只有一行dsl.accept(this)，这行代码在所有DSL元素里都会出现。只是在继承了AbstractDsl类型的DSL元素中，它是被放在实现initialize抽象方法的地方，而LoggingDsl类型没有继承过来的initialize方法，就直接将它摆在构造函数里了。“把自己传递给构造方法接收的Consumer对象”，关于DSL的这个神秘行为，我们在后面讲“启动”的环节里再来解释。

回到ApplicationDsl上来，这个类型只是在ConfigurationDsl的基础上，通过一个MessageSourceInitializer对象额外注册了几个Spring自用的Bean，主要功能都是直接继承自ConfigurationDsl。再看ConfigurationDsl类型，这里有几个比较常用的方法：

configurationProperties(Class clazz)：注册属性配置类，相当于@ConfigurationProperties注解。
logging(Consumer dsl) ：提供函数的输出日志配置。
beans(Consumer dsl) ：提供定义Bean的地方，相当于@Configuration注解。
enable(Consumer configuration) → 为其他DSL提供扩展能力的万能配置入口，比如增加Web监听。

为了符合流式声明结构的要求，这些方法都返回ConfigurationDsl类型，并且使用使用return this让下一个配置可以串联起来。然后就可以写出像下面这样的配置代码：

conf -> conf
    .beans(...)
    .logging(...)
    .enable(...);

beans()方法接收的是一个消费BeanDefinitionDsl的匿名函数，这个DSL提供bean()方法，其效果类似SpringMVC程序里的@Bean注解，但在内部会通过GenericApplicationContext的registerBean()方法直接注册Bean到IoC容器，没有反射和扫描的过程。logging()方法接收一个消费LoggingDsl的匿名函数，后者提供level()方法，可以动态调整任意包路径的输出日志级别。enable()方法需要结合其他DSL元素一起使用，其用途非常广泛，比如开头示例里的webMvc()方法会返回一个WebMvcServerDsl对象，可以配置HTTP监听、路由等属性并通过该DSL对象自动注册相关的Bean到Spring上下文。

在整个ApplicationDsl对象定义完以后，就进入到最后的一个环节“启动”了。前面提到过，application()接收一个ApplicationDsl对象，会返回一个JafuApplication对象。接下来就要调用这个返回对象里的点火器方法run()。

SpringFu的DSL是声明式的，开发者通过ApplicationDsl对象定义的所有配置信息，此时都还藏在ApplicationDsl自己的肚子里，真正的Spring容器里面依然空空如也。在JafuApplication的run()方法里，SpringFu创建出由SpringBoot框架封装的SpringApplication应用对象，并将传入的ApplicationDsl对象指定为该应用对象的initializer，然后调用应用对象的run()。这之后就进入了SpringBoot的剧本，SpringApplication会完成Spring运行所需的所有前序工作，然后调用所有initializer对象的initialize()方法，包括此前传入的ApplicationDsl对象。

在ApplicationDsl的initialize()方法里，首先通过super.initialize(context)调用祖父类型AbstractDsl的initialize()方法，将传入的context容器引用保留下来。然后执行dsl.accept(this)进入构造时传入的回调方法。在接下来的beans()和enable()方法里，又会显式的调用子级DSL元素的initialize()方法，从而将这个初始化过程一级一级的迭代下去。就像是层层嵌套的递归调用，直到所有子级元素都构造完毕。至此，初始化过程结束，程序返回到SpringBoot的启动流程。

从源码不难得出结论，SpringFu程序的本质就是规避了JVM动态特性的SpringBoot程序。在卸掉过去spring-boot-starter-web和spring-boot-starter-webflux沉重的外壳之后，换上了一身轻便的战袍。

看似离经叛道，实则一脉相承。